Platform
One boundary in code. Every plane configured across it.
Harden every skill and every document and the perimeter grows with each integration — and has to hold perfectly. Harden the boundary instead and one enumerable set of gates has to hold, configured once in the architecture rather than a policy document you hope people read.
Two perimeters, compared
One perimeter must hold everywhere. The other holds in four places.
Both are architectures for the same problem. Only one of them can be enumerated.
And hardening a prompt means writing instructions, which are not controls — they're followed with high probability, not with certainty. So the gate sits outside the model, in code, where it doesn't depend on the model cooperating.
Grows with every integration
Harden the assets
- vet every skill before it ships
- audit every document an agent can read
- constrain every autonomous action in advance
- extend the perimeter each time a tool is added
- an instruction is followed with high probability, not certainty
Closed, stated in advance
Harden the effect boundary
- four effect categories, nothing outside them
- the gate lives in code, not in a prompt
- approval binds to the effect, not the tool that requested it
- an agent cannot escalate by finding another route
- the same four gates hold regardless of what changes upstream
What this changes
An adversary needs one failure rather than most of them.
The closed set
Four categories. Anything else is safe to leave open.
Crossing the boundary is one of exactly four things, enumerated below — there is no fifth. Those four are what C2 and C3 cover; C0 and C1 reach none of them, which is why they run unattended.
System of record
Production writes
Repositories, trackers, wikis, pipelines — any change to a system of record.
Leaves the boundary
Egress
Any call that transmits data outward. Exfiltration isn't a write, so a write-only definition leaves it uncovered.
Visible to a third party
Publication
Shared workspaces, threads, channels — anything visible to a third party.
Bounded per run
Spend
Resource consumption, bounded per run.
Human decision required
AI output is inert until a human acts, and the four above are the enumerated set of boundaries where that decision is recorded.
Execution, credentials, audit
The model can be wrong. The runtime still holds.
Sandboxing, egress control, and credential scope operate underneath the model. They hold even when its reasoning doesn't.
Configured once
Eight planes, four surfaces, and not one cell that varies.
Tool access, permissions, autonomy policy, logging, budgets, workspaces, skills, and credentials are set once and resolved on the path every agent has to take. Which surface a person opened — chat, CLI, remote tasks, a standing agent — changes none of them.
Neither does the model. Nothing on this page is specific to a provider or a framework, which is what lets a plane configured this quarter still be the plane next quarter.
Tool access
Which integrations exist and which credentials back them.
Permissions
What an agent may read and write, per endpoint.
Autonomy policy
Which actions execute unattended and which wait for a person.
Logging
One audit trail, regardless of surface.
Budgets
Spend bounded per run and attributed to a principal.
Workspaces
Where an agent builds, before anything is proposed.
Skills
The reusable instructions an agent draws on.
Credentials
Scoped and short-lived, issued per session.
Nothing here is model-specific
- A unified gateway — swap inference providers without a code change.
- An open skill format, portable across frameworks.
Scope
Org, team, user isn't three equal boxes. It's one hierarchy, enforced at every level.
Role-based access, budget ceilings, and configuration cascade down from organization to team to user. A lower scope may override only what's opened to it above — never reach past its own tenant boundary to another's.
No credential outruns the person behind it either: an agent never exceeds the authority of the identity it acts for.
Tenant isolation — one boundary per organization
Configuration cascades down; a lower scope overrides only what's opened to it above. Nothing here crosses the tenant boundary.
How work arrives
Proposed actions batch into one decision. Promotion doesn't have to be total.
Chat, remote tasks, and standing agents each collect proposed actions instead of firing them immediately. Review batches everything into a single decision, and the person reviewing can promote part of a proposal and hold the rest.
Chat
Reviewed in seconds to minutes
Remote tasks
Reviewed in minutes to hours
Standing agents
Reviewed hours to days later, out of band
Promoting a skill is a weaker thing
A skill is reusable instructions, promoted from a person to a team to the organization — and instructions are not a control. What promotion buys there is attention: a widely adopted skill's proposals warrant less scrutiny than an untested one's.
What an agent may know
Agents need a knowledge base. Text-only retrieval gives them a lossy one.
An agent answers from what it can look up; without your documents it answers from the model's memory instead. So it gets scoped collections of them, retrieved across images, tables, and figures as well as text.
In engineering and acquisition work
The load-bearing content
- an interface diagram
- a requirements table
- a test matrix
Not the paragraph around it.
Text-only retrieval
Drops the part that mattered
It answers confidently from what's left. That's a correctness property, not a convenience.
What this transfers
Moving the gate doesn't remove the risk. It relocates it.
Moving the gate to the write boundary moves risk onto review quality. A bad proposal that a tired person approves is the real attack, and batching — which reduces review burden — is where one hides.
Scope of this page
This describes architecture. It claims no certification, accreditation, or compliance attestation.
The mitigation is legibility
- Proposals show diffs rather than descriptions.
- Each action carries what justified it.
- Anything with non-operator lineage is visibly marked.
Next
These boundaries hold for tools you have not registered yet.
A briefing walks the perimeters against your own stack — which effects leave it, what a named human is asked to approve, and how a handful of your real tools would register against every plane above.