Skip to main content
How it works

Six roles — and only some of them can stop anything.

Agent Assembly is not a fixed pipeline. Its architecture is a set of roles, and a deployment instantiates the ones you actually put in place. This page names the six, says which of them can refuse an action before it runs, and shows where the platform changes the answer.

The one thing to carry away: a role you have not deployed is reported as absent. There is nothing underneath it that picks up what it would have done.

The shape

A field of roles, not a stack of tiers

Two rules give the picture its shape, and they are the reason it is drawn this way. First, a role may be absent, and its absence is something the product reports rather than something another role quietly covers. Second, a role’s authority belongs to that role: the control plane decides but holds no traffic, transport mediation holds traffic and can refuse it, and today the Linux host adapter mostly watches. Nothing in the model makes them interchangeable.

On a path you routed

Managed execution checkpoints

Decide before the action runs · ask the control plane

Protocol and transport mediation

Decides before the request leaves the machine · refuses on its own configuration, and asks the control plane for tool calls

Platform-specific host-level adapters

Platform-dependent and often absent · report to the evidence pipeline, decide nothing

Not on any path

Governance control plane

Policy · identity · budgets · approvals · audit. Answers decision requests, and holds no traffic.

Credential and capability boundary

Runs across the others · what each may ask for, and how a credential is bound to an identity

Evidence and protection-state pipeline

Runs across the others · records what was decided, and reports what was absent

Outside the path you routed

An unmanaged launch · traffic that never reached a mediator · an encryption library nothing hooks · a platform with no adapter. Not decided — and the record says so.

Read the picture for what it does not contain. Nothing connects the three roles on the routed path to one another, and they are listed in no order: none hands work to another, none is a fallback for another, and one you have not deployed leaves a hole that gets reported rather than filled. The governance control plane is not on any path — it decides and holds no traffic, so its answer stops an action only where one of the routed-path roles is already waiting in front of that action.
The six roles

What each one is, and what you get today

Governance control plane

The authority that holds policy, identity, budgets, approvals and audit, and answers decision requests. It holds no traffic of its own.

Today. Runs anywhere. Its refusal stops an action only where something in front of that action waits for the answer.

Managed execution checkpoints

Points on a routed path where an action is presented for a decision before it runs — a policy check from an SDK, a managed launch, or a tool handed to the sandbox.

Today. Runs anywhere, and is reachable only where the agent opts in. A process that does not make the call is not asking.

Protocol and transport mediation

A mediator placed on the wire that can refuse, redact or rewrite a request before it leaves the machine. This is where refusal before the action is strongest, because it sits outside the agent’s process.

Today. macOS and Linux. There is no Windows build path, so on Windows this role is absent rather than degraded.

Platform-specific host-level adapters

Operating-system-level mediation of processes, files and encrypted traffic. Each platform needs its own mechanism, and a platform without one has none — this is the role that is most often simply missing.

Today. Linux has one and it observes. macOS and Windows have no adapter; see the platform section, which states what macOS has instead.

Credential and capability boundary

What a component is allowed to ask for, and how a credential or a capability is bound to an identity — including the scanning and redaction applied to outbound requests.

Today. Runs anywhere. An agent presents an identity and a possession proof, and that identity is asserted rather than established.

Evidence and protection-state pipeline

How a claim is substantiated, downgraded and reported — including reporting that a role was configured and unavailable, or absent altogether. This is the role that makes the other five legible.

Today. Runs anywhere. Writing is best-effort, so it records what got through rather than a ledger of what happened.

Seen, judged, or stopped

Which mechanism can actually stop something

Three different things get called protection, and telling them apart is most of an evaluation. Observed means an event reached the record. Evaluated means a decision was produced for the action. Denied before execution means the action did not take effect and the decision came first. Only the third is prevention — and the table below says which mechanism reaches it.

MechanismHighest it reaches today
The proxy — connection-time refusal, in-tunnel host re-check, credential block, MCP tool-call adjudicationDenied before execution For traffic that is routed through it and inspected.
The control plane’s action checkEvaluated It reaches refusal before the action only through a caller that waits on the answer, and today that set has two members: the MCP path, and an SDK shim that honours the answer.
The runtime policy checkpointEvaluated It reaches refusal before the action only if the SDK shim honours the answer.
The runtime scannerRedacted It runs after the action and returns counters, not a verdict.
The SDK clientEvaluated — advisory It is not an enforcement point.
Linux kernel probes for encrypted traffic, files and process executionObserved · Detected No such signal takes part in any allow or deny decision.
The Linux syscall guardDetected Plus terminating the process afterwards. The offending call has already run by the time the process dies, so this is explicitly not refusal before the action.
The WASM sandboxDenied before execution For tools handed to it — but it is not on an agent’s normal tool-call path, so it is not a general guarantee.
Developer-tool configuration writesNot a data-path claim Writing a tool’s own settings file is tool governance: it takes effect only if the tool honours those keys. Any prevention these integrations deliver is the proxy’s, borrowed through the launch environment they inject.

One inference this table exists to block. An audit event proves that something was observed. It never proves the action was stopped. A record and a refusal are different outcomes, and a page that treats one as evidence of the other is the failure this whole architecture was rewritten to prevent.

Platforms

Where the platform changes the answer

Host-level adapting is the one role that is genuinely platform-specific, and it is where a picture drawn for one operating system misleads a reader running another. Each platform needs its own mechanism, and where a platform has none, it has none.

Linux

Transport mediation is a released artifact. Host-level adapting is done with eBPF: kernel probes report plaintext from encrypted connections, process execution and file activity. One program in that set enforces rather than reports — an opt-in syscall guard that terminates a confined process.

No eBPF signal takes part in any allow or deny decision. The guard terminates the process after the offending call has already run, which is detection followed by a kill, not refusal before the action; it is off unless a specific process is named. File-activity probes are x86_64 only, and the privileged loader daemon that owns every kernel operation is published to the crate registry rather than in the release downloads.

macOS

Transport mediation works and is the route to most of what this site describes; it is installed from source rather than from the release downloads. There is no operating-system-level interception adapter, and building one is an explicit non-goal.

Do not read that as no host enforcement on macOS. It is the one platform on which the host-enforcement rung is reachable at all, through an opt-in, authorized settings write for the managed Claude Code launch. Two things bound that hard. What the write establishes is that the file says the right thing; whether the tool honours those keys while it runs is unmeasured. And the rung is recorded as unearned at the published v0.0.1-rc.6 tag — the evidence it rests on postdates that tag.

Windows

There is no local mediation of any kind. Transport mediation has no Windows build path, and no host-level adapter exists.

The control plane, the CLI and the SDKs run there, so a policy check from your own code still reaches a decision. What is missing is anything on the wire to apply it to traffic your code did not make.

The boundary

When an action is outside all of this

An action is on the governed path when, before it takes effect, it is presented to something that is configured to decide and to honour the answer. It is outside the boundary when any link in that chain is missing. These are the ways that happens today, each one measured rather than imagined.

  • The agent never calls the checkpoint. The call is voluntary; a process that does not make it is not asking, and nothing about it is known.
  • The answer is not honoured. The SDK evaluates and returns a decision; refusing to execute lives in the language shim around it, not in the client.
  • Traffic never reaches the mediator. Proxy settings are injected by a managed launch — an ambient value, a removed one, or a session started by hand changes what is covered.
  • The tool has no managed launch to offer. One shipped integration cannot build a governed launch command at all, and another is capped at observation, so neither injects anything to route.
  • The destination is mediated but not inspected. Payload inspection is limited to model-provider hosts by default, so another host is tunnelled with its connection observed and its payload not.
  • The encryption library is not one the probes hook. They attach to OpenSSL symbols, which Go’s own TLS stack and Node’s statically linked one do not expose.
  • The platform has no host-level adapter — macOS and Windows, as above.

What gets recorded instead. For anything outside the boundary, nothing is known about the action, so the rule is that it is not reported as allowed and not as clean: the record says the action or its payload was not inspected. Read that as scoped to the action rather than to the connection carrying it — a host the proxy does not inspect is still adjudicated when the connection is made, so the connection is observed while the payload is not. One live defect runs against this rule today: the connection-level event still records an allow for traffic that is about to be tunnelled uninspected, tracked as AAASM-5637. Take the rule and the open defect together rather than as finished behaviour. And a quiet log is evidence about the observer, never about the agent.

Go deeper

This page stops here on purpose

Below this depth the answers live in the engineering record, where they are versioned with the code they describe. Each link goes to the source this page derives from — none of it is restated here, because a second copy drifts from the first inside one release.

The architecture decision record

The canonical account of the six roles, the per-platform matrix and the vocabulary this page uses, with a source citation on each row.

Read the decision record →

The trust boundary

The threat model, the failure posture of each control including the ones that fail open, and the enumerated ways around the boundary.

Read the security model →

Limits, per integration

What each developer-tool integration covers and what it does not, including the two that cannot put a tool on the path at all.

Read the known limits →

Every claim, with its evidence

The shared register this page and the rest of the site quote from — each entry with the term it reaches, its bound, and the evidence rows behind it.

Read the claim register →