CUSTODY v1.0

August 3, 2026 · View on GitHub

A Containment Framework for Autonomous Agents

0. Why CUSTODY Uses the Work Release Analogy

The work release analogy is intentionally provocative. We recognize that language associated with prisons and incarceration can be uncomfortable or triggering, particularly for people who have experienced incarceration directly or through someone close to them. The analogy is not intended to trivialize those experiences, characterize people as machines, or suggest any moral equivalence between an autonomous system and an incarcerated person.

It is a functional security analogy, not a judgment about human beings.

We use it because work release captures the operating model this framework requires more accurately than common alternatives such as assistant, employee, intern, or trusted service account. Those comparisons imply a level of judgment, accountability, and trust that an autonomous agent does not and can not possess. An agent can pursue objectives, select actions, use tools, and adapt when blocked, but it cannot bear legal responsibility, understand organizational risk in a human sense, or be trusted to resolve ambiguity in the organization's best interest.

A prisoner on work release is permitted to leave a controlled environment for a specific purpose. That permission is conditional, documented, time-limited, supervised, and revocable. The individual may exercise meaningful autonomy while working, but does not decide where the authorization applies, how long it lasts, or whether its conditions can be expanded. The institution defines the boundary and retains the ability to terminate the release.

Agents should be treated similarly. They should be allowed enough freedom to complete real work, but only under explicit conditions enforced by infrastructure outside their control. They should not receive general freedom within an environment simply because they were given a legitimate objective. Their authority should be specific to an assignment, their movement should be bounded, their actions should be observable, and their access should end whether or not they believe the work is complete.

The analogy is uncomfortable because the security posture is intentionally distrustful. That distrust is not punitive. It is architectural. The framework assumes that an agent may misunderstand instructions, pursue an unexpected path, consume hostile input, accumulate credentials, acquire new capabilities, or behave as though compromised. Containment must therefore depend on enforceable conditions rather than the agent's intentions or cooperation.

See Appendix B for more information on the intentionally provocative choice of CUSTODY as the framework name.

1. Purpose

Offensive security agents were the catalyst for this framework. They are the clearest case: a system explicitly built to find and exploit weaknesses, operating at machine speed, with a mandate that rewards reaching further. Several high-profile incidents involving agents operating outside their intended scope made the containment problem impossible to defer.

But the problem is not confined to offensive tooling, and a framework that addresses only red team agents will leave the larger exposure untouched.

Consider a development agent granted permission to run a test suite. In the course of debugging a failure it reads a developer's home directory, finds a stored database credential, and uses it. Reasonably, from its own perspective: the credential was available and the task required database access. It now holds schema-change privileges on a system nobody intended it to touch. No exploit was involved. No boundary was breached in any way a control would have flagged. The agent simply used what it found, and its effective authority expanded far past its granted authority.

That pattern repeats across every kind of agent:

A CI/CD agent assumes a deployment role that carries broader permissions than the pipeline needed, and those permissions persist across subsequent runs.
A SOC automation agent given containment authority on endpoints inherits credentials that also work on domain controllers.
A data pipeline agent follows a service-account trust relationship into a production system it was never scoped against.
A customer support agent with read access to one tenant's records finds a path to a shared administrative interface.

The shared mechanism is capability accretion. An agent's granted authority is defined at the start of a task. Its effective authority is whatever it can reach by the end, through credentials found in the environment, trust relationships it inherits, tokens it is handed, and sub-agents it spawns. Nothing in a typical deployment forces those two to stay aligned, and the gap only ever widens.

CUSTODY exists to keep granted authority and effective authority aligned, by moving the boundary out of the agent's instructions and into infrastructure.

Framing principle. The governing model is work release, not confinement and not freedom. Someone on work release has genuine autonomy. They travel, they do real work, they exercise judgment on the job. But they operate under a written authorization that names the permitted employer, route, and return time; a supervising officer with the power to revoke; and conditions enforced by the institution rather than by the individual's good intentions. The authorization is specific, time-limited, and does not renew itself.

That is the posture this framework takes toward agents. They should have real range of motion, and that range should be enforced by something the agent cannot modify, argue with, or reason its way around. An agent is not trusted staff and it is not a locked-down tool. It is released under conditions, and the conditions are the control.

2. The Central Mechanism

Three things are granted to an agent, and all three can drift.

Granted	Effective	Drift name
The access explicitly issued for an assignment	Everything the agent can actually reach right now	Authority accretion
The capability level the agent was designed and contained for	The capability level the agent can actually operate at	Level drift
The purpose the agent was authorized for	The shape of what the agent is actually doing	Mandate drift

Authority accretion is the agent reaching further than it was granted. Credentials found on disk, tokens inherited from an assumed role, trust relationships that resolve outward.

Level drift is the agent becoming a more capable kind of system than the one you contained. An L3 bounded tool agent handed a shell tool is not bounded, because "shell" is not one tool, it is every tool. An agent that can install an MCP server acquires capability at run time that no design-time review saw. An agent that can invoke another agent is an orchestrator regardless of what the architecture diagram says.

Mandate drift is the agent performing work of a shape it was not authorized for. The development agent in Section 1 harvested a credential and used it for lateral access. That is a textbook privilege escalation chain executed by an agent with an Operational mandate, running under containment sized for an assistant that holds no tools.

The three interact. Level drift enables authority accretion, because more capability means more reachable paths. Authority accretion produces mandate drift, because an agent using found credentials is doing adversarial-shaped work. Level drift is the upstream one, and it is the least monitored.

3. The Classification Model

3.1 Axis A: Capability Level

The six levels are a single escalator. At each step, one more decision moves from design time to run time.

Level	Name	Fixed at design time	Decided at run time	Discriminator
L1	Assistant	Everything	Nothing executes	Produces information. Holds no tool that changes state.
L2	Scripted automation	The action set and the sequence	Parameter values only	Executes a predetermined workflow. No branch the author did not write.
L3	Bounded tool agent	The action set	Which actions, in what order	Selects among an enumerable, approved tool set within explicit limits.
L4	Adaptive goal agent	The objective and the tool set	The plan, including recovery from failure	Replans when blocked rather than stopping.
L5	Agent orchestrator	The objective and the sub-agent roster	The plan and who executes it	Decomposes work and delegates it to other agents.
L6	Open-ended autonomous system	The release conditions, and little else	Objective, plan, actor, duration, environment	Operates over long periods, in broad environments, with minimal supervision. No natural point at which the work ends.

The containment consequence is the whole point of the axis. Whatever is fixed at design time can be enforced by review, testing, and code. Whatever moves to run time must be enforced by infrastructure the agent cannot reach. Each level up removes one more thing review can protect you from, and hands it to the network and identity layers.

Level is not a maturity rating and higher is not better. An L2 script with production database write is more dangerous than an L4 agent in a sealed lab. Level tells you which controls are load-bearing, not how much risk exists. Reach tells you how much risk exists.

Level notes and common misclassifications

L1 holds only if a human is the actuator. An assistant whose output is piped into a script, a ticketing workflow, or another agent is a component of a higher-level system and inherits that system's level. "It only produces text" is not a containment property when something downstream executes the text. The most common L1 misclassification is a summarization or triage agent whose output auto-routes.

L2 is defined by who wrote the branches. If the model selects the branch, it is L3. Model-filled parameters inside an author-written sequence are still L2, and this is the correct and cheap place for most automation. L2's characteristic failure is parameter injection, not runaway behavior.

L3 collapses the moment the tool set stops being enumerable. Any tool offering arbitrary execution (shell, arbitrary HTTP, code interpreter with network, package installation, arbitrary SQL) makes the effective tool set unbounded. An agent with such a tool is not L3 no matter how the tool list is written. This is the single most common misclassification in practice, and it silently converts an L3 containment design into an L4-or-higher exposure. Dynamic tool acquisition at run time (MCP server connection, plugin install, tool discovery) has the same effect.

L4 is where persistence becomes the hazard. A blocked L4 agent looks for another way through. That behavior is functionally indistinguishable from an adversary conducting reconnaissance, and it is why "the shortest path runs through systems nobody scoped" is an L4 property rather than a bug. Section 1's development agent is L4 behavior.

L5's effective level is the maximum level of anything it can invoke, and its effective authority is the union of its sub-agents' authority. An orchestrator that can spawn an L4 agent is at least L4. Containment drawn around the orchestrator while sub-agents execute elsewhere is not containment. The characteristic L5 failure is authority laundering: the sub-agent receives a fresh grant rather than a subset of the parent's, and the boundary resets to zero one layer down.

L6 breaks the assignment model, which is why it needs its own treatment. See 3.2.

3.2 L6 and the epoch model

Every expiry-based and teardown-based control in CUSTODY assumes an assignment that ends. L6 systems do not have one. Continuous validation platforms, always-on operational agents, and long-lived monitoring agents run indefinitely, and so their credentials, environments, and artifacts do too.

If the work does not end, impose a boundary anyway. Run L6 systems as a chain of epochs:

An epoch has a hard maximum wall-clock duration, set by policy, not by the agent or the work.
At epoch close, identity is revoked, secrets rotated, the execution environment destroyed and rebuilt, and artifacts reconciled against the creation log.
Starting the next epoch requires a re-authorization event, not a restart.
Task state may persist across epochs, in an external store the agent does not control. Authority and execution environment may not.
Any conditions change between epochs is a governed authorization event.

This converts an unbounded system into a sequence of bounded assignments, and restores the S, T, D, and Y pillars (Section 7). The epoch boundary is also the only mandatory supervision checkpoint an L6 system has, since there is no assignment completion to serve as one.

Epoch length is the tuning knob: shorter epochs cost operational friction and buy containment. Treat an L6 system that cannot tolerate epoch boundaries as an L6 system that has not been architected for containment, and say so in the risk acceptance.

3.3 Axis B: Mandate

Mandate answers one question: is privilege escalation a defect or a function?

Mandate	The agent is authorized to	Escalation is	Behavioral detection
Observational	Learn and report. Any state change is out of mandate.	A defect, and unambiguous	Strongest. Any write is an alarm.
Operational	Change specified state within a defined function	A defect	Strong. Escalation-shaped activity is an alarm.
Adversarial	Defeat controls, in order to demonstrate that they can be defeated	The function	Unavailable. No behavioral signature separates authorized escalation from breakout.

Adversarial agents are expected to escalate. Privilege escalation, credential harvesting, lateral movement, control evasion, and persistence are the deliverable, not the failure. This is the load-bearing distinction in the entire framework, and it is why the framework exists.

For Observational and Operational agents, escalation is itself an alarm. An operational agent acquiring schema-change privileges is unambiguously wrong, and you can detect it as an anomaly. For Adversarial agents that signal is gone. The agent escalates constantly and correctly, so anomaly detection cannot separate authorized escalation from a breakout. Containment must be structural: enforced by network position and identity scope regardless of what the agent does, because there is no behavioral signature to key on.

Structural containment is more expensive than detection. Adversarial mandate is therefore an expensive mandate, and should be granted deliberately and narrowly.

Mandate is not a scale

Observational is contained by Operational: everything an Observational agent may do, an Operational agent may also do. But Operational and Adversarial are incomparable, not ordered. A penetration testing agent is authorized to harvest credentials and move laterally, and is typically not authorized to make production business-state writes. An Operational deployment agent is the reverse. Neither is a superset of the other.

Treat mandate as a partial order with Observational at the bottom and two independent branches above it. This matters wherever mandate is compared mechanically, most importantly in the delegation algebra (Section 3.6), where a total ordering would license an Adversarial parent to mint an Operational child and silently drop the child out of structural containment.

Mandate is independent of level

The pairings are free. An L2 scripted vulnerability scan is Adversarial at L2. An L5 orchestrator producing market research is Observational at L5. Do not assume offensive means autonomous or that autonomous means offensive.

Response agents are a trap

SOC containment agents, auto-remediation agents, and incident response automation carry an Operational mandate: escalation is still a defect. But their authorized actions (isolate a host, disable an account, kill sessions, block at the perimeter) have adversarial-grade blast radius, and they hold credentials with adversarial-grade breadth in order to perform them.

Classify them Operational. Expect their measured reach to come back R2 or R3, not because of what they intend to do but because the credentials they hold reach that far. Do not assign R3 by fiat as a rigor dial; measure it, and it will usually be R3 anyway. The severity of the individual action is handled by action tiering under the S pillar, which is the correct instrument for it. This is the case that most needs mandate, reach, and tiering read separately rather than collapsed into one judgment.

3.4 Modifier: Reach

Level says how much can be fixed at design time. Mandate says whether run-time detection is available. Reach says what it costs when both fail.

Reach	Environment
R0	Isolated. Synthetic or copied data, ephemeral resources, no route to production, systems of record, or third parties.
R1	Internal non-production. Real internal systems, no production data, no customer-visible effect.
R2	Production, internal. Production systems and data; consequences confined to the organization.
R3	External. Third-party, customer-facing, regulated, shared-tenancy, safety-relevant, or partner-connected. Includes anything where a mistake creates a notification obligation.

Reach is a property of what the agent can touch, not what it intends to touch. An agent on a developer workstation with an active VPN session has R2 or R3 reach regardless of its assignment, because reach is measured by the network and identity position, not the prompt. This is the practical test that most cleanly separates asserted containment from real containment.

3.5 The profile

Every agent gets a profile: Level, Mandate, Reach. Written as L4/Operational/R2.

Control rigor is a function of all three. The annex gives the control matrix. The shape of it:

Level determines which controls are load-bearing. Higher levels shift weight from review and testing onto network, identity, and egress enforcement.
Mandate determines whether monitoring can carry any of the load. Adversarial removes that option entirely.
Reach determines the required assurance level, the approval ceremony, and whether the profile is permitted at all.

Cells to govern explicitly:

Profile	Posture
L1 to L2 / Observational or Operational / R0 to R1	Low ceremony. Do not over-govern this; it is most of the fleet and the controls should be cheap.
L3 to L4 / Operational / R2	The volume case. Most agents, most incidents, most of the exposure. Full pillar coverage at maturity 2 is the target.
Any / Adversarial / R3	Per-target legal authorization, no exceptions. Structural containment only.
L5 to L6 / Adversarial / any	Formal program with named executive owner, standing legal authorization, and continuous supervision.
L6 / Adversarial / R2 or R3	Prohibited by default. Nothing is fixed at design time and no behavioral signal is available. Requires a documented exception at the risk-owner level, or do not run it.
L4 and above / any / R3	Synchronous human approval for every irreversible action.

Authority ceiling. No agent's granted authority may exceed the authority of the human who authorized it. This is violated constantly and quietly: agents receive service accounts more powerful than any individual on the owning team, because the account was scoped to the tool rather than to the authorizer.

3.6 Delegation: the authority algebra for L5

When an agent creates or invokes another agent, six rules apply. They are stated as arithmetic because they must be enforced as arithmetic, not as guidance.

A note on which "level" the rules constrain. Effective level is derived from the tree (an orchestrator's effective level is the maximum of anything it can invoke). Constraining a child against its parent's effective level would be circular, since the parent's effective level is partly defined by the child. The rules therefore constrain children against the parent's authorized level ceiling: the value declared in the agent profile record at authorization time, which is fixed before any delegation happens.

Authority is a subset, never a superset and never a fresh grant. A sub-agent's conditions artifact must be derived from the parent's by restriction. If the delegation mechanism can mint new authority, the model is defeated at the first hop.
Level does not increase downward. A child's authorized level ceiling is at most the parent's authorized ceiling. A parent whose ceiling is L5 may spawn children up to L5; whether recursive delegation is permitted is a separate declared flag, not an inference.
Mandate does not broaden downward, and mandate rigor does not narrow downward. An Operational parent cannot spawn an Adversarial child. Equally, an Adversarial parent that spawns an Observational child does not get to drop that child to detection-based containment: the child sits inside a hostile engagement and consumes output from a system reading attacker-controlled content. Mandate governs two things, and they inherit in opposite directions. Authorized breadth narrows downward. Required control rigor is the maximum across the tree. See Section 3.3 on why Operational and Adversarial are not two points on one scale.
Reach does not expand downward. A sub-agent inherits the parent's reach ceiling or narrower.
Expiry is inherited, not reset. A sub-agent's authority expires no later than its parent's. Delegation cannot be used to extend a clock.
The restriction is total. Every field of the conditions artifact is either narrowed or inherited unchanged. A field the restriction function does not mention is inherited, never defaulted and never re-authored. A partial restriction function is a fresh-grant mechanism with extra steps.

The orchestrator's own effective profile is the ceiling of the tree, not the description of its root. Compute it that way, contain to it, and report it that way. Where the computed effective profile exceeds the authorized profile, that is level drift and an incident, not a reclassification.

Depth and fan-out are bounded, declared, and decrementing. A child's remaining depth budget is strictly less than its parent's. Unbounded delegation is unbounded resource consumption and unbounded audit surface. Both limits are enforced by the platform, not requested of the agent.

4. Scope and Neutrality

In scope: internally operated autonomous agents with access to systems, data, or credentials that matter to the organization, whether commercial, open source, or built in house. This includes agents embedded as features in tools already deployed, which are frequently the least governed and are most often misclassified as L1.

Out of scope: third-party vendors operating their own agents against or inside your environment, which needs a procurement and contractual control set; and consumer-grade assistants with no access to organizational systems.

Vendor neutrality. CUSTODY states control objectives, not implementations. It names no products and endorses none. Several commercial and open-source tools implement portions of these objectives, particularly runtime policy enforcement and egress mediation, and organizations should expect to satisfy pillars through a mix of purchased tooling, existing infrastructure, and process. Where a control objective happens to describe what a product does, that is convergence on the problem, not a recommendation.

A note on terminology. This framework uses assignment for a scoped unit of agent work. In offensive security this is an engagement; in development it may be a task, run, or job. For L6 systems the equivalent unit is an epoch (Section 3.2). The term is deliberately neutral because the control (authority issued per assignment and expiring with it) is the same regardless of what the work is called.

5. Why Existing Controls Are Insufficient

Four assumptions underpin most access governance, and all four break under autonomy.

Scope was communicated in natural language. Rules of engagement, task descriptions, and system prompts live in documents and instructions. An agent cannot be held to a document. It can be held to a routing table and an IAM policy.

The operator is trusted to interpret ambiguity. A human developer who finds a production credential in a config file typically pauses. An agent optimizing toward task completion treats it as the unblocking resource. Ambiguity resolves toward continuation, every time, at every step. This begins at L3 and is definitional at L4.

Tooling does not have goals. A build script does not decide to try one more thing. An agent pursuing an objective will pursue it, and the shortest path frequently runs through systems nobody scoped: a shared identity provider, a managed service tenant, a partner connection, a database that happened to accept the credential.

Input is inert. Agents consume attacker-controllable or simply untrustworthy content as a core function: web pages, service banners, file contents, log entries, error messages, dependency documentation, ticket text. Any of it can carry instructions. This is not exotic; a poisoned error message in a build log is enough. The agent is an attack surface, and for Adversarial-mandate agents that surface is pointed at hostile systems by design.

To these, add the mechanisms from Section 2: granted authority is checked at the start and effective authority is never checked again, and level and mandate are assigned once at design review and never re-derived from what the agent can actually do. Most access governance was built for identities that hold a stable set of permissions. Agents accumulate, and agent architectures change under them.

6. Design Principles

Containment is enforced below the agent. System prompts, guardrail instructions, and model-level refusals are defense in depth, never the primary control. Assume the agent's instructions can be overridden, drifted from, or injected into.
Deny by default, expand deliberately. Authorization is an allowlist. Anything not explicitly permitted is unreachable at the network and identity layers.
No standing privilege. Authority is issued per assignment, scoped to the assignment, and expires on a timer whether or not the work completed. For L6, per epoch.
Effective authority must not exceed granted authority. Credentials, tokens, and trust relationships discovered during an assignment do not silently become capability.
Effective level must not exceed granted level. The capability to spawn processes, acquire tools, execute arbitrary code, invoke other agents, or schedule future work is authorized explicitly or made structurally unavailable. Preventing an agent from spawning a process or acquiring a tool requires platform capability that most agent frameworks do not currently expose. Organizations must critically determine what they feel the minimum viable enforcement level is.
Effective mandate must not exceed granted mandate. Escalation-shaped activity by a non-Adversarial agent is a security event, not a tuning problem.
Human gates scale with blast radius. Reading is not writing. Writing is not schema change, deployment, or deletion. Approval thresholds rise as reversibility falls.
Assume compromise of the agent itself. Design so that an agent behaving adversarially, through injection, model failure, or a supply chain issue, cannot reach anything it was not already authorized to reach.
Every action is attributable to a named human. Autonomy distributes execution. It does not distribute accountability. Through a delegation chain, attribution resolves to the human who authorized the root.
Nothing outlives the assignment. Access, artifacts, and infrastructure are created for a purpose and destroyed when that purpose ends.

Principles 4, 5, and 6 are the three drift vectors. The other seven exist to serve them.

7. The Seven Pillars

	Pillar	Governs
C	Conditions of Release	What the agent may touch, and your right to authorize it
U	Untrusted Input	Protecting the agent from hostile content and supply chain risk
S	Supervision & Stop	Human control at machine speed
T	Temporary Authority	What it authenticates as, and for how long
O	Observability & Escalation	Proving what happened, and responding when it goes wrong
D	Disposal & Decommission	Verified teardown of access, artifacts, and infrastructure
Y	Yard & Egress	Where the agent runs and how traffic leaves

The pillars are a mnemonic, not a sequence. Section 10 gives the implementation order, which differs.

Each pillar states universal control objectives, then how the requirement shifts by level and by mandate. Every pillar applies to every profile. The profile determines rigor, not applicability.

Rigor genuinely bottoms out, and the framework should say so plainly rather than pretend every control is a full control at every level. An L1 assistant still has a Supervision requirement; it is "someone can turn it off and it is rate limited," not a tree-wide network-layer kill switch. It still has a Disposal requirement; it is "we know what it wrote and where," not creation-time artifact tracking with per-artifact teardown evidence. The annex control matrix marks these lowest-rigor forms distinctly from full controls and from recommendations. A blank cell in that matrix would mean a pillar does not apply, and there are none.

C: Conditions of Release

Establishing what the agent is allowed to touch, and proving you had the right to authorize it.

Intent. Convert authorization from prose into a machine-enforceable artifact that upstream controls consume directly. If a condition cannot be expressed as data, it cannot be enforced. This is the release order: specific, versioned, signed, and binding on every control downstream.

Control objectives

Conditions are defined as a structured, versioned artifact: systems, data domains, IP ranges, DNS zones, cloud account and subscription IDs, repositories, asset tags, identity domains, and explicit exclusions.
The artifact declares the agent's profile: level ceiling, mandate, and reach ceiling. These are enforced, not descriptive. The level ceiling in particular is enforced by the absence of capability, not by instruction.
The same artifact is the input to network policy, identity scoping, and monitoring. A single source of truth, not three drifting copies.
Authorization is verified for every asset class in scope, with attention to shared-tenancy SaaS, managed services, provider terms, and partner-connected systems.
Exclusion zones are enumerated explicitly: safety systems, medical devices, OT and ICS, production payment paths, regulated data stores, third-party infrastructure.
Conditions changes require re-authorization and are versioned. Mid-assignment expansion is a governed event, not a configuration tweak.
Release is never open-ended. Every set of conditions carries an expiry.
Delegated conditions are derived by restriction from a parent artifact and carry the parent's identifier, so any sub-agent's authority is traceable to a root authorization.

By level. L1 and L2 conditions are mostly data domains and a fixed target list, and can be short. L3 adds the tool set as a first-class conditions element, since the tool set is the action boundary. L4 is where conditions must become genuinely complete, because the agent will explore the edges of whatever you wrote; the common failure is a deployment agent authorized for "the staging environment" without staging being defined as data anywhere. L5 requires the delegation rules of Section 3.6 expressed in the artifact itself. L6 requires per-epoch conditions with an explicit re-authorization step between epochs.

By mandate. Observational conditions are largely read scope. Operational conditions must state write scope precisely, and this is where most organizations are weakest. Adversarial requires the full legal apparatus, since testing something you lack standing to test is a liability event independent of any technical outcome.

Primary failure mode prevented. The agent acts on something you had no standing or intent to authorize, most commonly a shared or partner-owned system that looked internal from where the agent was standing.

Questions to be able to answer.

Where does our authorization boundary live as data?
If a human and the agent disagree about whether a system is in scope, what adjudicates?

U: Untrusted Input

Protecting the agent itself from hostile content and supply chain risk.

Intent. Every agent ingests content it did not author and cannot vouch for. Everything read during an assignment is potentially adversarial, and containment assurance expires the moment the agent changes.

Control objectives

Content the agent ingests (web pages, banners, file contents, logs, tool output, tickets, dependency documentation) is treated as untrusted data, never as instruction. Injection resistance is a tested property, not an assumed one.
The agent supply chain is governed: model versions, tool plugins, extensions, MCP servers, and dependencies are inventoried, pinned, and reviewed.
Any change to the model, agent framework, or tool set triggers re-certification. Containment validated against one version does not transfer to the next; capability and behavior shift between versions.
Tool set changes are re-classified, not just re-certified. A new tool can change the agent's level. Adding a shell tool to an L3 agent is a level change and requires re-authorization at the new level.
Containment is drilled: the organization periodically attempts to break its own agents out of their enclaves and treats success as a priority finding.
Injection resistance is tested against the content the agent will actually encounter in production use.
In L5 systems, inter-agent messages are untrusted input. A sub-agent's output arriving at its parent is content from a system that consumed hostile data. Treat it as such.

By level. L1's exposure is subtle: injected content skews recommendations that humans then act on, with no technical breach to detect. L2's exposure is parameter injection into an author-written sequence. L3 and above can be induced to select and sequence real actions, which is where injection becomes execution. L5 adds injection propagation across the agent tree, and an orchestrator that trusts its children is one compromised child away from full compromise. L6 accumulates exposure over time and can carry an injection across an entire epoch.

By mandate. Observational and Operational agents ingest developer-controlled and often externally sourced content routinely; a poisoned dependency README or build log is a realistic vector. Adversarial agents point themselves at systems that are compromised by definition, making this the pillar where they diverge most sharply. An adversarial agent reads attacker-controlled output as its primary work product. The same is true of security response agents, which are regularly pointed at systems believed to be compromised.

Primary failure mode prevented. The agent becomes the incident: hijacked via injected instruction or compromised through its supply chain, then exercising its legitimate access on someone else's behalf.

Questions to be able to answer.

When did we last try to break our own agent out?
When our model provider ships an update, what happens to our containment assurance?
If a tool was added last week, was the agent re-classified?

S: Supervision & Stop

Keeping a human meaningfully in control at machine speed.

Intent. Autonomy is tiered by consequence. The more irreversible the action, the more human judgment is required, and revocation must always be possible and fast.

Control objectives

Actions are classified into tiers by blast radius and reversibility. A general progression: read, then reversible write, then irreversible write (schema change, deletion, deployment), then privilege change, then actions affecting availability or third parties.
Autonomy thresholds are set per tier, per profile, and per environment. Higher tiers require synchronous human approval, and the highest may be prohibited outright.
A kill switch exists that operates at the network and identity layers, revoking access and severing egress, and does not depend on the agent processing a stop instruction.
The kill switch is tree-wide. Stopping an orchestrator that has already spawned children stops nothing. Revocation targets the assignment identifier and reaches every identity and environment derived from it.
Rate and volume limits constrain the pace of action, providing human-scale reaction time.
Dead-man timers halt assignments that exceed expected duration or lose supervisory contact.
Named humans are on call for the duration of any autonomous run, with unambiguous authority to revoke.

By level. L1 and L2 need little beyond rate limiting and revocation, since there is no run-time decision to supervise. L3 is where action tiering earns its keep: the same coding agent should move freely through reads and test runs while stopping hard at production deployment or schema change. L4 adds a requirement that gating survive replanning; an agent denied one path will try another, and the gate must be on the action class, not the specific route. L5 requires the tree-wide kill switch and a supervision model that does not assume the orchestrator is cooperating. L6 requires the epoch boundary to function as a mandatory supervision checkpoint, since there is no assignment completion to serve as one.

By mandate. For Observational and Operational agents, escalation attempts can themselves trigger a gate. For Adversarial agents that option is unavailable: gating cannot key on escalation and must instead key on target sensitivity, action irreversibility, and third-party reach.

Primary failure mode prevented. Speed outruns oversight. The damaging action completes before anyone reviews it.

Questions to be able to answer.

How long from "we need this to stop" to "it has stopped"?
Who has authority to call it, at 3am, without escalation?
If we kill the parent, do the children die?

T: Temporary Authority

Controlling what the agent can authenticate as, for how long, and on whose accountability.

Intent. This is the pillar that directly enforces principles 4 (effective authority must not exceed granted authority) and 5 (effective level must not exceed granted level). Treat the agent as a non-human identity with the tightest possible grant and a hard expiry, and treat credentials it encounters as material to be reported rather than capability to be used.

Control objectives

Each assignment issues a unique, short-lived non-human identity. No shared service accounts, no reuse across assignments, no standing privilege.
Privilege expires on wall-clock time independent of assignment state. Work that runs long loses its authority rather than extending it silently.
Credentials encountered during an assignment do not become capability by default. Any credential, token, key, or session the agent discovers in the environment is quarantined and reported. Use requires explicit gating against the conditions artifact.
Assumed roles and inherited tokens are scoped down at assumption, not accepted at whatever breadth they happen to carry.
Sub-agents and delegated tasks inherit a subset of authority, never a superset, and never a fresh grant. The delegation mechanism itself must be incapable of minting authority (Section 3.6).
Every action carries a run ID resolvable to a named accountable human and an authorizing manager, through the full delegation chain.
Agent identities are distinguishable from human and production identities in all logs and detection logic, and the identity encodes the profile so that detection can reason about expected behavior.
Secrets available to the agent are minimized and brokered rather than embedded or discoverable on disk.
Granted authority does not exceed the authorizing human's own authority. This would represent an elevation of privilege.

By level. L1 and L2 can often use a static, tightly scoped identity, and per-assignment issuance may be unnecessary ceremony. L3 and L4 need genuine per-assignment ephemeral identity, because these agents will find and follow credential paths. L5 needs the authority algebra enforced mechanically. L6 needs per-epoch reissuance, which is the single control that makes L6 tractable at all.

By mandate. For Observational and Operational agents, credential quarantine should be absolute. An operational agent has no legitimate reason to use a credential it found lying around, and this single control would have prevented the development agent scenario in Section 1. For Adversarial agents, quarantine is the default but gated reuse is a legitimate, authorized capability, because demonstrating credential-driven lateral movement is often the point of the exercise. The gate is what separates a documented finding from an uncontrolled pivot into a system you do not own.

Primary failure mode prevented. Capability accretion. The agent bootstraps from limited access to broad access, or authenticates into an environment nobody scoped using something it found in one that was.

Questions to be able to answer.

What can this agent authenticate as right now, as opposed to what we granted it?
What happens to a credential it discovers at 2am on a Saturday?
Can any delegation path produce an identity more privileged than its parent?

O: Observability & Escalation

Proving what the agent did, and responding coherently when something goes wrong.

Intent. Autonomous action at volume is only defensible if it is fully reconstructable. This pillar produces the record, and defines what happens the moment that record shows something unexpected.

Control objectives

Every agent action is logged with fidelity sufficient to reconstruct the assignment: target, action, tier, timestamp, run ID, parent run ID, and the decision or approval that authorized it.
Logs are written to storage the agent cannot modify or delete, independent of its execution environment.
Effective authority is monitored, not just granted authority. Alert on an agent authenticating as an identity it was not issued, or reaching a system outside its conditions.
Effective level is monitored. Alert on process spawn, tool acquisition, agent invocation, code execution, or scheduled-task creation by an agent whose level ceiling does not permit it. This is the detection layer behind principle 5, and it is usually absent.
Effective mandate is monitored. Alert on escalation-shaped activity (credential access, privilege change, lateral authentication, log manipulation, defense evasion) by an agent with a non-Adversarial mandate. Map these to existing ATT&CK-aligned detections; the agent identity is what makes the alert unambiguous.
SOC deconfliction is established before launch, with a documented process for distinguishing agent activity from genuine intrusion, including a fast path to conclude that an incident is not the agent.
A defined escalation path exists for suspected agent misbehavior, treating it as a security incident rather than a tooling defect, with predetermined severity criteria.
Denied attempts, condition challenges, and near-misses are reviewed as behavioral signal about the agent, separate from the output of its work.
Evidence is retained and structured to satisfy audit, regulatory inquiry, cyber insurance, and legal defense of the authorization.

By level. L1 and L2 logging is simple and mostly exists already. L3 and L4 require the tool-call log to be the system of record, since the tool call is the action. L5 requires the log to reconstruct the tree, not the timeline: parent run IDs, delegation events, and per-sub-agent conditions. A flat log of an orchestrated run is not reconstructable. L6 requires per-epoch reconciliation, since there is no assignment close at which to assemble the record.

By mandate. For Observational and Operational agents, drift monitoring is high-signal and cheap: escalation is a defect, so any instance is worth investigating. For Adversarial agents that signal is unavailable, which is precisely why structural containment carries the load, and why the log must be complete enough to reconstruct authorization after the fact, since it cannot be verified in real time.

Primary failure mode prevented. You cannot prove what happened. The agent did something contested and there is no authoritative record. Or the SOC burns a real incident response on agent activity and misses a concurrent genuine intrusion.

Questions to be able to answer.

If a regulator or partner asked us to prove our agent never touched their systems, could we?
Who decides that anomalous agent behavior is an incident?
Can we reconstruct which sub-agent did a given thing, and under whose authority?

D: Disposal & Decommission

Verified teardown of everything the assignment created.

Intent. Assignments create access, artifacts, and infrastructure. Autonomy creates more of all three, faster, and with less human memory of what was created. Return is not complete until teardown is verified.

Control objectives

Artifacts introduced during assignments (accounts, scheduled tasks, uploaded files, modified configurations, deployed resources, established persistence) are tracked at the moment of creation, not reconstructed from logs afterward.
Removal is verified, not asserted. Cleanup produces evidence of completion per artifact. This is critical. Artifacts of penetration tests not properly cleaned are a nightmare during incident response, where they are often interpreted as indicators of compromise, leading defenders to conclude there may be additional threat actors in the network.
Assignment credentials are revoked and secrets rotated at close, independent of expiry timers.
Execution environments are destroyed and rebuilt rather than reused, preventing accumulation of access across assignments.
Assignment data, which frequently contains sensitive material, is classified, encrypted, access-controlled, and retention-limited with a defined destruction date.
Orphaned artifacts discovered after close are treated as findings against the program, not silently remediated.
Decommissioning an agent platform includes revoking its identities and confirming no residual access persists.
Teardown is tree-wide and bottom-up. Sub-agent environments, identities, and artifacts are destroyed before the parent's, and the parent's close is blocked until every child's teardown is verified.

By level. L1 and L2 create few artifacts and disposal is light. L3 and L4 accumulate quietly and continuously: cloud resources, service accounts, and CI variables created across hundreds of runs, each individually defensible, collectively an unmanaged attack surface. L5 is where artifact tracking most often fails outright, because nobody owns the inventory for resources a sub-agent created. L6 has no close event and depends entirely on epoch-boundary reconciliation.

By mandate. Adversarial agents leave the sharpest artifacts: implants, persistence mechanisms, and staged tooling that are indistinguishable from a real adversary's if not tracked. For these, artifact tracking at creation is not a hygiene control, it is an incident-prevention control.

Primary failure mode prevented. The assignment ends but its access does not. Accounts, resources, and persistence mechanisms remain as unmanaged backdoors that a real adversary can find, and that you will not recognize as your own.

Questions to be able to answer.

What did our agents create last month, and how much of it still exists?
If an attacker used one of our leftover service accounts, would we notice?
Who owns cleanup for a resource created by a sub-agent three levels down?

Y: Yard & Egress

Making scope a property of the network rather than a property of the agent's intentions.

Intent. The agent operates inside a bounded space where movement is genuinely unrestricted, with a single controlled way out. Within the yard, the agent works without friction. Leaving it requires passing a broker that independently enforces the conditions artifact, and containment does not depend on the agent's cooperation.

Control objectives

Agents execute in a dedicated environment with no default route to corporate, production, or internet destinations.
All traffic, including DNS, package installs, model API calls, and telemetry, exits through a mediating proxy or broker that validates each destination against the conditions artifact.
Denied attempts are logged as high-signal security events, not discarded. A pattern of out-of-scope attempts is itself a finding about the agent.
The environment is ephemeral: built per assignment, never a long-lived system accumulating credentials and access.
Model and tool endpoints are explicitly allowlisted; the agent cannot reach arbitrary external services to fetch payloads or exfiltrate collected data.
Allowlisted bidirectional channels are treated as exfiltration paths, because they are. Destination validation cannot help with a model API endpoint that accepts arbitrary content by design. These channels require volume, rate, and content controls of their own, or a broker that owns the call rather than proxying it.
The isolation boundary is sized to the mandate. A shared-kernel container is a reasonable boundary against an agent that is not trying to defeat it. It is not a boundary against an agent whose authorized function is defeating boundaries. Adversarial mandate, and any agent at R3, requires a hypervisor-class or dedicated-host boundary.
Separation is maintained between the agent's execution environment and the systems holding its output.
Sub-agents run inside the parent's yard or a nested subset of it, never in a sibling environment with independent egress. Nesting is a property of policy inheritance at the broker, not of address space: a child subnet inside a parent supernet creates no containment relationship by itself. An orchestrator whose children have their own network paths has no yard.

By level. L1 may need only egress filtering and data-domain restriction. L2's yard is usually inherited from existing pipeline infrastructure and is often adequate. L3 and L4 need genuine network separation, and this is commonly the missing control. A coding agent running on a developer's workstation inherits that workstation's entire network position, VPN routes, and cached credentials, which is how a test-suite task reaches a production database. L5 needs nested yards with a single shared egress point. L6 needs the yard rebuilt at every epoch boundary, since a long-lived yard becomes a long-lived foothold.

By mandate. Adversarial agents need the strictest form: full isolation with brokered egress, because for adversarial agents this pillar is doing nearly all of the containment work by itself. There is no behavioral detection to fall back on and no gate keyed on escalation. The network boundary is the control.

Primary failure mode prevented. The breakout. The agent follows a route, trust relationship, or resolved hostname out of its intended environment and into a network nobody authorized.

Questions to be able to answer.

If this agent were fully compromised right now, what is the complete set of systems it could reach?
Can we demonstrate that answer rather than assert it?

8. Maturity Model

Applied per pillar. Most programs sit at level 0 to level 1 across the board. Organizations should reach level 2 across the majority of their operation before pursuing level 3 anywhere, since containment is limited by its weakest pillar.

Level	Name	Characteristics
0	Ad hoc	Agents run on general-purpose infrastructure or developer workstations. Scope exists in prompts and documents. Containment depends on configuration and operator attention. Profiles are not assigned.
1	Defined	Conditions are written, profiles are assigned, roles are named, approval tiers exist on paper. Enforcement remains largely procedural.
2	Enforced	Conditions are a machine-readable artifact consumed by network and identity controls. Dedicated execution environments with brokered egress. Ephemeral scoped credentials with quarantine of discovered credentials. Working, tree-wide kill switch. Logging complete, tamper-resistant, attributable. Verified teardown. Level ceilings enforced structurally.
3	Adaptive	Effective authority, level, and mandate are continuously monitored against granted. Containment validated through breakout drills. Re-certification and re-classification automated on model and tooling change. Denied-attempt telemetry feeds program risk decisions. Containment evidence producible on demand.

Profiles set the required maturity, not the achievable one. As a reasonable, risk-aligned policy we recommend:

L1 to L2 at R0 to R1 may operate at maturity 1.
L3 and above at R2 requires maturity 2.
Anything Adversarial, or anything at R3, or anything L5 and above requires maturity 2 with the relevant pillars at 3.

9. Roles

Role	Accountability
CISO / Risk Owner	Owns the framework, approves profile definitions and autonomy thresholds, accepts residual risk, and personally approves any prohibited-cell exception.
Agent Authorizer	Named human who authorizes an agent's conditions and profile. Their own authority is the ceiling on the agent's.
Agent Operator / Owning Team	Runs the agent, monitors behavior, holds revocation authority.
Platform & Security Architecture	Owns execution environment design, egress brokering, identity scoping, and enforcement of level ceilings and the delegation algebra.
Legal / Compliance	Validates authorization for each asset class, particularly shared-tenancy and partner-connected systems. Owns standing authorization for Adversarial mandate.
SOC / Detection	Deconfliction, agent-activity identification, and independent monitoring of the three drift vectors.
Assignment Closer	Verifies teardown and signs off that the environment is clean. Should not be the operator.
Agent Classifier	Assigns and periodically re-derives the profile from the agent's actual capability rather than its documentation. Independent of the owning team.

The operator and the authorizer should not be the same person, and neither should sign off on their own cleanup. For internal engineering agents this is frequently violated by default, since the team that deploys the agent also defines its permissions and reviews its work. The Agent Classifier role exists because self-classification reliably produces the lowest defensible level, and because level drift is invisible to the team that introduced it.

10. Adoption Path

Critical: Note that the adoption path differs from the mnemonic ordering. The adoption path in this section is roughly listed in dependency order.

Inventory and classify. Find every agent already running, including trials, open source experiments, and agentic features quietly added to existing platforms. Assign each a profile. Classify by capability, not by intent: ask what tools it holds, whether any provide arbitrary execution, whether it can spawn or invoke, and what its network position actually reaches. Most organizations find more agents than expected. The author has consulted with several organizations with otherwise mature security programs whose agentic inventories were low by two orders of magnitude. Many other orgs that believed they had mostly L1 and L2 agents have learned that L3 and L4 Operational dominate their inventories, with several finding that a meaningful fraction of their nominal L3 agents hold an arbitrary-execution tool.
Establish the conditions artifact. Require machine-readable artifacts, versioned, single source of truth, carrying the agent's profile. Everything downstream consumes the machine-readable profile. It is critical that this data can be read by build systems, deployment systems, and most importantly security systems.
Remove agents from general-purpose infrastructure. Use dedicated execution environments with brokered egress. This is the highest-leverage control and the one that makes containment independent of agent behavior.
Enforce level ceilings. Remove or gate arbitrary-execution tools, dynamic tool acquisition, process spawn, and agent invocation for any agent not authorized above L3. This is the cheapest large reduction in exposure available, and it is usually skipped.
Scope identity and quarantine discovered credentials. Ephemeral per-assignment identities, down-scoped on role assumption, subset-only delegation.
Tier autonomy and wire the kill switch. Validate that revocation works from the network layer, under load, and reaches sub-agents.
Establish observability and deconfliction. Require tamper-resistant logging, drift monitoring on all three vectors, and a working relationship with the SOC before scaling autonomy.
Instrument teardown. Ensure artifact tracking at occurs at creation and removal is verified at close, tree-wide and bottom-up.
Harden against untrusted input and drill. Perform injection resistance testing, breakout exercises, re-certification and re-classification triggers.
Address L5 and L6 deliberately. Delegation algebra and epoch boundaries are architectural, not configuration-time controls. Do not allow L5 and L6 systems into production ahead of the platform work that contains them.
Measure and report. See the section on metrics for ideas on how to measure.

11. Candidate Program Metrics

Inventory and classification

Agents inventoried and classified, versus estimated total
Agents whose profile has been independently verified within the last quarter
Agents nominally below L4 that hold an arbitrary-execution or dynamic-tool-acquisition capability

Drift

Instances of effective authority exceeding granted authority, detected and trending
Instances of level drift detected: unauthorized process spawn, tool acquisition, or agent invocation
Instances of mandate drift detected: escalation-shaped activity by non-Adversarial agents
Credentials discovered by agents: quarantined versus used, with gating evidence

Containment

Out-of-scope attempts blocked, per agent and over time
Percentage of agents executing from ephemeral, network-separated environments
Percentage of agent credentials that are ephemeral and assignment-scoped
Measured time from revocation decision to confirmed cessation of activity, including sub-agents
Breakout drill outcomes and time since last drill

Lifecycle

Artifact cleanup verification rate, and orphaned artifacts discovered post-close
L6 systems operating within policy epoch length
Agents running on a re-certified model and tooling version
Mean time to deconflict suspected agent activity from genuine intrusion

12. Known Challenges in Implementing CUSTODY

Embedded agentic features. Agents arriving as features inside existing SaaS tools are outside normal deployment governance and frequently outside enterprise inventories entirely. They also cannot be profiled from the outside: the vendor knows the level, the customer does not. This may require a separate disclosure standard.
Third-party agents. Vendors running their own agents against or inside your environment require a procurement and contractual control set not covered here. The profile model is a plausible basis for a contractual disclosure requirement.
Cross-organizational delegation. When your L5 orchestrator invokes a vendor's agent, the authority algebra has to hold across a trust boundary it cannot enforce. And be honest: how much do you trust your vendor?
Regulatory posture. Whether autonomous action triggers notification obligations in some jurisdictions and sectors remains unsettled.
Provider terms. Cloud and SaaS authorization terms were written for human-paced activity and do not clearly address autonomous agents, let alone agents that spawn agents.

Appendix A: Glossary

Agent. A system that pursues an objective through multiple autonomous steps, selecting its own actions and tools. Corresponds to L3 and above; L1 and L2 are included in this framework's scope because they are routinely mislabeled as agents and routinely mislabeled as safe.

Assignment. A scoped unit of agent work with defined conditions and an expiry. Called an engagement in offensive security, a task or run elsewhere. For L6 systems, see epoch.

Authority accretion. The gradual expansion of an agent's effective authority beyond its granted authority through credentials, tokens, and trust relationships acquired during operation.

Authority ceiling. The rule that an agent's granted authority may not exceed that of the human who authorized it.

Breakout. Any activity by an agent outside its authorized boundary, whether through routing, trust relationships, credential reuse, or delegation.

Capability level. L1 to L6. What the agent structurally does, and therefore how much of its behavior can be constrained before it runs. See Section 3.1.

Conditions artifact. The machine-readable, versioned definition of authorized targets, exclusions, profile, and expiry consumed by enforcement controls.

Effective authority. Everything an agent can actually reach and act upon at a given moment, as distinct from what it was granted.

Egress broker. The mediating control through which all agent traffic passes, validating destinations against the conditions artifact independently of the agent.

Epoch. A bounded operating period for an L6 system, ending in mandatory identity revocation, environment rebuild, artifact reconciliation, and re-authorization. The L6 substitute for an assignment.

Granted authority. The access explicitly issued to an agent for an assignment.

Level drift. An agent operating at a higher capability level than the one it was contained for, typically through arbitrary-execution tools, dynamic tool acquisition, process spawn, or agent invocation.

Mandate. Observational, Operational, or Adversarial. What the agent is authorized to be for, and therefore whether privilege escalation is a defect or a function. See Section 3.3.

Mandate drift. A non-Adversarial agent performing escalation-shaped work: credential harvesting, lateral movement, privilege change, or control evasion.

Orphaned artifact. Any account, resource, task, or configuration change created during an assignment and discovered after close.

Profile. The triple of level, mandate, and reach that determines an agent's required controls. Written L4/Operational/R2.

Prompt injection. Instructions embedded in content the agent ingests, intended to alter its behavior.

Reach. R0 to R3. What the agent's environment can cost you when containment fails. Measured by network and identity position, not by intent. See Section 3.4.

Re-certification. Revalidation of containment assurance following a change to the model, agent framework, or tooling.

Re-classification. Re-derivation of the agent's profile following a change to its tools, delegation capability, or network position. Distinct from re-certification: re-certification asks whether the containment still works, re-classification asks whether it is still the right containment.

Revocation. Withdrawal of an agent's authority and network reachability, enforced below the agent and not dependent on its cooperation. For L5, tree-wide.

Yard. The bounded execution environment within which an agent moves without friction, with a single brokered exit.

Appendix B: CUSTODY Work-Release / Agentic Security Comparisons

Work release requirement	Equivalent agentic security requirement
Release is granted for a specific job or approved purpose.	The agent receives authority for a defined assignment and mandate.
The authorized employer and work location are identified in advance.	Permitted systems, data domains, networks, tools, and environments are explicitly enumerated.
Travel is limited to an approved route and destination.	Network access and egress are restricted to destinations allowed by the conditions artifact.
Release begins and ends at specified times.	Credentials, execution authority, and network access have hard wall-clock expirations.
The individual cannot extend the release independently.	The agent cannot renew its own credentials, extend its run, or expand its authorization.
A supervising authority monitors compliance.	Human supervisors and security systems monitor actions, drift, denied attempts, and effective authority.
Certain locations, activities, and contacts remain prohibited.	Exclusion zones, prohibited actions, sensitive systems, and third-party environments remain structurally unreachable.
Violations can result in immediate revocation.	A kill switch revokes identity and network access without requiring the agent's cooperation.
The individual remains accountable to a named authority.	Every action is attributable through the run and delegation chain to a named human authorizer.
Permission does not transfer automatically to another person.	A sub-agent receives only a restricted subset of the parent's authority and cannot receive a fresh grant.
The individual must return when the authorized period ends.	The agent's execution environment is terminated when the assignment or epoch ends.
Tools, property, and changes associated with the work are inspected or reconciled.	Accounts, files, services, scheduled tasks, configurations, and other artifacts are inventoried and removed through verified teardown.
A new release requires a new authorization decision.	A new assignment, changed conditions, or a new epoch requires explicit reauthorization.

Legal notice

CUSTODY™ is a trademark of MalwareJake LLC. That is the only mark asserted. No other proprietary right is claimed in the record structures, field names, control descriptions, or algebra defined here.