Agent Assembly Blog

SDKs Are Not Security Boundaries

2026-06-25T00:00:00.000Z

An in-process SDK is the fastest way to govern an agent — but it is not, by itself, a security boundary. Anything running in the same process can bypass it.

That's why Agent Assembly is built as three independently-deployable layers:

SDK (in-process) — fastest path; applies pre-execution allow/deny and emits events.
Sidecar proxy — enforces network egress with no code changes; catches what the SDK misses.
eBPF (kernel) — uprobes on SSL libraries plus exec/file syscall hooks catch everything, including deliberate bypass attempts.

Each layer raises the cost of evasion. The SDK is for adoption and speed; the proxy and eBPF layers are where the boundary becomes hard to cross. Treating the SDK as the whole story is the mistake — defense in depth is the point.

Why Agent Assembly Exists

2026-06-25T00:00:00.000Z

Autonomous agents are shipping into production faster than the controls around them. An agent that can call tools can move money, touch customer data, and reach the open internet — usually with the same credentials as the human who deployed it, and with secrets sitting inside the model's context window.

Agent frameworks make agents capable. They don't give an agent an identity, constrain its authority, or keep secrets out of the model's reach. That gap is what Agent Assembly closes: a runtime boundary that gives every agent an identity, limits what it can do, and injects secrets at execution time so they never enter the context the model can see.

This blog is where we'll share the build — engineering notes, security decisions, and the story of making a governance layer for autonomous agents.