Agent Credential Attestation Protocol (ACAP)

1.1. Problem Statement

Contemporary authorization frameworks such as OAuth 2.0 [RFC6749] and OpenID Connect [OIDC] were designed for human-initiated, single-hop delegations: a resource owner grants a client access on behalf of themselves. AI agent pipelines violate this assumption in several important ways.¶

First, an agent pipeline may involve an arbitrary number of hops. A root agent receives a task from a human, decomposes it, and delegates sub-tasks to child agents, which may themselves delegate further. OAuth's two-party model has no native representation for this; each hop requires a fresh grant cycle or an out-of-band trust agreement.¶

Second, the originating human instruction -- the intent -- is not cryptographically bound to any OAuth token. An agent can receive a token whose original purpose has been transformed or corrupted by prompt injection at an intermediate step, and the verifying party has no way to detect this.¶

Third, scope in OAuth is flat and is not guaranteed to narrow monotonically through a delegation chain. A child agent can, in principle, present its parent token to a different authorization server and request broader access. Nothing in the wire format prevents scope creep.¶

Fourth, the delegation graph is not natively recorded. OAuth introspection surfaces information about a single token; it provides no view of the full task ancestry.¶

Recent IETF work -- notably the WIMSE working group [WIMSE] and the draft on AI agents acting on behalf of users [OBO01] -- acknowledges these gaps but stops short of specifying a compact, self-contained credential format with cryptographically enforced monotone scope reduction and intent binding.¶

1.2. What ACAP Adds

ACAP addresses the gaps above as follows.¶

Intent binding:

Every ACAP credential carries att_intent, a hex-encoded SHA-256 hash of the original UTF-8 instruction text. This value is set at issuance and propagated unchanged through every delegation. A verifier can confirm that a presented credential descends from a specific human instruction by independently computing the hash.¶

Monotone scope reduction:

At delegation time the issuer MUST verify that the child's requested scope is a subset of the parent's scope using the IsSubset algorithm defined in Section 5. Any request that fails this check MUST be rejected. Scope therefore only ever narrows; it can never widen through delegation.¶

Depth-limited delegation:

Each credential carries att_depth, an integer that starts at 0 for a root credential and increments by 1 at each delegation. Depth is bounded above by MaxDelegationDepth (10). A credential whose depth equals this limit MUST NOT be used as a parent for further delegation.¶

Tamper-evident chain:

Each credential carries att_chain, an ordered list of JWT IDs from the root of the delegation tree to the current token. The verifier checks that the chain length equals att_depth + 1 and that the final element equals the token's own jti. Together these checks detect any tampering with the ancestry record.¶

Lifetime containment:

A child credential's expiry is capped at the parent's expiry. Concretely, exp = min(requested_exp, parent_exp). This ensures that revoking a parent token effectively expires all descendants, even without an active revocation lookup.¶

Cascade revocation:

The revocation store records revoked JTIs and cascades revocation to all descendants by inspecting the att_chain column in the credential store. Revocation is permanent and takes precedence over token expiry.¶

Append-only audit log:

Every issuance, delegation, verification, revocation, and expiry event is recorded in a hash-chained log. Each entry commits to the previous entry's hash, the event type, the JTI, and the timestamp, forming a tamper-evident record of all credential lifecycle events within a task tree.¶

1.3. Relationship to Prior Art

ACAP is informed by but is not a profile of any existing specification. The Agentic JWT (A-JWT) paper proposes delegation chains for AI agents but does not specify exact claim semantics, scope subset enforcement, or audit log structure. The IETF draft [AGENTJWT] covers similar ground in the JWT format domain. The draft [OBO01] addresses delegation in the OAuth authorization code flow context. ACAP occupies a different point in the design space: it is a self-contained signed-token format with no external authorization server required at verification time.¶

4.1. Overview

An ACAP credential is a JSON Web Token [RFC7519] with:¶

• Header: { "alg": "RS256", "typ": "JWT" }¶

• Payload: the claims defined in Section 4.2 and Section 4.3¶

• Signature: RS256 over the ASCII representation of the header and payload¶

All implementations MUST use RS256 (RSASSA-PKCS1-v1_5 using SHA-256 [RFC7518]) as the signing algorithm. No other signing algorithm is permitted.¶

4.2. Standard JWT Claims

The following standard JWT claims are used. All are REQUIRED unless noted.¶

The sub claim MUST match the pattern ^agent:[A-Za-z0-9_\-]+$. Implementations MUST reject credentials whose sub does not begin with the literal prefix agent:.¶

4.3. ACAP Extension Claims

All ACAP-specific claims are prefixed with att_. Implementations MUST ignore unknown att_* claims to allow forward compatibility.¶

att_pid MUST be present when att_depth > 0 and MUST be absent when att_depth == 0.¶

att_tid, att_intent, and att_uid MUST be propagated unchanged through all delegations.¶

4.4. Concrete Examples

{
  "iss": "https://attest.example.com",
  "sub": "agent:inbox-agent-v2",
  "iat": 1742386800,
  "exp": 1742473200,
  "jti": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "att_tid": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
  "att_depth": 0,
  "att_scope": ["email:read", "email:draft"],
  "att_intent": "3b4c2a1f8e7d6c5b4a3f2e1d0c9b8a7f...",
  "att_chain": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"],
  "att_uid": "user:alice"
}

{
  "iss": "https://attest.example.com",
  "sub": "agent:summariser-agent-v1",
  "iat": 1742387100,
  "exp": 1742473200,
  "jti": "c3d4e5f6-a7b8-9012-cdef-012345678901",
  "att_tid": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
  "att_pid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "att_depth": 1,
  "att_scope": ["email:read"],
  "att_intent": "3b4c2a1f8e7d6c5b4a3f2e1d0c9b8a7f...",
  "att_chain": [
    "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "c3d4e5f6-a7b8-9012-cdef-012345678901"
  ],
  "att_uid": "user:alice"
}

5.1. Scope Entry Format

A scope entry is a string conforming to the grammar:¶

scope-entry = resource ":" action
resource    = 1*( ALPHA / DIGIT / "_" / "-" / "*" )
action      = 1*( ALPHA / DIGIT / "_" / "-" / "*" )

Both resource and action MUST be non-empty. Implementations MUST reject invalid scope entries at all stages: issuance, delegation, and verification.¶

5.2. Wildcard Rules

The wildcard character * MAY appear as the entirety of either the resource or action component (or both). Coverage rules:¶

• P covers C if P.resource equals * OR P.resource equals C.resource¶

• AND P.action equals * OR P.action equals C.action¶

Consequently *:* covers every valid scope entry, email:* covers email:read, email:draft, etc.¶

5.3. NormaliseScope

Before storing scope in any credential or comparing scopes, implementations MUST apply the NormaliseScope procedure:¶

1. Trim leading and trailing whitespace from each entry.¶

2. Remove any empty entries that result from trimming.¶

3. Remove duplicate entries, preserving the first occurrence.¶

4. Return the resulting list in insertion order.¶

5.4. IsSubset Algorithm

function IsSubset(parentScope, childScope):
    for each entry CE in childScope:
        childEntry = ParseScope(CE)
        if childEntry is invalid:
            return false
        covered = false
        for each entry PE in parentScope:
            parentEntry = ParseScope(PE)
            if parentEntry is invalid:
                continue
            if EntryCovers(parentEntry, childEntry):
                covered = true
                break
        if not covered:
            return false
    return true

function EntryCovers(parent, child):
    resourceOK = (parent.Resource == "*") OR
                 (parent.Resource == child.Resource)
    actionOK   = (parent.Action  == "*") OR
                 (parent.Action  == child.Action)
    return resourceOK AND actionOK

6.1. Overview

Issuance creates a root credential (depth 0) that anchors a new task tree. The Issuer MUST perform all validation checks before constructing the credential. The Issuer MUST sign the credential with its RSA private key using RS256.¶

6.2. Input Validation

The Issuer MUST reject the issuance request if any of the following conditions hold:¶

1. agent_id is absent or empty.¶

2. user_id is absent or empty.¶

3. scope is absent or contains no entries.¶

4. Any entry in scope is not parseable as a valid scope entry.¶

5. instruction is absent or empty.¶

6.3. Intent Hash Computation

The intent hash is computed as:¶

att_intent = lowercase-hex( SHA-256( UTF-8-encode( instruction ) ) )

The instruction string MUST be encoded as UTF-8 before hashing. The resulting 32-byte SHA-256 digest MUST be encoded as 64 lowercase hexadecimal characters. No canonicalization is applied to the instruction before hashing; the raw UTF-8 bytes are hashed as-is.¶

6.4. Identifier Generation

The Issuer MUST generate two UUID v4 [RFC9562] values at issuance:¶

• jti: the unique identifier for this credential.¶

• att_tid: the task tree identifier.¶

Both values MUST be generated using a cryptographically secure random source.¶

6.5. TTL and Expiry

1. If ttl_seconds is zero, the TTL defaults to DefaultTTLSeconds (3600 seconds).¶

2. If ttl_seconds is negative, the issuance MUST be rejected.¶

3. If ttl_seconds exceeds MaxTTLSeconds (86400 seconds), the TTL is capped at MaxTTLSeconds.¶

4. exp = iat + ttl_seconds (after applying the rules above).¶

6.6. Root Credential Construction

7.1. Overview

Delegation creates a child credential derived from an existing parent credential. The result is a credential at att_depth + 1 with a scope that is a subset of the parent's scope and an expiry no later than the parent's expiry.¶

7.2. Input Validation

The Issuer MUST reject a delegation request if:¶

1. parent_token is absent or empty.¶

2. child_agent is absent or empty.¶

3. child_scope is absent or contains no entries.¶

7.3. Parent Token Verification

The Issuer MUST:¶

1. Verify the RS256 signature against the Issuer's public key.¶

2. Verify that the parent token has not expired (exp > now).¶

3. Verify that the signing algorithm is RS256.¶

7.4. Scope Subset Enforcement

The Issuer MUST apply NormaliseScope to the requested child_scope. The Issuer MUST then apply IsSubset(parentScope, childScope). If IsSubset returns false, the delegation MUST be rejected.¶

7.5. Depth Limit

The Issuer MUST check that parent.att_depth < MaxDelegationDepth (10). If the parent's depth equals or exceeds the limit, the delegation MUST be rejected.¶

7.6. Expiry Computation

parent_exp = parent.exp

if ttl_seconds > 0:
    requested_exp = now + ttl_seconds
    child_exp = min(requested_exp, parent_exp)
else:
    default_exp = now + DefaultTTLSeconds
    child_exp = min(default_exp, parent_exp)

The child's expiry MUST NOT exceed the parent's expiry.¶

7.7. Delegated Credential Construction

8.1. Overview

A credential is valid if and only if all of the following conditions are satisfied:¶

1. The RS256 signature verifies against the Issuer's public key.¶

2. The current time is before exp (subject to clock-skew allowance).¶

3. The length of att_chain equals att_depth + 1.¶

4. The final element of att_chain equals jti.¶

5. The jti is not present in the revocation store.¶

8.2. Verification Algorithm

function Verify(tokenString, issuerPublicKey, revocationStore):

    // Step 1: Signature and expiry
    claims, err = RS256Parse(tokenString, issuerPublicKey)
    if err is not nil:
        return invalid("signature verification failed")

    // Step 2: Chain length invariant
    expectedLen = claims.att_depth + 1
    if len(claims.att_chain) != expectedLen:
        return invalid("chain length mismatch")

    // Step 3: Chain tail invariant
    if claims.att_chain[len(claims.att_chain) - 1] != claims.jti:
        return invalid("chain tail does not match jti")

    // Step 4: Revocation check
    if revocationStore.IsRevoked(claims.jti):
        return invalid("credential has been revoked")

    return valid(claims)

8.3. Warnings vs. Hard Failures

Chain length and chain tail inconsistencies are surfaced as warnings that cause the credential to be reported as invalid. The warning mechanism exists to distinguish between cryptographic failures (which may indicate active attack) and structural inconsistencies (which may indicate implementation bugs).¶

9.1. Semantics

Revocation permanently invalidates a credential identified by its jti. Once revoked, a credential MUST be treated as invalid regardless of its exp claim. Revocation is irreversible.¶

9.2. Cascade Semantics

Revoking a credential with jti X automatically revokes every credential whose att_chain contains X:¶

Revoke(X):
    targets = { jti | jti == X OR X in credentials[jti].att_chain }
    for each T in targets:
        revocations.insert(T, now, revokedBy)

Cascade revocation SHOULD be performed atomically within a single database transaction.¶

9.3. Revocation Store

The revocation store records:¶

Duplicate revocation attempts MUST be treated as a no-op (idempotent).¶

9.4. Lifetime Interaction

A credential that has expired is invalid regardless of the revocation store. A credential that has been revoked is invalid regardless of whether it has expired. These are independent failure conditions.¶

10.1. Overview

Certain delegations require explicit human approval before being granted. ACAP defines an approval protocol that makes the human decision a cryptographic event embedded in the resulting credential.¶

10.2. Approval Lifecycle

The HITL approval flow consists of four phases:¶

1. Request. The agent sends an approval request containing the parent_token, requested child_scope, an intent description, and the agent_id. The Issuer creates a pending approval record and returns a challenge_id.¶

2. Poll. The agent polls for approval status using the challenge_id. Status is one of: pending, approved, rejected, or expired.¶

3. Grant or Deny. A human reviews the request via a dashboard or integration. To grant, the human authenticates via an OIDC Identity Provider and the Issuer verifies the id_token. The Issuer records the human's identity and marks the approval as granted.¶

4. Credential Issuance. Upon grant, the Issuer delegates a new credential from the parent token with the approved scope. The credential carries att_hitl_req, att_hitl_uid, and att_hitl_iss.¶

10.3. Approval Expiry

Pending approvals MUST expire after a bounded time window. Implementations MUST NOT allow approvals to remain pending indefinitely. An expired approval MUST be treated identically to a rejection.¶

10.4. Parent Token Re-verification

When an approval is granted, the Issuer MUST re-verify the parent token before issuing the delegated credential. If the parent token has expired or been revoked while the approval was pending, the Issuer MUST reject the grant.¶

10.5. HITL Claims Propagation

The HITL claims (att_hitl_req, att_hitl_uid, att_hitl_iss) from the most recent human approval propagate to all subsequent delegations. If a new HITL approval occurs at a deeper delegation, the new claims replace the inherited ones.¶

10.6. Multi-Tenant Isolation

Approval requests are scoped to the authenticated organization. An approval created by org A MUST NOT be resolvable by org B.¶

11.1. Structure

The audit log is an append-only, hash-chained record of credential lifecycle events. Each entry commits to the previous entry's hash, making the log tamper-evident.¶

The audit log is partitioned by att_tid. Each task tree has its own independent hash chain. The first event uses a genesis hash of 64 ASCII zero characters as the previous hash value.¶

11.2. Entry Hash Computation

entry_hash = lowercase-hex( SHA-256(
    prev_hash
    || event_type
    || jti
    || created_at_rfc3339nano
) )

where || denotes string concatenation. The genesis hash is:¶

"00000000000000000000000000000000\
 00000000000000000000000000000000"

(64 ASCII zero characters.)¶

11.3. Event Types

11.4. Audit Entry Fields

11.5. Append-Only Enforcement

Implementations MUST enforce append-only semantics on the audit log.¶

11.6. Log Verification

To verify the integrity of the audit log for a given att_tid:¶

1. Retrieve all entries in ascending id order.¶

2. For each entry starting at the second, verify that entry.prev_hash equals the entry_hash of the preceding entry.¶

3. Recompute entry_hash from the raw fields and verify it matches.¶

Any discrepancy indicates tampering or corruption.¶

12.1. Prompt Injection

ACAP credentials bind to the intent hash of the original instruction, but they do not prevent a legitimate credential from being used by a compromised agent. The narrow, monotone-reducing scope model limits the blast radius of a compromised agent. The intent hash enables post-hoc detection of misuse. The att_ack claim carries a checksum of the agent binary for agent substitution detection.¶

12.2. Replay Attacks

Credentials carry a unique jti. Verifiers MUST check the revocation store on every verification call. The exp claim bounds the replay window for non-revoked credentials. Verifiers SHOULD maintain a short-term cache of recently seen jti values.¶

12.3. Scope Creep

Scope creep is prevented by IsSubset enforcement at delegation time. Resource servers MUST verify that the presented credential's att_scope covers the requested operation.¶

12.4. Clock Skew

Implementations SHOULD allow a clock-skew leeway of up to 60 seconds. Implementations MUST NOT allow a leeway of more than 300 seconds.¶

12.5. Key Management

The Issuer's RSA private key is the root of trust. Compromise allows forging credentials. Implementations SHOULD use hardware security modules and short key rotation periods. The public key MUST be distributed via an out-of-band mechanism (e.g., a JWKS endpoint).¶

12.6. Credential Store Integrity

The revocation store and credential store are security-critical. Implementations MUST apply access controls preventing unauthorized modification.¶

12.7. Audit Log Integrity

Hash-chaining provides tamper-evidence but not tamper-prevention. The audit log SHOULD be replicated to a write-once store or transparency log for stronger guarantees.¶

14.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

14.2. Informative References

[AGENTJWT]

Goswami, D., "Agentic JWT: Secure Delegation Protocol for AI Agent Pipelines", 2025, <https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/>.

[OBO01]

"OAuth 2.0 for AI Agents Acting on Behalf of Users", 2025, <https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/>.

[OIDC]

Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <https://openid.net/specs/openid-connect-core-1_0.html>.

[WIMSE]

"IETF Workload Identity in Multi System Environments (WIMSE) Working Group", n.d., <https://datatracker.ietf.org/wg/wimse/about/>.