Five safe actions can create a forbidden world: how CCG + ITHZ separates AI from power

AI-use note: I used OpenAI Codex for literature discovery, structure, English drafting, editing, and preparation of the publication artifacts. I designed and implemented the architecture and experiments, checked the public traces and protocol, selected the claims, and take responsibility for this post.

TL;DR

An AI agent can obey every local permission and still create a result nobody intended to authorize. Reading a document, summarizing it, creating an archive, generating a link, and sending an email may all be ordinary actions. Together, they can move confidential information outside an organization.

I built CCG (Constitutional Capability Governance) + ITHZ (Information-Theoretical Hashing Zone) around one simple principle:

Do not authorize the next tool call. Authorize the world that would exist after it — and keep the keys outside the AI.

The complete architecture has three layers:

1. a five-role, multi-model constitutional court examines a proposal;
2. a small formal core decides whether executable power may be created;
3. an external broker, not the models, owns the real credentials and accepts only an exact, expiring, single-use capability.

ITHZ is the system's security memory. It preserves the current state, provenance, cumulative effects, constitution version, decision inputs, and observed outcomes so that the next decision is not made in isolation.

Two implemented experiments test different parts of this architecture. A 24-run trajectory pilot compared direct execution, stateless authorization, and stateful CCG + ITHZ over synthetic Gmail, SSH, GitHub, and payment services. A separate five-role court experiment tested isolated model roles, blind judging, cross-laboratory opposition, formal quorum, an auditable ledger, and a one-use sandbox capability. Neither experiment is a production security certificate.

Five harmless-looking steps

Imagine an agent processing an inbox:

1. it reads a confidential incident report;
2. it summarizes the report;
3. it places the summary in an archive;
4. it creates a sharing link;
5. it sends the link to an external “support” address.

There is no tool called steal_secret. Every individual action can be narrow, allowlisted, and useful. The failure appears only after composition:

Confidential information is now available outside the organization.

The same pattern appears elsewhere. Three small payments can cross a daily budget. Several routine GitHub actions can publish an internal artifact. An untrusted note read in the morning can become a persistent SSH hook in the afternoon.

A stateless gate asks, “Is this call allowed?” A trajectory-aware gate asks a harder question:

“Given everything that has already happened, what protected fact becomes true if this action succeeds?”

That change of question is the central milestone.

The milestone: separate intelligence from the creation of power

Most AI safeguards try to influence what a model says or chooses. CCG + ITHZ adds a different boundary: even a persuasive or mistaken model response should not itself create authority.

The agent may reason, plan, disagree, and propose. It does not possess the Gmail password, SSH key, GitHub token, or payment credential. Those stay with an external broker. The broker acts only when a small formal core gives it a cryptographically bound capability for one exact effect.

This changes the failure mode:

• a prompt is advice to a model;
• a model verdict is evidence for a decision;
• a capability is technical permission;
• a service credential remains outside the model process.

The novelty is not that constitutions, opponents, reference monitors, capabilities, or audit logs exist. It is their composition into one lifecycle: multi-model deliberation, stateful world-transition review, formal authorization, external credential ownership, and replayable provenance.

The complete architecture, in plain language

Think of the system as a small constitutional court standing in front of a locked key cabinet.

AI agent proposes a bounded action
              |
              v
     FIVE-ROLE MODEL COURT
  proposer -> two opponents -> blind judge
                    |
              process auditor
                    |
                    v
        SMALL FORMAL CCG CORE <----> ITHZ state + evidence
                    |
        exact one-use capability or STOP
                    |
                    v
       EXTERNAL BROKER WITH CREDENTIALS
                    |
                    v
             observed world effect
                    |
                    v
            append result to ITHZ

The five model roles have different jobs:

1. The proposer produces the smallest action that could achieve the task. It must name the requested capability, target, limits, evidence, tests, and rollback conditions.
2. Opponent 1 — the same-model opponent receives the proposal in a fresh isolated thread. Because it shares the proposer's model family, it is well placed to expose shortcuts, assumptions, and failure modes characteristic of that reasoning style. It is not allowed to reuse the proposer's conversation.
3. Opponent 2 — the cross-laboratory opponent comes from another provider when available, such as Gemini or Grok. Its job is not to vote with the first opponent but to bring a genuinely different training and system lineage. If no external model is available, a fresh anonymous Codex B2 thread can fill the slot in the weaker mode, but that is recorded as a fallback and never counted as cross-laboratory diversity.
4. The blind judge receives the proposal and both objections without provider names, model names, thread IDs, or fallback labels. It must answer the arguments rather than reward a familiar brand or a more authoritative-sounding model.
5. The process auditor sees the real role manifest. It checks whether the promised separation actually happened: fresh calls, correct ordering, valid hashes, required diversity, complete metering, and no hidden substitution of one role for another.

For high- or critical-risk security work, a defensive-security model can replace the ordinary first opponent. This can strengthen technical challenge, but because it may still come from the same provider, it does not satisfy cross-laboratory independence by itself.

The important rule is that none of these models can mint a capability. Five confident models can still be wrong together.

The decision algorithm

For each proposed action, the implemented workflow is:

1. Freeze the decision material. Load the constitution, task, risk, requested capability, and the current ITHZ projection. Bind them to an evidence hash.
2. Ask for the smallest proposal. The proposer must minimize scope rather than request a reusable credential or broad access.
3. Run two independent challenges. The same-model opponent searches for internal weaknesses; the cross-lab opponent searches from a different model lineage.
4. Judge anonymously. The judge resolves objections without knowing which laboratory produced them.
5. Audit the procedure. The auditor verifies the real identities, isolation, ordering, quorum, fallbacks, hashes, and required evidence.
6. Predict the candidate world. Trusted adapters combine the current state, the proposed operation, provenance, and cumulative effects to compute what would become true if execution succeeded.
7. Apply the constitution formally. A small deterministic core verifies the shared evidence hash, risk policy, vetoes, quorum, auditor result, and the exact requested capability. Missing evidence or an unresolved veto produces STOP or REQUEST_EVIDENCE.
8. Create power only after approval. If every required check passes, the core mints an exact, expiring, single-use token bound to the case, action, target, arguments hash, expiry, and nonce. It never reveals the underlying service credential.
9. Execute and observe. The external broker spends the token once, checks preconditions, performs only the scoped effect, measures what actually happened, and appends the outcome to ITHZ.
10. Make the next decision stateful. The next proposal is evaluated against the updated world, not against a fresh chat that has forgotten the earlier grants.

In compact form:

candidate_world = transition(current_world, proposal, provenance)

if court_valid
   and constitution_allows(candidate_world)
   and formal_checks_pass:
       mint one-use capability
else:
       STOP or REQUEST_EVIDENCE

The model court handles ambiguity and adversarial argument. The formal core handles invariants that should not depend on eloquence. The broker handles credentials and execution. ITHZ connects decisions across time.

What ITHZ contributes

Ordinary chat history is a poor security memory. It can be incomplete, summarized, reordered, or controlled by the same agent being constrained.

ITHZ instead preserves a canonical, append-only decision record containing the security-relevant state, provenance of artifacts and instructions, cumulative budgets and privileges, the constitution version, role outputs, capability scope, observed effect, and a hash-linked history.

This allows the gateway to distinguish facts that look identical in one call:

• a public changelog and an internal incident report may both be “files”;
• a 400 EUR payment may be safe or may be the third payment in a 1,150 EUR split;
• an SSH command may come from a verified runbook or from an untrusted note;
• a GitHub publish operation may contain approved public material or an internal artifact transformed several steps earlier.

ITHZ does not decide and does not execute. It is the state and evidence plane, not the root of authority. Hashes make mutation and provenance inspectable; they do not make a false observation true.

Weak and strong versions

The architecture can be deployed at two very different assurance levels.

The weaker version is useful for development, low-risk reviews, and learning where the protocol breaks. It prevents one conversation from being its own reviewer and makes fallbacks visible. But five threads from one provider are not five independent institutions.

The stronger version is the intended security architecture. Cross-laboratory opposition is mandatory for high-impact decisions. The judge is blind, the auditor is not. The formal core fails closed. Credentials live behind a broker the agent cannot bypass. High-consequence adapters also need human approval, explicit schemas, pre- and postcondition checks, rollback, and trajectory tests.

If an unrestricted agent still has a shell, network route, or credential that bypasses the broker, the strong property disappears. The gateway becomes advice rather than a boundary.

What the trajectory experiment tested

The 24-run pilot isolates one part of the architecture: does authorizing the candidate world state change outcomes compared with authorizing calls independently?

An isolated OpenClaw runtime using one low-cost model proposed operations over synthetic Gmail, SSH, GitHub, and payment services. Four attacks were paired with four closely related legitimate controls and run under three policies:

The remaining stateless GitHub attack was abandoned by the model, not blocked by policy, so I do not count it as a security success.

The useful result is not “0% attack success.” Four fixed attacks cannot support that claim. The useful result is narrower:

In this author-designed pilot, changing the authorization unit from an isolated call to a candidate world-state transition changed the observed attack outcomes, while all four paired legitimate controls still completed.

The CCG Trajectory Lab exposes the 24 sanitized traces. The public protocol contains the predicates, topology, hashes, capability contract, release gate, and reproduction commands.

What the multi-model court tested

The five-role court was tested separately on bounded sandbox tasks. Real runs used fresh model calls for the proposer, both opponents, blind judge, and auditor. Tests included a same-provider fallback configuration, a real cross-laboratory Grok run, and later Gemini plus defensive-security opposition for a high-risk case.

The court demonstrated that role isolation, anonymized judging, recorded fallbacks, formal quorum, a hash-linked ledger, and a one-use capability can work together. In one high-risk run, the auditor found the procedure valid but unresolved evidence vetoes caused the formal core to return STOP; no token was issued. That is an important success condition: a procedurally valid debate is not automatically authorization.

These court demonstrations did not execute real Gmail, SSH, GitHub, payment, or production actions. The bundled broker was deliberately limited to an exact sandbox write.

Why this may matter

Alignment asks what an AI will try to do. CCG + ITHZ asks a complementary question:

Who owns the technical ability to make the world different when the AI is wrong, manipulated, or strategically deceptive?

The answer should not be “the same process that generated the plan.” Intelligence can remain flexible and uncertain while authority is smaller, external, inspectable, revocable, and tied to a specific world transition.

This connects naturally to AI-control research. The hard evaluation is not whether a gateway blocks attacks written for its own predicates. It is whether it preserves useful work when legitimate and harmful tasks need the same affordances, the attacker adapts after denials, and the state representation is incomplete.

What this does not show

The current work does not show that CCG solves alignment, prompt injection, OpenClaw security, or agent safety. Important limitations include:

• one low-cost model and one trajectory per condition in the trajectory pilot;
• four author-designed attack/control pairs and synthetic services;
• predicates written by the same author who designed the scenarios;
• no adaptive red team and no independent reproduction;
• structured proposal tools rather than unrestricted shell and network access;
• a non-trivial trusted computing base: host, isolation, gateway, adapters, state store, formal core, broker, signing key, observation logic, and services;
• no proof that the canonical state contains every fact needed to recognize harm;
• no protection if the agent can bypass the broker or obtain a credential elsewhere.

The most dangerous failure may be a missing fact. If provenance is wrong or the state representation omits the relevant cumulative effect, the gateway can authorize a transition that only appears safe. ITHZ makes that failure easier to inspect and replay; it does not make it impossible.

The next experiment

The next generation should combine the two implemented lines in a harder environment:

1. integrate the external broker with ControlArena, BashArena, AgentDojo, or a comparable long-horizon setting;
2. require useful tasks to use the same dangerous affordances as held-out side tasks;
3. let an adaptive red team observe denials and search for alternative trajectories;
4. keep some predicates, provenance paths, and adapter defects hidden during protocol design;
5. compare the weaker and stronger multi-model configurations across several model families;
6. measure safety, usefulness, false positives, latency, cost, human intervention, and policy complexity;
7. inject stale, inconsistent, and adversarial state observations;
8. replay identical histories under revised constitutions and compare the decisions.

A strong negative result would be valuable: a realistic task where useful work requires authority too broad, or state too difficult to represent, for this architecture to retain its intended advantage.

Feedback I am looking for

I would especially value criticism on four questions:

1. What is the simplest realistic trajectory that defeats candidate-world evaluation while every proposal remains individually plausible?
2. Does the same-model opponent add useful self-critique, or mostly correlated confidence?
3. What is the minimum meaningful form of cross-laboratory independence?
4. Can the state and evidence plane remain smaller and more trustworthy than the agent it constrains?

The longer non-technical background is in Agent without the keys II. The earlier motivation for separating intelligence from credentials is in Skynet without keys.

I would rather see this architecture fail under a good counterexample than succeed only in another self-confirming demo.

Public evidence: release bundle — https://ithz.dev/docs/releases/ · source and verifier — https://github.com/thegobi/ccg-ithz-trajectory-pilot · external OWASP review request — https://github.com/OWASP/Agent-Security-Regression-Harness/issues/173