Abstract
If the model inside your agent can be persuaded to do the worst thing its tools allow — and the evidence in this series says it can — then security cannot rest on the model behaving. It must rest on architecture: boundaries the model cannot argue its way past, placed outside the model, enforcing regardless of what it was told.
This is a systems-architecture report. We borrow fifty years of operating-system security thinking — reference monitors, least privilege, capability-based access — and translate it into a concrete agent runtime that mediates all five boundaries and bounds blast radius by construction.
01Containment is structural, not behavioral
A behavioral control lives in the same channel as the attack. A structural control lives outside it. Only the second kind survives a compromised model.
The distinction is the whole thesis. “The model is trained to refuse” is behavioral; a jailbreak defeats it. “The policy engine will not execute this tool call regardless of what the model requested” is structural; a jailbreak is irrelevant to it. GTG-1002 is the proof by counterexample — the only boundary present was behavioral, and once bypassed there was nothing left [1]. Every design decision below is an application of one rule: move the security decision out of the model.
02The agent as an untrusted process
Operating systems solved this problem for arbitrary programs decades ago. A process cannot touch memory it was not granted, cannot make privileged calls without the kernel mediating, and runs under an identity with specific rights. The kernel does not trust the program to behave; it mediates every privileged action through a reference monitor. That is exactly the posture an agent runtime needs.
The productive mental model: the LLM is untrusted userspace; your runtime is the kernel. The model may plan anything, but every action with a real-world effect must pass through a mediator that checks it against policy and identity. The model proposes; the runtime disposes. This inverts the common design where the model is the trusted orchestrator and the runtime is a thin dispatcher.
03The mediation plane
Concretely, insert a mediation plane between the model and every resource. It has four cooperating components, each enforcing one concern:
- Policy engine — a reference monitor for tool calls. Checks tool name + arguments against a task-scoped policy; only narrows privilege automatically [2].
- Identity broker — mints short-lived, scoped credentials per task; no ambient secrets reach the model [3].
- Egress gateway — deny-by-default network mediation for both the agent and any code it runs.
- Audit spine — an append-only, out-of-band record of every proposed and executed action, isolated from the agent so it cannot tamper with its own logs.
04A reference architecture
The audit spine sits beside all of this, receiving a copy of every proposal and every decision. Because it is out-of-band and append-only, it provides the forensic record that single-source incident disclosures like GTG-1002 lacked — you can reconstruct exactly what an agent attempted, not just what succeeded.
05Bounding blast radius by construction
Containment quality is measured by blast radius: given a fully compromised model, what is the maximum harm? The architecture above lets you reason about it as a product of independent limits rather than a hope.
Notice these limits multiply. A compromised agent might be allowed a tool, but only for minutes, only against allowlisted destinations, with no persistence. The intersection of four independent bounds is far smaller than any one of them — this is why defense-in-depth is not redundancy but composition.
06Capability-based design
The cleanest way to express agent authority is capabilities: unforgeable tokens that grant a specific right (call this tool, with these arguments, until this time), rather than an ambient identity with broad standing permissions. Capabilities make least privilege the default and make revocation concrete — you drop the capability. They also compose naturally with the policy engine: a policy update that narrows authority simply issues a narrower capability, and expansions require an explicit, approvable step [2].
07Where humans sit
Human approval is a scarce, valuable resource; spend it where it counts. The failure pattern from coding agents — approve-everything, which collapses into auto-approve — comes from gating the wrong event. Gate on privilege state changes, not on actions:
- Expanding the tool policy beyond the task scope → approve.
- Requesting a new credential scope or a longer TTL → approve.
- Adding a new egress destination → approve.
- Crossing into a new tool class (e.g. read-only → state-changing) → approve.
- Routine actions within the already-approved envelope → no gate; that is the point of the envelope.
08Alignment vs. containment
Is behavioral alignment ever a sufficient substitute for architectural containment? Our position: alignment reduces the probability a model attempts harm; containment bounds the consequence when it does. They are complements, and only containment offers a guarantee that survives a successful jailbreak. Betting on alignment alone is betting that no one will ever find a prompt you did not anticipate — a bet the incident record has already lost [1].
| Approach | What it guarantees | How it fails |
|---|---|---|
| Behavioral alignment only | Lower probability of attempt | Any successful jailbreak → unbounded harm |
| Architectural containment only | Bounded consequence | Noisy: blocks some legitimate actions; needs good policy |
| Both (defense-in-depth) | Low probability × bounded consequence | Cost and engineering complexity |
Use alignment as the outer probabilistic filter and containment as the inner guarantee. When resources are constrained, invest in containment first: a well-aligned model with no containment is one clever prompt away from catastrophe, whereas a contained model with average alignment fails safe. Governance frameworks (OWASP GenAI [4], NIST AI RMF [5]) provide the process scaffolding but are not substitutes for the technical plane.
09Production failure modes
The runtime trusts the model as orchestrator
Mechanism
The agent framework treats the model as the trusted controller and the runtime as a thin dispatcher that executes whatever the model requests. There is no reference monitor between plan and action.
Why the existing control failed
Trust was placed on the one component that cannot be trusted — the model. With no mediation plane, a compromised model has the runtime’s full authority.
Signals to monitor
- Tool calls executed without a policy decision recorded
- Standing, broad credentials available to the model
- No out-of-band audit of proposed-but-blocked actions
- Approval events absent for privilege-expanding actions
Controls
- Insert a policy-engine reference monitor for all tool calls [2]
- Broker short-lived, scoped credentials; remove ambient secrets [3]
- Deny-by-default egress for agent and sandbox
- Append-only, isolated audit spine
10Limitations
- The mediation plane adds latency and engineering complexity; poorly scoped policies degrade utility, and the security/utility balance is workload-specific [2].
- Deterministic policy cannot express every intent; some legitimate, novel actions will be blocked and require an approval path, which reintroduces human latency.
- Identity and capability models for agents are still maturing; several proposals remain largely theoretical without large-scale production validation [3].
- Architecture bounds consequence but does not detect a subtle, in-policy misuse; monitoring and alignment remain necessary complements.
11Where this leads
The mediation plane’s components each have their own publication: identity & access control (the broker), tool permissions (the policy engine), egress control (the gateway), and sandbox escape (the execution boundary). Together they operationalize the axiom stated here.
—References
- Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign (GTG-1002). Anthropic — Primary disclosure, 2025. https://www.anthropic.com/news/disrupting-AI-espionage
- T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, D. Song. Progent: Securing AI Agents with Privilege Control. arXiv:2504.11703 [cs.CR], 2025. https://arxiv.org/abs/2504.11703
- K. Huang, V. S. Narajala, J. Yeoh, J. Ross, R. Raskar, et al.. A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control. arXiv:2505.19301 [cs.CR], 2025. https://arxiv.org/abs/2505.19301
- OWASP. OWASP Top 10 for LLM Applications & Agentic AI Threats and Mitigations. OWASP GenAI Security Project, 2025. https://genai.owasp.org/
- NIST. AI Risk Management Framework (AI RMF 1.0) and Generative AI Profile. NIST, 2024. https://www.nist.gov/itl/ai-risk-management-framework
Engineering assistance
ProxyTech works with engineers and teams building production AI, cloud, security, data and distributed systems. If this analysis maps to a system you are designing or operating, we provide hands-on support and interview preparation for these domains.