As published, this post framed the product as a fixed stack of interception tiers, each one catching what the tier above it missed. That framing has since been retracted. ADR 0033 records it as a forbidden design: it presents one deployment shape as the architecture, and "the tier below catches it" implies a continuity of coverage the product does not have — an absent component governs nothing, and nothing behind it picks up the slack.
The body below has been corrected to the current framing: governance is a set of distinct roles, each with its own reach, its own decision authority and its own failure mode, and which of them exist at all is a deployment fact. The argument this post makes is unchanged — an in-process SDK is not a security boundary — and the bounds it stated were already accurate. Only the framing carrying them has been replaced.
That's why Agent Assembly does not rely on the SDK alone. Governance is spread across distinct roles, and which of them are present is something you decide when you deploy — not a ladder that fills itself in:
aa-sdk-client itself has
no in-tree caller that refuses, a non-cooperating process simply never calls it, and it does not
see raw HTTP, subprocess spawns, or file access.HTTP_PROXY/HTTPS_PROXY and trust
the local CA, and interception is HTTP/1.1 — HTTP/2, gRPC, and WebSocket fall outside it.Each role raises the cost of evading undetected. The SDK is for adoption and speed; the proxy is where a second, out-of-process decision gets made; the kernel probes are where you find out something happened that neither of them saw. Treating the SDK as the whole story is the mistake — defense in depth is the point.
The honest version of "defense in depth" is worth stating, though, because the alternative is the over-claim this post exists to argue against: three conditional roles compose into a narrower gap, not the absence of one. An action that is not a wrapped tool call, is not routed through the proxy, and does not run OpenSSL on a Linux host with the probes loaded is seen by none of them.
The per-role boundaries, and which bypasses have actually been measured versus merely reasoned about, are enumerated in Limitations and known bypasses.
]]>Agent frameworks make agents capable. They don't give an agent an identity, constrain its authority, or keep credentials from travelling with its requests. That gap is what Agent Assembly is closing: a runtime boundary that gives a registered agent an identity, limits what it can do on the paths you route through it, and scans its outbound traffic so recognised credentials are redacted before the request is forwarded.
Worth saying plainly, because the distinction matters more than the pitch: that boundary holds on the paths it is wired into. An agent launched outside the managed path with no integration installed, or talking over a transport the proxy does not parse, is outside it — and we publish exactly where that line falls in Limitations and known bypasses.
This blog is where we'll share the build — engineering notes, security decisions, and the story of deciding what an agent may do before it does it.
The closing line originally described the product with a category phrase we have since stopped using, because it names a component rather than what the product decides. Wording only — no claim in this post has been changed or withdrawn.