PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems

1.1. Problem

Agentic AI systems spawn sub-agents dynamically. Current identity frameworks fail three tests:¶

1. Attribution -- when an orchestrator spawns a sub-agent to book flights and another to file expenses, both share the orchestrator's ambient credentials. Incident response cannot determine which sub-agent took which action.¶
2. Attenuation -- sub-agents typically inherit all parent authority. AAuth explicitly rejects scope attenuation (draft-hardt-aauth-protocol-01 Appendix C.3.7). Bearer-token and OAuth flows have no delegation narrowing primitive.¶
3. Enforcement -- even protocols that define attenuation (AIP) defer aggregate budget enforcement to "the orchestration platform at runtime" (draft-prakash-aip-00 Section 7.4), leaving a single-layer guard vulnerable to orchestrator compromise.¶

1.2. Non-Goals

• Replacing SPIFFE/WIMSE workload identity for in-cluster service-to-service auth. PEDIGREE is an upper layer that delegates from a SPIFFE-bearing root.¶
• Defining a user-authentication protocol. OIDC/OAuth flows bootstrap the root consent; PEDIGREE governs what happens after.¶
• Specifying an authorization policy language. PEDIGREE accepts Cedar (RECOMMENDED), Datalog, or Rego as mandate policy formats.¶

1.3. Related Work

The following table compares PEDIGREE with existing protocols across key delegation and enforcement dimensions.¶

3.1. Identifier Schemes

PEDIGREE defines two identifier schemes:¶

Named (registry-backed)

Format: pedigree:name:<deployment>/<agent-id>¶

Example: pedigree:name:glyphzero/trading-orchestrator-7f3a¶

Self-certifying (registry-free)

Format: pedigree:key:ed25519:<multibase-public-key>¶

Example: pedigree:key:ed25519:z6MkpZ...¶

RECOMMENDED for sub-agents with lifetimes under 5 minutes.¶

3.2. Root of Trust

Each chain terminates at a root principal (human, identified via OIDC/OAuth). The primary agent's PEDIGREE carries the root's sub claim and a signature over the initial consent.¶

4.1. Header

{
  "alg": "EdDSA",
  "typ": "pedigree+jwt"
}

4.2. Payload (SIT Claims)

The following is the set of claims carried in a SIT payload:¶

{
  "iss": "<issuer identity>",
  "sub": "<this agent's identity>",
  "jti": "<token uuid>",
  "iat": 1712345678,
  "exp": 1712349278,
  "pedigree_version": "0.1",
  "agent_pub": "<base64url ed25519 pubkey>",
  "parent_chain": ["<parent jti>", "<grandparent jti>"],
  "delegation_depth": 2,
  "scopes": ["read:cal", "write:cal"],
  "mandate": {
    "format": "cedar",
    "policy_set": "permit(principal, action == PedigreeAction::\"read_file\", resource);"
  },
  "consent_chain": ["<consent id>"],
  "ceiling_ref": "sha256:<operator ceiling hash>",
  "completion_bindable": true
}

4.3. Required Invariants

1. delegation_depth == len(parent_chain)¶
2. scopes MUST be a subset of the immediate parent's scopes.¶
3. exp - iat MUST NOT exceed the parent's remaining lifetime.¶
4. mandate.policy_set MUST narrow or equal the parent's mandate under the static-analysis check of Section 7.¶

5.1. Mint

To mint a child SIT, the parent:¶

1. Verifies its own SIT is unexpired and not revoked.¶
2. Chooses a subset of its scopes.¶
3. Generates (or receives) the child's public key.¶
4. Computes a child mandate that is provably narrower than the parent's (see Section 7).¶
5. Appends its own jti to the child's parent_chain.¶
6. Signs the child JWT with its own private key.¶

5.2. Verify (Strict)

Verifiers MUST:¶

1. Cryptographically verify the leaf SIT against the issuer's public key.¶
2. Retrieve each parent JWT referenced by parent_chain and cryptographically verify each.¶
3. Check each parent's sub equals the corresponding parent_chain entry of the descendant.¶
4. Check each hop's scopes is a subset of the prior hop's scopes.¶
5. Check each hop's mandate is a narrowing of the prior hop's mandate via static analysis (Section 7).¶
6. Check the leaf's ceiling_ref hash matches the operator's current ceiling or a published prior version within grace period.¶

5.3. Parent-Swap Resistance

Because verification re-verifies each parent against the issuer's public key, an attacker cannot substitute a same-scope parent from a different chain. AIP's Biscuit append-only semantics trust block signatures and do not re-verify upstream; PEDIGREE's explicit re-verification catches this attack class.¶

7.1. Narrowing Check

A child mandate M_c narrows a parent mandate M_p if and only if:¶

forall (action, resource).
  M_c.permits(action, resource) => M_p.permits(action, resource)

7.2. Static Analysis

When mandate.format == "cedar", implementations MUST emit a static-analysis proof that M_c narrows M_p. Cedar's published analyzer (AWS 2024) suffices. The proof artifact MAY accompany the SIT as a narrowing_proof field referencing the proof by content hash.¶

This static-proof primitive is absent from AIP (Biscuit semantics enforce narrowing imperatively but do not emit a verifiable artifact).¶

8.1. Purpose

A completion block cryptographically binds the outcome of an agent's action to the delegation chain that authorized it, enabling downstream verifiers to prove a result came from an authorized chain without trusting out-of-band audit logs.¶

8.2. Format

{
  "jti": "<completion jti>",
  "parent_sit": "<sit jti>",
  "status": "completed",
  "result_hash": "sha256:<hex>",
  "verification_status": "self_reported",
  "cost_cents": 1234,
  "timestamp": "<rfc3339>",
  "signing_agent": "<agent identity>"
}

The status field MUST be one of: "completed", "failed", or "partial".¶

The verification_status field MUST be one of: "self_reported", "tool_verified", "peer_verified", or "human_verified".¶

The completion block is signed by the executing agent's private key. Verifiers check the signature against agent_pub of the referenced SIT.¶

8.3. Chain Binding

A downstream agent receiving a result from an upstream agent SHOULD require the completion block alongside the result. The receiving agent MAY refuse to consume un-bound results.¶

9.1. Cascade

Revoking a consent or a parent SIT invalidates every descendant in the chain. Implementations MUST walk the consent chain when evaluating revocation.¶

9.2. Shared Signals Framework

Implementations SHOULD emit OpenID SSF events (credential-change, session-revoked) on revocation to propagate to connected IdPs. See draft-rampalli-suradar-bindings for CAEP event schema.¶

11.1. JWT "typ" Header Value

Registration of the "pedigree+jwt" value in the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)" registry:¶

Type Header Parameter Value

pedigree+jwt¶

Specification Document

This document, Section 4.1¶

11.2. URI Scheme

Provisional registration of the "pedigree" URI scheme with two defined forms:¶

• pedigree:name:<deployment>/<agent-id>¶
• pedigree:key:ed25519:<multibase-public-key>¶

11.3. Well-Known URI

Registration of the well-known URI /.well-known/pedigree-agent.json per RFC 8615.¶