Kindred Systems

LondonUnited Kingdom kindred@kindredsystems.ai

Security OAuth token exchange SPIFFE workload identity delegation The Kindred Agent Identity Framework (KAIF) is an OAuth 2.0 token exchange mechanism for delegated agent-to-service authorization, combining RFC 8693 token exchange with SPIFFE workload identity attestation and operator-assigned authorization tiers. This document specifies the protocol mechanics, deployment profiles, and interoperability requirements for systems implementing agent authorization with audit accountability. KAIF is intended for scenarios in which an operator (human principal) provisionally authorizes an agent (automated workload) to perform bounded actions on their behalf, with cryptographic proof of authorization, delegation depth tracking, and revocation in real time. This document is intentionally vendor-neutral in its normative requirements. Cloud platforms, model providers, workflow systems, and audit backends discussed by implementations are informative deployment examples, not part of the KAIF wire protocol.

Introduction

Problem Statement Contemporary system architectures increasingly rely on autonomous agents, both AI-driven and workflow-based, to execute actions on behalf of human operators in complex distributed environments. Current authorization models present several challenges:

1. Coarse-grained control: Traditional API keys or static tokens provide no granularity on what actions an agent may perform.
2. Limited auditability: It is difficult to correlate which agent executed which action, especially in delegated scenarios.
3. Revocation latency: Certificate-based models suffer from multi-minute revocation propagation delays.
4. Workload identity opacity: There is no standardized way for an authorization service to verify which workload is requesting access.

KAIF addresses these challenges by combining three existing standards and practices:

• RFC 8693: OAuth 2.0 Token Exchange for subject-actor separation
• SPIFFE/SPIRE : Cryptographic workload identity and JWT-SVID attestation
• Operator-assigned authorization tiers: A flexible authorization model that avoids hard-coded trust assumptions

Scope and Intended Deployment KAIF is intended for operator-initiated, agent-executed, boundary-crossing transactions. A "boundary-crossing transaction" is any action where:

• The agent is acting on behalf of a human principal (operator)
• The action modifies state in an external system (payment, API mutation, purchase)
• Regulatory, financial, or security audit requirements require proof of authorization

The following are out of scope for v1.0:

• Behavioral trust scoring (agent action pattern analysis)
• Peer reputation models
• Long-running streaming delegations
• Cross-operator federation (see v2.0 roadmap)

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. KAIF-specific terms:

• Operator: A human principal (person) who authorizes an agent to act on their behalf.
• Agent: An automated workload (software) with a SPIFFE identity that executes actions on behalf of an operator.
• Boundary Crossing: An action that crosses a trust boundary--e.g., calling an external API, initiating a payment, or writing to a regulated log.
• Authorization Tier: An operator-assigned permission level (PROVISIONAL, STANDARD, VERIFIED, TRUSTED) that determines token TTL and delegation depth.
• Delegation Depth: The count of intermediate agents in a delegation chain (depth 0 = direct operator->agent, depth 1 = operator->agent1->agent2).
• Revocation: Immediate invalidation of a token via JTI (JWT ID) denylist.
• Relying Party: A third-party service that validates KAIF tokens without running a KAIF server instance.

Implementation Status (Informative) KAIF has been validated in at least one concrete multi-system deployment as an implementation-backed protocol design. That deployment demonstrated, end to end:

• operator-originated delegation grant issuance
• workload identity presentation during token exchange
• audience-bound authorization for a third-party execution surface
• receipt correlation back to the originating workflow
• workflow resumption after external completion

This evidence indicates that the KAIF handshake is viable across a real external boundary. It does not make any specific cloud, AI provider, queue, workflow runtime, or datastore normative for interoperability. Independent implementations remain necessary to establish broader interoperability confidence.

Terminology Stability The protocol wire format in this document uses authorization_tier and authorization_tier_value as the canonical delegation strength fields. Implementations MAY use local internal terms such as trust_tier, trust_score, or similar, but those names are deployment-specific and are not normative protocol vocabulary unless explicitly mapped to the KAIF claims defined here.

Protocol Overview

Three-Party Flow delegation JWT) v +----------------------+ | KAIF Server | | (Authorization | | Authority) | +---------------------++ ^ | | | 2. Token Exchange (RFC 8693) | | (delegation JWT + SVID -> access token) | v | +--------------+ | | Agent | | | (SPIFFE | | | identity) | | +------+-------+ | | | | 3. Use token at relying party | | | v | +--------------+ | | Relying | | | Party | +---------| (e.g., | | Payment API)| +--------------+ ]]>

Delegation Grant (Subject Token) An operator provisions a delegation grant, a signed JWT that authorizes an agent to request access tokens. A grant issued by the KAIF server contains:

Token Exchange Request (RFC 8693) The agent exchanges the delegation grant (subject_token) and its SPIFFE identity JWT-SVID (actor_token) for an access token: &subject_token_type=urn:ietf:params:oauth:token-type:access_token &actor_token= &actor_token_type=urn:ietf:params:oauth:token-type:jwt &scope=invoke:completion &audience=urn:example:payment-api ]]>

KAIF Access Token (Response) The server returns a signed JWT that carries operator identity, agent identity, delegation depth, tier, and scope:

Validation Flow When a relying party receives the access token from an agent: Relying Party: "Use this token to execute transaction" v Relying party checks: 1. Token signature valid against KAIF issuer JWKS ok 2. Token not expired ok 3. Token not in revocation denylist (KAIF /introspect) ok 4. Scope permits requested action ok 5. Delegation depth within policy ok v Relying Party: "AUTHORIZED" -> execute transaction v Relying Party -> KAIF Server: Log receipt/audit event ]]>

Detailed Protocol Specification

Endpoint: POST /provision Purpose: Operator provisions a delegation grant for an agent. Request: Validation:

• id_token MUST be a valid OIDC token from configured IdP
• agent_id MUST be registered in operator's ACL
• scope MUST be a subset of agent's permitted scopes
• ttl_seconds MUST be between 60 and 86400

Response: Errors:

• invalid_request (400): Missing required fields
• invalid_grant (400): id_token invalid or expired
• access_denied (403): Operator not authorized for agent or scope

Endpoint: POST /oauth/token Purpose: RFC 8693 token exchange for agent-initiated access-token requests. Request: &subject_token_type=urn:ietf:params:oauth:token-type:access_token &actor_token= &actor_token_type=urn:ietf:params:oauth:token-type:jwt &scope=invoke:completion &audience=urn:example:payment-api ]]> Validation steps (in order):

1. Parse and validate subject_token (delegation grant)
   • MUST have valid signature from KAIF issuer
   • MUST NOT be expired (with 10s clock skew tolerance)
   • MUST NOT be in JTI revocation denylist
2. Parse and validate actor_token (JWT-SVID)
   • MUST have valid signature from SPIRE bundle
   • MUST NOT be expired
   • SPIFFE ID MUST be registered in ACL
3. Validate scope
   • MUST be subset of subject_token scope
   • MUST be subset of actor's permitted scopes (ACL)
   • MUST use glob matching (e.g., "vault:read:*" matches "vault:read:key")
4. Check authorization tier
   • Fetch the operator-assigned authorization tier (default 0.5 = STANDARD)
   • MUST meet agent's minimum tier requirement
   • Determine token TTL based on tier
5. Compute delegation depth
   • If subject_token is direct provision: depth = 0
   • If subject_token is access token from prior exchange: depth = subject.kaif.delegation_depth + 1
   • MUST NOT exceed: min(actor ACL depth limit, tier depth limit)
6. Mint access token with RS256 signature

Response: Errors:

• invalid_request (400): Malformed request
• invalid_grant (400): subject_token invalid/expired/revoked
• invalid_scope (400): Scope not permitted
• invalid_client (401): actor_token invalid
• insufficient_trust (403): Authorization tier below minimum
• delegation_depth_exceeded (403): Depth would exceed limit

Endpoint: POST /introspect Purpose: RFC 7662 token introspection for relying parties that verify tokens in real time. Request: Response (if active): Response (if revoked or invalid):

Endpoint: POST /revoke Purpose: Operator revokes a token. Request: Response: Mechanics:

• Extract JTI from token
• Add to Redis denylist with TTL = token.exp
• Publish to revocation channel for multi-instance sync
• Write audit entry

Endpoint: GET /.well-known/jwks.json Purpose: Public JWK Set document for external relying parties. Response: Caching: MUST set Cache-Control: max-age=3600

Endpoint: GET /.well-known/kaif-metadata.json Purpose: Issuer metadata for relying parties (KAIF v1.1+). Response:

Authorization Tier Model KAIF uses operator-assigned authorization tier values in the range 0.0-1.0 to determine access permissions:

Tier	Range	Token TTL	Max Depth	Use Case
PROVISIONAL	0.0-0.49	300s	0	New agents, limited trust
STANDARD	0.5-0.69	600s	1	Established agents
VERIFIED	0.7-0.89	900s	2	High-confidence agents
TRUSTED	0.9-1.0	900s	3	Critical operators, full delegation

Assigning tier values: Operators assign tier values to agents based on their operational context, not automated behavioral scoring in v1.0. Examples:

• New agent: 0.3 (PROVISIONAL, untested)
• Stable agent with 6 months history: 0.6 (STANDARD)
• Agent in production payment path: 0.85 (VERIFIED)
• Root operator with full authority: 1.0 (TRUSTED)

Scope Model KAIF scopes follow OAuth 2.0 conventions with glob-pattern support: Examples:

• invoke:completion -- Invoke a specific completion (exact match)
• vault:read:* -- Read any vault key (glob)
• admin:* -- All admin operations (glob)
• vault:read:anthropic_key -- Read one specific key (exact match)

Validation: Implementations MUST evaluate exact matches before glob patterns, or use an equivalent matcher. Substring matching is not sufficient.

Delegation Depth and Sub-Delegation An agent MAY create a delegation chain by using its access token as the subject_token in a second token exchange, creating a sub-delegated token. Rules:

• Depth 0: Operator -> Agent (direct)
• Depth 1: Operator -> Agent1 -> Agent2 (sub-delegation)
• Depth N: Limited by min(ACL max_depth, authorization_tier max_depth)

Restrictions:

• The parent token's may_sub_delegate flag MUST be true.
• The parent token MUST be in VERIFIED or TRUSTED tier.
• The sub-delegated token scope MUST be a subset of the parent scope.
• Depth MUST be strictly increasing, with no cycles.

Example: token T1 with delegation_depth: 0 2. Agent1 uses T1 as subject_token to request sub-delegation for Agent2 -> verify T1.may_sub_delegate = true -> verify T1.delegation_depth + 1 <= ACL max -> issue token T2 with delegation_depth: 1 principal_chain: [operator, agent1] 3. Agent2 attempts to sub-delegate to Agent3 -> check T2.delegation_depth + 1 <= ACL max -> issue token T3 with delegation_depth: 2 ]]>

Audit and Non-Repudiation Every KAIF operation appends an immutable audit entry, linked by SHA-256 hash chaining: Verification: External parties can verify audit chain integrity by replaying the hash computation:

Revocation and Propagation KAIF provides two revocation models:

Lazy Revocation (Default) Relying parties MAY cache tokens and check expiry locally. Revocation is eventual: the denylist is checked on the next refresh. Latency: Minutes (depends on token cache TTL)

Strict Revocation Relying parties call /introspect on every token use to check revocation status in real time. Latency: <100ms (Redis denylist lookup) Operators choose strict vs. lazy based on their risk tolerance and throughput requirements.

HA-Backed Revocation Stores KAIF deployments commonly back the JTI denylist and audit chain with a managed Redis service. When the backing store is a managed HA service that does not expose customer-triggerable restart or failover operations, implementations MUST validate continuity through client-observable behavior rather than cluster control-plane actions. At minimum, a conformant deployment using such a service MUST demonstrate:

• Redis client reconnect after transient disconnect
• Denylist persistence across reconnect
• Audit hash-chain continuity across reconnect
• Resumption of successful writes after reconnect

Platform-specific HA limitations and validation methods SHOULD be documented in implementation reports or deployment profiles, not embedded into interoperable wire semantics.

Security Considerations

Token Binding (RFC 8705) KAIF SHOULD support mutual TLS (mTLS) token binding . When an agent presents a client certificate, KAIF MUST include: The relying party MUST verify that the mTLS handshake certificate thumbprint matches the token's cnf value.

Clock Skew All timestamp validation MUST use 10-second clock skew tolerance (not configurable).

Key Rotation KAIF MUST support zero-downtime key rotation by maintaining both active and retained keys in the JWKS. Relying parties MUST accept tokens signed with either key for a retention period (recommended: 7 days).

SPIFFE Trust Domain Validation KAIF MUST validate that actor_token SPIFFE ID matches the configured SPIRE trust domain. Mismatched trust domains MUST be rejected with invalid_client.

Scope Validation Scope validation MUST use exact-match-first, then glob matching. Substring matching MUST NOT be used (e.g., "vault:read" does NOT match "vault:read:key").

Logging and Redaction KAIF implementations MUST:

• Log JTI (not token values)
• Redact subject_token, actor_token, authorization headers in HTTP logs
• Never log private key material
• Include request ID for tracing

Threat Model Summary

Attacker	Threat	Required Control	Residual Risk
External caller without delegation	Attempts token exchange without operator grant	subject_token signature, expiry, revocation, and ACL validation	Stolen valid grant until expiry or revocation
Compromised workload	Uses wrong or forged workload identity	actor_token JWT-SVID validation against trust bundle and ACL-bound SPIFFE ID	Abuse by a legitimately attested but compromised workload
Token thief	Replays access token at relying party	Short TTL, optional mTLS binding, strict introspection for high-risk paths	Replay window exists when relying parties use lazy revocation
Over-privileged intermediary agent	Attempts excessive sub-delegation	Scope subset checks, may_sub_delegate, depth enforcement, tier gating	Misconfigured ACL or operator approval can still over-authorize
Malicious or faulty relying party	Accepts invalid, expired, or wrong-audience token	Mandatory JWKS validation, expiry checks, audience checks, optional strict introspection	Weak local policy at relying party remains possible
Audit tampering actor	Alters forensic record after issuance	Hash-chained audit entries and externally verifiable prev_hash continuity	Record deletion or total store loss still requires external retention strategy

Privacy and Data Minimization KAIF is intended to prove delegated authority, not to maximize identity disclosure. Implementations SHOULD minimize personal and operational data as follows:

• sub SHOULD use the least identifying operator handle consistent with the deployment's audit requirements.
• principal_chain SHOULD contain only the identities required to explain delegation lineage.
• Audit detail fields SHOULD exclude prompt bodies, business payloads, secrets, and raw token material unless separately required by policy.
• Relying parties SHOULD log JTI, actor identity, action, and result before logging broader contextual data.
• Operators and deployments SHOULD define retention periods for audit entries and principal-chain material consistent with legal and regulatory requirements.

Relying Party Profile (Normative) A third-party service that accepts KAIF tokens MUST implement:

Token Validation now (with 10s clock skew) 4. If lazy revocation: done 5. If strict revocation: POST /introspect to check JTI denylist 6. Extract scope, verify requested action is permitted 7. Extract actor.sub (SPIFFE ID), log for audit trail ]]>

Error Handling HTTP status codes are used as defined in .

Condition	Action	HTTP Status
Signature invalid	Reject	401 Unauthorized
Expired	Reject	401 Unauthorized
Revoked (strict mode)	Reject	401 Unauthorized
Scope insufficient	Reject	403 Forbidden
Introspect unreachable (strict mode)	Degrade or reject (policy choice)	503 Service Unavailable

Audit Trail Relying parties SHOULD log:

• Timestamp of token use
• JTI
• Actor SPIFFE ID
• Scope used
• Action executed
• Result (success/failure)

This enables cross-party forensics if a token is misused.

Backward Compatibility This is KAIF v1.0, the initial standards-track release. Future versions:

• v1.1: Issuer metadata endpoint (.well-known/kaif-metadata.json)
• v2.0: Multi-issuer federation, cross-operator delegation
• v3.0: Behavioral trust signals (optional, opt-in per operator)

Implementations MUST gracefully ignore unrecognized claims in KAIF tokens to allow forward compatibility.

IANA Considerations This document registers the following values with IANA:

OAuth 2.0 Grant Type Type: urn:ietf:params:oauth:grant-type:token-exchange (RFC 8693) Description: Token exchange grant (already registered; KAIF profiles its use)

JWT Claims Claim name: kaif Claim description: Container for KAIF-specific claims (authorization_tier, delegation_depth, principal_chain) JWT claims registry: Requested

Conformance An implementation claims KAIF v1.0 conformance if it:

1. Implements POST /oauth/token with RFC 8693 semantics
2. Implements POST /introspect with RFC 7662 semantics
3. Validates actor_token as JWT-SVID from a configured SPIRE bundle or equivalent SPIFFE trust source
4. Enforces scope glob matching with exact-match-first behavior
5. Supports delegation depth tracking and enforcement
6. Publishes JWKS with active and retained keys
7. Maintains an audit trail with SHA-256 hash chaining
8. Supports JTI revocation with sub-second propagation
9. Validates timestamps with 10-second clock skew tolerance
10. Passes the KAIF conformance test suite

Conformance is demonstrated by passing the KAIF conformance kit included with this repository. Protocol conformance and deployment evidence are related but distinct:

• Protocol conformance establishes that an implementation speaks KAIF correctly.
• Deployment evidence establishes that a specific operating environment behaved correctly under real conditions.

An implementation MAY publish deployment evidence, interoperability notes, or platform-specific profiles in addition to protocol conformance results.

Interoperability Evidence (Informative) A report SHOULD clearly state:

1. which parts of the KAIF handshake were exercised
2. whether the relying party was independent from the authorization server
3. which delivery, receipt, or resume semantics were validated beyond token issuance
4. which deployment details are informative examples rather than normative protocol requirements
5. which claims were not tested

Revocation-Store Resilience Profile If a deployment uses a managed Redis service for denylist and audit persistence, conformance evidence SHOULD include a revocation-store resilience profile. That profile SHOULD verify:

1. Redis client reconnect recovery
2. Denylist persistence after reconnect
3. Audit chain prev_hash continuity after reconnect
4. Successful new delegation, token issuance, and revocation writes after reconnect

If the platform does not expose customer-triggerable restart or failover operations, the implementation MUST document that limitation and MAY satisfy this profile using client-side disconnect and reconnect simulation plus state verification.

Normative Informative Cloud Native Computing FoundationCloud Native Computing Foundation

Illustrative Implementation Status (Informative) One implementation-backed validation of KAIF exercised the following path:

1. an operator provisioned a delegation grant for a registered workload
2. the workload exchanged that grant together with its workload identity for an audience-bound token
3. a third-party execution surface accepted the boundary request
4. a completion receipt was written back to the originating system
5. the originating workflow resumed and completed its downstream steps

This validation supports the claim that KAIF can convey delegated authority, workload identity, audience restriction, and correlated receipt data across a real external boundary. This validation does not, by itself, prove:

• interoperability across multiple independent KAIF implementations
• standardization of any particular cloud transport, agent runtime, queue, workflow engine, or datastore
• completeness of every optional KAIF feature or future extension

Implementers SHOULD publish similarly bounded implementation reports so that protocol review can distinguish wire-level interoperability from deployment-specific success.