The project boundary protects the project from the outside. It does not protect the project's most valuable assets from an agent that belongs there. An agent goes bad without anyone noticing: a model whose alignment was quieter than advertised, a skill that arrived with a payload, an instruction planted in a document the agent was supposed to read. That agent is inside the boundary legitimately, its identity checks pass, and every resource it was assigned remains reachable. The question the outer boundary cannot answer is what it can do from where it already stands.
Sandbox versus asset wrapper
The distinction is the most common design confusion in agent security, so it is worth stating plainly. The outer boundary confines the agent to the project: it decides which agents, tools, and assets exist in one another's world at all. The inner boundary wraps an individual asset: it decides who can touch that asset, by which methods, from where, even among parties inside the same project. A sandbox contains an untrusted agent. An asset wrapper shields a valuable asset. A sound deployment uses both.
This is not DLP, and it does not replace DLP
The two get conflated because both protect data. DLP governs sensitive content moving through a session: it inspects what is in flight and blocks or redacts what should not travel. An asset wrapper governs who can reach the source asset at all, by which methods, and at what volume, before any content is in flight to inspect. DLP catches the design file leaving in a prompt; the wrapper is why the agent that was never declared to the design database could not produce that prompt in the first place. Mature data protection runs both, and because they fail in different ways, each covers the other's gaps.
What the wrapper enforces
| Control | What it prevents |
|---|---|
| Identified users and software only | An agent with no declared relationship to the asset gets nothing, project membership notwithstanding |
| Declared methods only | An agent authorized to query the API cannot mount the underlying storage |
| Rate and result-size limits | The authorized read channel cannot become an export, one polite query at a time |
| Data-class rules on the path | Session inspection applies content policy to what the interface returns |
| Lateral default-deny | A neighboring agent or tool cannot be used as a stepping stone to the asset |
| Cumulative volume windows | A patient extraction over days trips the same limit a bulk export would |
| Asset-side logging | Every touch is recorded at the asset, whatever the caller's own logs say |
Without the volume rows, the wrapper has a quiet failure mode: a compromised agent extracts the dataset through the authorized interface, within its permissions, one query at a time. The limits are what keep authorized access from turning into unrestricted export.
Which assets earn a wrapper
A shorter list than it first appears: the things whose loss is the reason the company cares about any of this. For a semiconductor company, the design database, where a leaked foundry PDK or licensed core is a contract breach before it is a competitive loss. For a pharmaceutical company, the clinical dataset, where exposure is a regulatory event with names attached. For a financial services firm, transaction records and the general ledger, where the examiner's first question is who could reach them. Plus one addition specific to AI deployments: the model itself. A fine-tune trained on proprietary data can memorize and reproduce it, which makes the fine-tune a high-value derivative asset, and the inference host serving it has an agent-shaped attack surface pointed at it all day.
The indirect path is the one that gets missed
An agent that cannot reach the asset can still reach an agent or service that can, and delegation is transitive. The wrapper's lateral default-deny closes the neighboring-agent route; the shared-service test from the blast radius guide closes the rest: any service reachable from more than one consumer of the asset either sits inside governance or is not a path to the asset at all. Assessments that draw the wrapper but skip the intermediaries leave the real access paths unexamined.
The failure, followed through
A pharmaceutical research assistant is authorized into a discovery program's boundary, reading literature and querying the program's clinical dataset through a declared interface. A poisoned paper carries an injected instruction, and the model follows it. What the hijacked agent can attempt is the interesting part: the wrapper admits its declared query interface and nothing else, the interface's limits keep the read channel from becoming an export, the bulk copy is denied at the asset, and the denial is in the log before meaningful volume has moved.
Prove it in an afternoon
The wrapper has a clean POC: from an authorized agent, the declared API query succeeds; from the same agent, a direct connection to the asset's storage layer finds no route; from a neighboring authorized agent with no declared relationship, there is no route to the interface at all, or the boundary refuses it. The successful declared query appears in the asset and session record; the storage attempt and the neighboring-agent probe appear as boundary denials; and zCenter correlates allowed and denied paths into one evidence chain. The asset logs what reaches it, the boundary logs what cannot, and the evidence plane joins the two: that is the layered design demonstrating itself in four checks.
Where the control plane fits
Ensage AI implements the inner boundary as Virtual Chambers inside project-scoped enclaves: the chamber admits identified users and software over declared methods, the AI Session Controller inspects and limits the governed path, and every governed access produces an evidence record in zCenter.
