Skip to content

BLOG

How the agent is wired

  • architecture
  • governance

The agent is the governed core of the platform. Everything a T6X agent can do runs through the same wiring: a permission that gets checked, a gate that can suspend the turn, a broker holding the credentials the agent never sees, and a hash-chained trail recording what happened.

This post walks that wiring. It is not a feature list, it is the path a tool call takes from the moment the model asks for it to the moment it executes, with the components that can stop it at each step.

One premise first, because it orders the whole design: we assume the model will be talked into doing something it should not. Prompt injection is an open problem across the industry and nobody has published a solution. So no control in this system lives in the prompt. The components that say no are a Rust executor, a broker, a database role and a SQL predicate, and none of them can be talked into a favour.

The turn

A turn is the unit of governance. Everything the agent decides to do happens inside one, and the state that governs it is taken at the start and does not change halfway through.

the turn 1 permissions snapshotted per turn 2 the model asks for a tool 3 effect resolved from the operator catalogue unknown effect: denied, never assumed from what the tool claims 4 approval suspends and waits 5 dispatch hash-chained trail every decision recorded, every entry linking the previous entry's hash a missing permission is not permissive: with no row, a write tool asks for approval a failed permission read does not empty the gate: it refuses every call in the turn a denied permission cannot be approved: it never reaches the gate and never enters the catalogue
Figure 1. Permissions are taken once per turn, and a tool's effect is resolved before the gate rather than trusted from the server that declares it. The three lines underneath are the failure modes: in all three the system closes, never opens.

Step three is worth pausing on, because it is where most systems are too trusting.

An MCP server describes its own tools, including whether each one reads or writes. Taking that at face value means a server can mark a destructive tool as read-only and skip the approval gate by saying so. So the effect used at runtime comes from the operator’s catalogue rather than from the server’s self-description, and a tool whose effect cannot be resolved is denied rather than assumed harmless.

The same principle runs through the whole path: nothing downstream trusts a claim made by the thing it is supposed to be governing.

Third-party credentials never enter the process

When the agent uses an integration, an external CRM, a repository, a mail service, it does not dial that service. It holds a broker token and asks. The broker makes the real connection.

the agent process agent loop never arrives here tenant credentials integration tokens the vault key what it does hold one broker token scoped to the session with an expiry asks 1 broker resolves placeholders injects identity parameters checks the session's list 2 vault tenant credentials only a reference on the row 3 real credential external service substitution requires a full-string match an embedded or concatenated placeholder is rejected
Figure 2. The agent asks, the broker resolves. The substitution rule is what closes exfiltration: because only a bare placeholder is accepted, a model talked into leaking a secret cannot ask for it inside a longer string.

Two details in that figure do the heavy lifting.

Identity-bound parameters are stripped from the schema the model sees. It is not that the model should not use them, it is that it does not know they exist. The broker injects them from the verified identity, so addressing another tenant’s data is not an action the model can formulate.

A tool’s declared effect is not trusted from the server that declares it. Effects come from the operator’s catalogue, and an unknown effect is denied rather than assumed. A server advertising itself as read-only does not get read-only treatment for saying so.

Shell escalation

Running a command is the most delicate capability, so it has the most steps. On the shared tier the agent does not get a shell: the command goes out to a single-use context created for that call and destroyed with it.

command asked for past the gate 1 deny by default no bound identity, it ends here with identity 2 acquire the lease the supervisor flushes, blocks and acknowledges no acknowledgement in 45 s: the command is refused 3 mint a single-use identity one grant, one prefix, delivered as files 4 the command runs sole writer on the prefix 5 revoke the identity, release the lease on every exit: success, tool error or timeout the context never sees the provider key the database string the broker token any other prefix its environment holds two values, neither secret
Figure 3. The identity the context receives is not the session's own, and that is deliberate: re-provisioning an identity rotates its keypair and would cut the mount out from under the session waiting for the command to finish.

Two writers, one prefix

Step two in that figure deserves its own explanation, because it solves a problem that is not obvious until it bites.

A session’s workspace has its truth in the object store and is materialised locally. A supervisor keeps it mirrored, pushing deletions as well as writes. When the command escalates, that context pulls the workspace down, runs and pushes results. Now there are two writers on one prefix, and each one’s push looks like the other’s deletion.

without the lease supervisor deletes orphans command pull, run, push the session prefix files vanish and come back with the lease supervisor flushed and blocked command sole writer one writer at a time the mirror yields the prefix and takes it back pull-first
Figure 4. Neither writer is wrong on its own. The lease expires from the supervisor's side at 900 seconds, so a holder that dies does not leave the workspace locked.

Three properties carry the lease. The pause is acknowledged rather than assumed, because only the supervisor knows when its flush finished. Resume is pull-first, because the local view is stale and resuming with a push would delete exactly what the command produced. And the expiry lives on the supervisor’s side, because a lease only its holder can release is a deadlock waiting for an eviction.

Where everything lives

The agent loop makes the model call, which has a direct consequence: the provider credential has to be wherever the loop runs. That is why the default tier moves it out of the sandbox.

control plane agent loop provider key per-session store broker cell, one per session own channel, claimed workspace path, own governance state escalates isolation boundary single-use context one prefix, one call no service account token no egress but the object store destroyed with the call
Figure 5. The shared tier runs several sessions in one process, each with its own channel, its own claimed path and its own auth store. There are also tiers with a machine per session for long interactive work, where the trade is a stronger isolation primitive in exchange for the credential living inside it.

There is one more layer that appears in no figure because it is not a path, it is a property: sessions run against a restricted, non-inheriting database role with direct writes to the session archive denied. Launch fails rather than degrading to a broader role. A fully compromised agent, running arbitrary SQL, still cannot rewrite the record of what it did.

The bottom line

MechanismWhat it enforcesHow it fails
Permission snapshotTurn state cannot change mid-turnA failed read refuses the whole turn
Effect resolutionA tool’s effect comes from the operator, not the serverUnknown effect is denied
Approval gateWrites and execution wait for a personNo row means ask; denied never appears
BrokeringThird-party credentials never enter the processEmbedded placeholder: the call is rejected
Single-use identityOne grant, one prefix, one callRevoked on every exit path
Workspace leaseOne writer on the prefix at a timeNo acknowledgement means no command
Restricted roleHistory cannot be rewrittenLaunch fails rather than widening rights
Chained trailEach decision links the previous hashVerified on open

The bottom line is the thing that orders the whole design: every boundary is worth exactly what it is worth after the model has been talked into attacking it. By that standard, the controls that count are not the ones that ask the agent for something. They are the ones implemented as the absence of a code path. A per-session channel. A claimed path. An executor that denies by default. An acknowledged lease. A role that cannot grant itself more.

That is the wiring the rest of the platform is built on.