Eleven steps, in dependency order.
The adoption path deliberately differs from the CUSTODY mnemonic. The letters are a memory aid. This is the order in which the work actually depends on itself.
-
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: what tools does it hold, does any provide arbitrary execution, can it spawn or invoke, and what does its network position actually reach? Most organizations find more agents than expected, and many that believed they had mostly L1 and L2 find L3 and L4 operational dominating instead.
-
Establish the conditions artifact
Machine-readable, versioned, single source of truth, carrying the agent's profile. It is critical that this data can be read by build systems, deployment systems, and most importantly security systems. Everything downstream consumes it.
-
Remove agents from general-purpose infrastructure
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
Tamper-resistant logging, drift monitoring on all three vectors, and a working relationship with the SOC before scaling autonomy.
-
Instrument teardown
Artifact tracking occurs at creation and removal is verified at close, tree-wide and bottom-up.
-
Harden against untrusted input, and drill
Injection resistance testing, breakout exercises, and 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 candidate metrics below.
Applied per pillar, because containment is limited by its weakest one
Most programs sit at level 0 to level 1 across the board. Reach level 2 across the majority of your operation before pursuing level 3 anywhere.
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.
Defined
Conditions are written, profiles are assigned, roles are named, approval tiers exist on paper. Enforcement remains largely procedural.
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.
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.
As a reasonable, risk-aligned policy: L1–L2 at R0–R1 may operate at maturity 1. L3 and above at R2 requires maturity 2. Anything adversarial, anything at R3, or anything L5 and above requires maturity 2 with the relevant pillars at 3.
Eight accountabilities, two of which are separations of duty
| 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. |
↔ scroll table
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.
What to put on the slide
- 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
- Effective authority exceeding granted authority, detected and trending
- Level drift detected: unauthorized process spawn, tool acquisition, or agent invocation
- Mandate drift detected: escalation-shaped activity by non-adversarial agents
- Credentials discovered by agents: quarantined versus used, with gating evidence
- 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, including sub-agents
- Breakout drill outcomes and time since last drill
- 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
Where CUSTODY is hard to implement, stated plainly
Embedded agentic features
Agents arriving as features inside existing SaaS tools are outside normal deployment governance and frequently outside enterprise inventories entirely. They 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 by the framework. 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 and provider terms
Whether autonomous action triggers notification obligations remains unsettled in some jurisdictions and sectors. Cloud and SaaS authorization terms were written for human-paced activity and do not clearly address autonomous agents, let alone agents that spawn agents.
CUSTODY v1.0
Full control objectives, the delegation algebra, the maturity model, glossary, and the work-release comparison table. Open, vendor neutral, and free to adopt.