Skip to content
Agentic Control Plane

Introducing ADCS — an open spec for agent-to-agent delegation chains

David Crowe · · 14 min read
spec delegation-chain a2a governance standards

Today we’re publishing ADCS v0.1 — the Agent Delegation Chain Specification. It’s an open spec that defines a JSON data structure and runtime semantics for the chain of agent-to-agent (A2A) hops that begins with a human and extends through autonomous agents.

Spec text: SPEC.md JSON Schema: schema/chain.schema.json Reference implementation: Agentic Control Plane gateway (in production) License: CC BY 4.0 (spec text), MIT (schema, examples, conformance vectors)

This post explains what the spec covers, the six design opinions baked into it, the tradeoffs each opinion accepts, and how ADCS relates to the other agent-identity work in flight.

TL;DR

A2A is real now. Google’s A2A Protocol has 50+ launch partners and is donated to the Linux Foundation. CrewAI ships first-class A2A delegation. Anthropic’s Agent SDK has subagents. OpenAI’s Agents SDK has handoffs. Bedrock AgentCore models delegated identity with Act: Agent claims.

What’s missing — and what every governance product is reinventing in incompatible ways — is the shared data shape for the chain itself. Who started this work? Which agents touched it? What permissions narrowed at each hop? How much budget remains? Was a cycle prevented? Today every product invents its own answer; audit logs don’t compose across vendors.

ADCS is one normative answer. It’s not a product. It’s a JSON shape plus a small set of rules:

{
  "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 (CrewAI A2A)",
      "effectiveScopes": ["web.*"],
      "effectiveTools": ["web_search", "hn_search"],
      "remainingBudgetCents": 100,
      "delegatedAt": "2026-04-16T10:01:23Z"
    }
  ],
  "depth": 2
}

That’s the load-bearing artifact. The rest of the spec defines how links[] grows safely — what gets intersected, what gets propagated, what’s prevented, what’s audited.

Why we wrote it

We’ve been building Agentic Control Plane, a governance product for AI agents. Production customers were asking us a question we couldn’t answer cleanly: “What’s the data shape for your delegation chain audit? Will my SIEM be able to correlate across agent vendors?” The honest answer was “our shape, and not yet.”

That’s a procurement objection. It also became a strategy decision. Either we keep our chain shape internal — fine for our customers, but it leaves the audit surface vendor-locked — or we publish it as a spec and bet that other tools converge on it.

The state of the art when we surveyed it (April 2026) is fragmented:

  • Google’s A2A Protocol explicitly punts authorization to higher layers: “A2A does not define how the authorization must be performed.” Real spec, real adoption — leaves the chain hole open.
  • Anthropic’s MCP and its authorization spec cover tool calls between an agent and a tool. Sub-agent behavior is host-side and out of scope.
  • IETF OAuth Token Exchange (RFC 8693) introduced the act claim and nested actor representation in 2020. Closest existing primitive. Doesn’t cover budget, doesn’t define agent-typed identity, doesn’t have audit emission requirements.
  • IETF Transaction Tokens (draft) adds monotonic scope reduction across call chains. Real WG item. Sibling for-agents draft retargets it for AI. Compatible with ADCS — we’re a profile of the same idea.
  • Macaroons (Google, 2014) and Biscuits (Eclipse) provide capability tokens with cryptographic attenuation. The right cryptographic envelope; the wrong layer for a JSON data shape standard.
  • OIDC-A (arxiv preprint, Sep 2025) — defines delegator_sub and delegation_chain claims with OIDC branding. One author, GitHub repo, no working group. Worth acknowledging; not yet a standard.
  • Agent Identity Protocol (arxiv preprint) — uses Biscuit + Datalog for chained delegations. Mathematically powerful; targeted at academic / advanced users.
  • Authenticated Delegation paper (MIT/Anthropic, Jan 2025) — motivates the need; frames the gap. Doesn’t ship a normative wire format.
  • AWS Bedrock AgentCore uses RFC 8693 Act: Agent claims internally. Vendor-specific.

Nothing real covers identity propagation + scope narrowing + budget + chain shape + open schema, all together. That’s the gap.

The six design opinions

ADCS is opinionated. Opinions are how a spec creates leverage — a spec without opinions describes data; a spec with opinions describes behavior. Here are the six load-bearing opinions, with honest tradeoffs.

1. originSub is invariant

The human at the root of the chain MUST NOT change at any depth. Every hop preserves originSub and originClaims exactly.

Why we picked this. Auditability is a one-question test: can you trace this action to a single accountable human? The invariant guarantees yes, structurally. There’s no clever delegation trick that loses the human.

Tradeoff we accept. Some delegation models want “actor replaces principal” semantics — “I’m acting as the role I just delegated to.” That’s useful for some authorization patterns (Kubernetes RBAC for example uses impersonate). ADCS rejects this in favor of preservation; if you need impersonation, you create a new chain.

2. Scope and tool narrowing is set intersection

A child agent’s effective permissions = intersect(parent_effective, child_profile). Permissions can only narrow.

Why we picked this. Set intersection is the strictest possible interpretation of least-privilege. Wildcard support (github.*) keeps it ergonomic; the result is mechanically auditable — for any chain, you can prove what each link can and cannot do.

Tradeoff we accept. OAuth Transaction Tokens use “scope of the token is equal or less than the scope of the subject_token” — a string-subset rule that’s slightly looser. ADCS’s set-intersection is strictly stronger but rejects some patterns (e.g., parent says github.*, child profile says github.repos.read — Transaction Token allows it; ADCS allows it too via wildcard match). The cases that diverge are obscure and we judged the strictness worth the simplicity.

3. Budget propagation is a first-class field

child_budget = min(parent_remaining, child_max). When a child’s budget hits zero, its tool calls are rejected with a structured error.

Why we picked this. Runaway loops in deep multi-agent chains are the #1 production failure mode we’ve seen. Bounding them at the data-structure level — not at a separate rate-limiter, not at a model-side sampling parameter — is cheap, load-bearing, and impossible to forget.

Tradeoff we accept. Nobody else has this. We’re inventing primary art. Budget-as-cents is also opinionated: it assumes a cost model. Some teams want budget-as-tokens, budget-as-time, or budget-as-API-calls. v1.0 may add a typed BudgetUnit enum; v0.1 commits to cents because most LLM cost reasoning happens in dollars and integer cents avoids floating-point. Honest call: if your governance pillar is rate limiting, not cost, you may find this field over-specific. We think the cost framing is more universally useful and includes rate-limiting as a special case (set max_budget at zero past N calls).

4. Type identity (agentProfileId) is distinct from runtime identity (agentRunId)

Audit logs need to correlate the calls of this specific execution, not just calls by any instance of agent X.

Why we picked this. Two parallel runs of the same agent — call them researcher-instance-A and researcher-instance-B — should produce two distinct chains. If your audit log conflates them, you can’t reconstruct what happened in a multi-tenant or high-concurrency setting.

Tradeoff we accept. Two identifiers per link is more verbose than one. OIDC-A’s delegator_sub collapses these into one claim. We chose verbosity for forensic clarity. Honest call: for single-tenant deployments with no concurrency, one identifier would suffice. Most production deployments aren’t single-tenant.

5. Cycle prevention is “target appears in chain”, not just depth limit

An agent MUST NOT delegate to a agentProfileId that already appears anywhere in the current chain.

Why we picked this. Depth-limiting bounds compute cost. Cycle prevention bounds reasoning loops. They’re different failure modes — an agent that re-invokes itself through three intermediaries can still be shallow but pathological. ADCS catches it at the structural level.

Tradeoff we accept. This rule is strict. It prevents legitimate patterns like “supervisor → coder → supervisor → tester” where the supervisor is the orchestrator that explicitly fans-out and fans-in. To support that pattern, you’d need a supervisor profile that’s marked as a coordinator — and then either two profile IDs (orchestrator + worker) or an exception clause. v0.1 keeps the strict rule; v0.2 may add an opt-in coordinator: true flag. Honest call: if your topology is supervisor-centric, this rule will bite you. The workaround is to model the supervisor as a profile distinct from the workers it coordinates.

6. JSON-first, not Datalog-first

The spec specifies a JSON data shape. Cryptographic envelopes (Biscuit, JWT) are optional; the data is the contract.

Why we picked this. A delegation chain has multiple audiences: SOC analysts reading audit logs, junior engineers debugging an integration, compliance officers running queries against SIEM exports, AI-driven incident-response copilots reasoning about the chain. JSON is the lowest-friction shape that all of them can read. The Agent Identity Protocol uses Biscuit + Datalog; that’s mathematically more expressive but excludes most of those audiences without specialized tooling.

Tradeoff we accept. JSON is unsigned. Anyone with write access to the audit log could fabricate a chain. ADCS spec text addresses this in §10 — “Implementations MAY transmit chains in any envelope… When transport over an untrusted channel is required, implementations SHOULD use a signed envelope (JWT or Biscuit) so each link can be cryptographically verified.” The data shape is decoupled from the cryptographic verification layer; both can exist. Honest call: if your threat model includes a malicious gateway, you need the Biscuit envelope. ADCS doesn’t mandate it because most threat models don’t.

How ADCS relates to other specs

Spec Covers What ADCS adds Relationship
A2A Protocol Transport, discovery, capability negotiation Chain semantics A2A explicitly leaves to a higher layer Layers on top. A2A invocation MAY carry an ADCS chain in a header or message-part.
MCP Tool invocation between agent and tool Chain context that wraps each MCP call Wraps MCP. Every governed MCP tools/call emits an ADCS audit entry.
RFC 8693 OAuth Token Exchange Nested act claims for delegation Scope intersection + budget + tool sets + runtime identity Profile of. ADCS chains MAY be expressed as JWTs with nested act.
OAuth Transaction Tokens Scope monotonic reduction across call chains Set-intersection (stricter), budget, agent-typed identity Strictly stronger intersection rule + budget.
Macaroons / Biscuits Capability tokens with cryptographic attenuation Standardized JSON shape for the chain payload Compatible envelope. ADCS chains MAY be wrapped in Biscuit.
OIDC-A delegator_sub + delegation_chain claim names Concrete data shape, budget, runtime identity, conformance vectors Acknowledges as prior art, chooses different vocabulary to avoid OIDC namespace collision.
Agent Identity Protocol IBCTs with Biscuit + Datalog JSON-first, simpler audit shape, budget propagation Sister spec. Different design choices for different audiences.
OpenTelemetry GenAI semconv Span attributes for agent invocation Chain-level attributes the semconv doesn’t cover yet Emits to. ADCS audit entries map to OTel attributes.

ADCS is one piece of the agent governance puzzle. It does not specify how agents authenticate, how they discover each other, or how they execute. It specifies the chain that records what happened, with the small set of rules that make the chain composable across vendors.

Reference implementation

The reference implementation is the Agentic Control Plane gateway, in production today:

  • delegation.ts — intersectScopes, intersectTools, computeChildBudget, detectCycle, buildChildChain. This is the file the spec was reverse-extracted from.
  • hookGovernance.ts — the four-layer policy merge (workspace → role → agentType → user) with chain context.
  • mcp/logging.ts — audit emission with the chain serialized into every entry.

Conformance test vectors at conformance/ verify the reference implementation produces the documented output for every operation. Other implementations should pass the same vectors.

Roadmap

  • 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 whether formalizing through a standards body is worth doing. If multiple vendors implement ADCS, that conversation becomes natural. If they don’t, the spec remains a clear public artifact backed by a reference implementation.

How to participate

We’re seeking implementer feedback. Open an issue on agentic-control-plane/delegation-chain-spec with:

  • A use case ADCS doesn’t yet cover
  • An ambiguity in the spec text
  • A field name you’d argue against
  • A normative semantic you’d argue for
  • An implementation report — “we built ADCS in [language] — here’s what was hard”

If you’re at one of the agent-governance vendors (Aembit, Cyata, Astrix, Zenity, Salt, Noma, Skyrelis, Tenet, Aiceberg, Singulr, KonaSense, SurePath, etc.), we’d especially value feedback. None of you currently publish a chain schema. If ADCS is the right shape, adopting it costs you nothing and gives the industry a common artifact. If it’s not, the public issue is the place to make the case.

What this changes for ACP

For us specifically, this changes the conversation. ACP is no longer just a governance product — it’s the reference implementation of a public spec. That changes how we engage with enterprise procurement (“we follow our own published spec, here’s the JSON Schema”), how we engage with auditors (“the chain shape is normative”), and how we engage with the rest of the agent-tooling ecosystem (“adopt this if you want our customers’ SIEM exports to compose with yours”).

If you’re shipping multi-agent systems to production, the conversation changes for you too: you can ask vendors “do you implement ADCS?” and have a concrete answer to evaluate. Today the question doesn’t have an answer because no vendor publishes a chain schema. We’d like that to change.

Spec is at v0.1.0 and explicitly draft. Field names and semantics MAY change before v1.0. We’re shipping this now because the category is forming and we’d rather have one good shared shape than five proprietary ones.

Share: Twitter LinkedIn
Related posts

← back to blog