ADCS — Agent Delegation Chain Specification
An open spec for agent-to-agent (A2A) delegation chains. Defines a JSON data structure and runtime semantics so audit logs from any agent platform compose, governance products converge on a common shape, and procurement teams have one artifact to ask for.
Version: 0.1.0 (draft) · Spec text · JSON Schema · GitHub repo · Reference implementation · Announcement post
What ADCS specifies
{
"originSub": "auth0|alice@acme.com",
"originClaims": { "email": "alice@acme.com" },
"links": [
{
"agentProfileId": "strategy-orchestrator",
"agentRunId": "run_orch_2026041610",
"agentName": "Strategy orchestrator",
"effectiveScopes": ["web.*", "internal-research.delegate"],
"effectiveTools": ["web_search", "research.delegate"],
"remainingBudgetCents": 350,
"delegatedAt": "2026-04-16T10:00:00Z"
},
{
"agentProfileId": "remote-researcher",
"agentRunId": "run_res_2026041611",
"agentName": "Remote researcher",
"effectiveScopes": ["web.*"],
"effectiveTools": ["web_search", "hn_search"],
"remainingBudgetCents": 100,
"delegatedAt": "2026-04-16T10:01:23Z"
}
],
"depth": 2
}
That’s the data structure. The spec defines six rules for how links[] grows safely.
The six normative rules
| Rule | Definition | Why |
|---|---|---|
| Origin invariant | originSub MUST NOT change at any depth |
Auditability: every action traces to one accountable human |
| Scope intersection | effective_child = intersect(effective_parent, profile_child). Permissions only narrow. |
Least-privilege at every hop, by construction |
| Budget propagation | budget_child = min(remaining_parent, max_child) |
Runaway loops in deep chains are mathematically bounded |
| Cycle prevention | An agent MUST NOT delegate to a profile already in the chain | No mutual recursion, no infinite delegation loops |
| Type vs runtime identity | Distinct agentProfileId (stable type) and agentRunId (per-execution) |
Audit logs correlate the calls of one specific run, even with parallel concurrency |
| Audit emission shape | Every governed tool call MUST emit an entry containing the chain | Logs are reconstructable; SIEM integration is a query, not a custom pipeline |
The full normative spec text is at SPEC.md. It’s ~2,500 words and uses RFC 2119 conformance language.
How to implement
- Read the spec text (
SPEC.md) - Validate against the JSON Schema (
schema/chain.schema.json) - Run the conformance test vectors (
conformance/) — JSON files with(input, expected_output)for every operation - Emit audit entries containing the chain (§9)
- Optional: wrap chains in a Biscuit or signed JWT envelope for cryptographic verifiability
The reference implementation (delegation.ts) is ~150 lines of TypeScript. Most production implementations should fit in a similar size.
How ADCS relates to other specs
| Other spec | What it covers | Relationship to ADCS |
|---|---|---|
| A2A Protocol | Transport, discovery, capability negotiation | A2A invocations MAY carry an ADCS chain in a header or message-part. Complementary. |
| MCP | Tool invocation between agent and tool | Every governed MCP tools/call emits an ADCS audit entry. Wraps MCP. |
| RFC 8693 | Nested act claims |
ADCS chains MAY be expressed as JWTs with nested act. Profile of. |
| OAuth Transaction Tokens (draft) | Scope monotonic reduction | ADCS adds set-intersection (stricter) + budget. Strictly stronger. |
| Macaroons / Biscuits | Capability tokens with attenuation | ADCS chains MAY be wrapped in Biscuit. Compatible envelope. |
| OIDC-A (preprint) | delegator_sub + delegation_chain claim names |
ADCS uses different vocabulary to avoid OIDC namespace collision. Acknowledges as prior art. |
| Agent Identity Protocol (preprint) | IBCTs with Biscuit + Datalog | ADCS is JSON-first, not Datalog-first. Sister spec. |
| OpenTelemetry GenAI semconv | Span attributes for agent invocation | ADCS audit entries map to OTel attributes. Emits to. |
Why publish it as a spec
We were already operating it as our internal chain shape. Publishing it as a spec does three things:
- Reduces a procurement objection. Customers asking “what’s the data shape for your audit chain?” now get “we follow ADCS v0.1, here’s the JSON Schema” — not “our own format”.
- Bets on standards-first market shaping. When other tools adopt the same shape, audit logs compose across vendors. When they don’t, ACP is still the reference implementation. Either outcome is preferable to fragmenting into N proprietary chain formats.
- Forces design discipline. A public spec can’t have implementation accidents in it — every field has to be justifiable. Writing the spec made the implementation cleaner.
Where it’s going
- v0.1.x — early adopter implementations and feedback. Field names and semantics may shift as implementers report what’s awkward. Conformance vectors expand.
- v1.0 — once the shape has stabilized through real use, commit to backwards-compatibility guarantees.
Beyond that we’ll let adoption decide. If multiple vendors implement ADCS, formalizing it through a standards body becomes worth doing. If they don’t, it remains a clear public spec backed by a reference implementation — still valuable, just narrower in reach.
Who should care
- Agent platform builders — if you’re shipping CrewAI / LangGraph / Anthropic SDK / OpenAI Agents SDK to production, the chain you’re already producing internally probably maps to this shape. Adopting ADCS makes your audit logs portable.
- Governance vendors — if you’re Aembit, Cyata, Astrix, Zenity, Salt, Noma, Skyrelis, Tenet, Aiceberg, Singulr, KonaSense, SurePath — none of you currently publish a chain schema. ADCS gives you one.
- CISOs evaluating agent platforms — start asking “does this product implement ADCS?” in your procurement. Today no vendor has a chain schema; in 6 months you should expect them to.
- Standards-body participants — if you’re in IETF OAuth WG or Linux Foundation AAIF, this is intended as input to whatever ratified spec eventually lands there. Consume, fork, fold in.
How to participate
Open an issue on agentic-control-plane/delegation-chain-spec. Implementation reports especially welcome.