Choose your enforcement path

What governs this page

Three governed paths exist, they are independent of one another, and choosing between them is a decision about your platform and launch model rather than about the product’s architecture. This page sets out what each one needs, when it decides, what it does when it fails, and — at the same length — what it does not cover.

Ticket references on this page are plain text, not links: the tracker is not publicly readable, so a link would only reach a login wall — and a link checker scores that wall as reachable, which makes the reference look verified when it is not.

Every table below is generated from governance/capability-manifest.yaml in the ai-agent-assembly/agent-assembly repository — the capability and evidence manifest defined by AAASM-5531 — through the pinned extract capability-surface.toml in this repository.

Manifest version 1.0.0 · 80 capability rows · taken at commit e2730ddaf · the manifest’s own evidence tree 299de3883, dated 2026-08-06 · declared fix version agent-assembly v0.0.1-rc.7.

The extract is refreshed by hand, so it can lag the manifest. What this repository’s CI proves is that the generated tables on these pages match the extract — prose outside the generated blocks is not checked, and proving the extract itself matches the manifest needs a cross-repository check, which is AAASM-5600.

Level 1 — one sentence

Pick a path by what you can change — your agent’s code, its network route, or its host — then read what that path does not cover before you plan around it.

Level 3 — for an evaluator

The three paths, side by side

Grouping the manifest’s rows onto these three is this page’s doing; every fact rendered under a group is the manifest’s. The grouping follows the roles ADR 0033 §1 names and the components it lists against each. It is deliberately not a partition of the whole manifest — the rows no path claims are listed further down rather than forced into one.

The paths do not form a chain. A path you do not deploy is absent, and its absence is a reportable state rather than something the next one picks up. Deploying two does not compose them into a stronger single control; it gives you two controls with two separate boundaries.

What is not a path

Three things are routinely mistaken for a fourth path, and each mistake changes what you would plan for:

• The control plane is not an interception point. It holds policy, identity, budgets, approvals and audit, and it answers decision requests — but no agent bytes traverse it, so a refusal it issues stops something only when a component in front of the action blocks on the answer. Which components do, and which refuse on their own local configuration instead, is ADR 0033 §2’s caller table. Attribute a refusal to whichever component actually made it.
• eBPF is one Linux mechanism, not a cross-platform floor. It is an implementation of the host-adapter role on Linux only, and on the other platforms nothing takes its place. See what ships today.
• Writing a tool’s own settings file is not data-path mediation. It is tool-governance: it takes effect only if the tool honours those keys. Any data-path refusal such an integration delivers is the proxy’s, borrowed through the launch environment the integration injects. These rows are listed separately for that reason.

Path 1 — Managed execution checkpoints

What you change: your agent’s code, or the framework adapter it initialises. The checkpoint is a call your process makes before running a tool.

Who it suits: teams that own the agent’s source and can adopt an SDK.

What this path does not cover. Every row below is one the manifest records at Unmeasured or Unsupported — nothing is known about the action, or the mechanism is not available at all.

Two properties of this path decide whether it fits, and neither is visible from a quickstart:

• The checkpoint is voluntary. It is a call the agent makes. A process that does not make it is outside the boundary, and the product knows nothing about that action — not that it was allowed, and not that it was clean.
• Honouring a refusal is the shim’s job, not the client’s. ADR 0033 §4 records that the in-repo decision helper has no caller that refuses to execute, and that one out-of-repo shim maps transport failures to allow. Read the per-language rows above before assuming a returned refusal stops anything.

Path 2 — Protocol and transport mediation

What you change: the agent’s network route — an injected proxy environment and a trusted certificate authority — rather than its code.

Who it suits: teams that cannot modify the agent, including closed-source and vendor tools, on a platform where the mediator runs.

What this path does not cover. Every row below is one the manifest records at Unmeasured or Unsupported — nothing is known about the action, or the mechanism is not available at all.

Three defaults on this path are worth setting expectations against before you plan:

• Inspection is opt-in per host, not blanket. Only a built-in set of provider hosts is intercepted by default; everything else is tunnelled through without its payload being looked at. Widening that is an operator decision with a latency and compatibility cost.
• The egress lists are empty out of the box. An allow/deny decision at connection time decides nothing until you populate them.
• The mediator is not packaged everywhere. On macOS it arrives through crates.io only; see the channel table in what ships today.

Path 3 — Platform-specific host-level interception adapters

What you change: the host — a privileged component installed beside the agent.

Who it suits: Linux operators who need a view of process, file and TLS activity that does not depend on the agent cooperating.

What this path does not cover. Every row below is one the manifest records at Unmeasured or Unsupported — nothing is known about the action, or the mechanism is not available at all.

This path is the one most often planned against optimistically:

• It is predominantly an observation mechanism. Its probes feed the evidence pipeline and are consulted in no allow/deny decision.
• Its one terminating control is off unless you name a process, and it acts after the offending call rather than before it — which is why the manifest records it at Detected rather than at a pre-execution refusal.
• There is no adapter on macOS or Windows, and the rows above say so rather than leaving it to inference. Read the macOS position together with ADR 0033 §5.3, whose macOS row carries a qualification a summary reliably drops.

The launch route, which is not itself a path

A managed launch is how an agent or developer tool is placed onto one of the paths above — it injects the environment, and it writes settings into the tool’s own configuration. Its rows are here rather than under a path because a settings write is not a claim about the data path.

Supported tool and governable tool are different lists. One shipped adapter returns a launch failure rather than a governed command, and another is capped at observation; for those, no proxy environment is injected and there is nothing to route into.

Rows no path above claims

These are the manifest rows the three paths do not account for. They are published rather than dropped, because a row that quietly belongs to no path is exactly the kind of coverage assumption this page exists to prevent.

Most are cross-cutting — identity, credentials and the control plane’s own failure modes apply to whichever path you pick. The host-action rows are not: they are actions for which no mediation mechanism exists at all.

What none of these paths gives you

• A durable audit record from the SDK’s own interceptor. On the shipped path, a governed tool call through an SDK’s interceptor does not produce one — a caller-supplied handler does receive the record, but the SDK wires nothing itself. That capability is Planned in ADR 0033 §6’s sense: decided, not implemented, tracked as AAASM-5750, and carrying no capability claim until it lands. Audit evidence produced elsewhere in the system is a different question, and Check a published claim is how to take any single sentence about it to its evidence.
• A statement that an uninspected action was fine. Where nothing inspected an action, the honest report is that nothing is known about it. An absent audit entry is a fact about the observer, not about the agent.
• Coverage as a property of the architecture. It is a per-host, per-launch fact. Two hosts running the same version can have different answers.
• Anything from the managed service. The Cloud control plane and the Enterprise operations features are documented as intent, carry the status map’s 🗺️ Planned documentation-area label, and have no rows in the capability manifest. Nothing here should be read as saying either can be provisioned today.

Deeper

The role model these three paths are named after, the caller table behind the control plane’s position, and the verified platform matrix are all in ADR 0033 in the Core documentation. The manifest this page is generated from is governance/capability-manifest.yaml.

Generated content on this page is rendered by docs/scripts/generate_capability_surface.py from capability-surface.toml. Do not hand-edit between the BEGIN/END GENERATED markers — AAASM-5609.

Last reviewed: 2026-08-13 — AI Agent Assembly Team

Last updated: 2026-08-20 by AI Agent Assembly Team