Network Working Group K. Hartman Internet-Draft SANS Institute Intended status: Informational 29 March 2026 Expires: 30 September 2026 Credential Broker for Agents (CB4A) draft-hartman-credential-broker-4-agents-00 Abstract This document specifies a Credential Broker for Agents (CB4A). a credential vaulting and brokering architecture that mediates AI agent access to API credentials. Agents never hold real long-lived credentials. Instead, they receive short-lived, narrowly scoped, auditable proxy credentials issued by a broker that separates policy decisions from credential delivery. The architecture addresses the "credential sprawl" risk inherent in agentic AI, where agents aggregating access across many services become high-value compromise targets. CB4A builds on SPIFFE/SPIRE for workload identity, uses a Policy Decision Point / Credential Delivery Point separation inspired by NIST SP 800-207, and employs DPoP (RFC 9449) for sender-constrained token binding. The specification defines three credential proxy models, a tiered approval framework, and a comprehensive threat model with ten identified threats and their mitigations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 September 2026. Hartman Expires 30 September 2026 [Page 1] Internet-Draft CB4A March 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Real-World Motivation . . . . . . . . . . . . . . . . . . 4 1.4. Why a Credential Broker for Agents . . . . . . . . . . . 4 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 2.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 5 2.2. System Architecture . . . . . . . . . . . . . . . . . . . 5 2.3. Scalability Philosophy . . . . . . . . . . . . . . . . . 6 2.4. Trust Boundaries . . . . . . . . . . . . . . . . . . . . 7 2.5. Credential Flow . . . . . . . . . . . . . . . . . . . . . 7 3. Credential Proxy Models . . . . . . . . . . . . . . . . . . . 8 3.1. Model A: Proxy Gateway . . . . . . . . . . . . . . . . . 8 3.2. Model B: Short-Lived Token Minting . . . . . . . . . . . 9 3.3. Model C: Credential Wrapping with Scheduled Revocation . 10 3.4. Model Comparison . . . . . . . . . . . . . . . . . . . . 10 3.5. CB4A Model Strategy . . . . . . . . . . . . . . . . . . . 11 4. Technical Design . . . . . . . . . . . . . . . . . . . . . . 11 4.1. SPIRE-Based Identity Layer . . . . . . . . . . . . . . . 11 4.2. Task Request Envelope . . . . . . . . . . . . . . . . . . 12 4.3. Policy Decision Point (PDP) . . . . . . . . . . . . . . . 12 4.4. Credential Delivery Point (CDP) . . . . . . . . . . . . . 13 4.5. Sender-Constrained Tokens . . . . . . . . . . . . . . . . 14 4.6. Tiered Approval Service . . . . . . . . . . . . . . . . . 15 4.6.1. Approval Routing (Enterprise) . . . . . . . . . . . . 15 4.6.2. Approval Fatigue Countermeasures . . . . . . . . . . 16 4.7. Immutable Audit Trail . . . . . . . . . . . . . . . . . . 16 4.8. Compromise Detection . . . . . . . . . . . . . . . . . . 17 4.9. Secure Degradation . . . . . . . . . . . . . . . . . . . 17 4.10. Broker Bypass Prevention . . . . . . . . . . . . . . . . 18 4.10.1. Lesson 1: Agents Must Not Have Direct Credential Access . . . . . . . . . . . . . . . . . . . . . . . 18 4.10.2. Lesson 2: Network-Level Enforcement Over Agent Cooperation . . . . . . . . . . . . . . . . . . . . . 19 4.10.3. Lesson 3: Multimode Detection . . . . . . . . . . . 19 Hartman Expires 30 September 2026 [Page 2] Internet-Draft CB4A March 2026 4.11. Native Integration Specification (Future) . . . . . . . . 19 5. Scalability Model . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Home / Single-Machine Deployment . . . . . . . . . . . . 20 5.2. Small Team / Startup Deployment . . . . . . . . . . . . . 20 5.3. Enterprise Deployment . . . . . . . . . . . . . . . . . . 20 5.4. CB4A-as-a-Service . . . . . . . . . . . . . . . . . . . . 21 6. Capability Tiers . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Tier 1: Core (Minimum Viable CB4A) . . . . . . . . . . . 22 6.2. Tier 2: Human Oversight . . . . . . . . . . . . . . . . . 22 6.3. Tier 3: Advanced Threat Defense . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Threat Model . . . . . . . . . . . . . . . . . . . . 25 A.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. TM-1: Broker Compromise . . . . . . . . . . . . . . . . . 25 A.3. TM-2: Revocation Propagation Failure . . . . . . . . . . 25 A.4. TM-3: Token Theft and Replay . . . . . . . . . . . . . . 26 A.5. TM-4: Approval Bypass and Fatigue . . . . . . . . . . . . 26 A.6. TM-5: Justification Field Gaming . . . . . . . . . . . . 26 A.7. TM-6: Multi-Agent Scope Composition . . . . . . . . . . . 27 A.8. TM-7: Audit Log Compromise . . . . . . . . . . . . . . . 27 A.9. TM-8: Policy Engine Injection . . . . . . . . . . . . . . 27 A.10. TM-9: Fail-Open Under Pressure . . . . . . . . . . . . . 27 A.11. TM-10: Approver Spoofing . . . . . . . . . . . . . . . . 28 A.12. TM-11: Broker Bypass . . . . . . . . . . . . . . . . . . 28 A.13. Threat Summary . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Hartman Expires 30 September 2026 [Page 3] Internet-Draft CB4A March 2026 1.2. Overview AI agents increasingly need to call APIs on behalf of users. Current approaches give agents long-lived API keys or OAuth tokens, creating standing privileges that survive beyond the task, aggregate access across services, and make agents high-value compromise targets. A compromised agent (via prompt injection, context exfiltration, or tool-calling manipulation) inherits all of those credentials. The Credential Broker for Agents (CB4A) addresses this by introducing a credential vaulting and brokering layer that sits between agents and the services they need to reach. The agent never holds real credentials. Instead, it receives short-lived, narrowly scoped, auditable proxy credentials. 1.3. Real-World Motivation The credential sprawl risk for AI agents is not theoretical. In March 2026, the TeamPCP supply chain campaign compromised LiteLLM [TEAMPCP-LITELLM], an AI gateway proxy used by thousands of enterprises to route requests to LLM providers (OpenAI, Anthropic, Google Vertex AI, and others). LiteLLM's entire purpose is to hold API keys for dozens of AI providers, making it one of the highest- density credential targets in any infrastructure. The attackers injected a credential stealer into PyPI packages that harvested SSH keys, cloud credentials, LLM API keys, .env files, and database passwords from any machine running the compromised versions [LITELLM-SECURITY]. The campaign exfiltrated an estimated 300+ GB of compressed credentials affecting approximately 500,000 corporate identities. This incident illustrates precisely the problem CB4A addresses: when AI infrastructure concentrates long-lived credentials in a single process or configuration, compromise of that process yields catastrophic access. 1.4. Why a Credential Broker for Agents The credential sprawl problem for agentic AI is distinct from traditional service-to-service authentication because: * Agents are semi-autonomous: they make decisions about which APIs to call, unlike microservices with fixed call patterns. * Agent compromise vectors are novel: prompt injection, context window exfiltration, and tool-calling manipulation do not exist in traditional service architectures. Hartman Expires 30 September 2026 [Page 4] Internet-Draft CB4A March 2026 * Scope is unpredictable: an agent might need Slack write access for one task and GitHub admin for the next, making static scoping insufficient. * User delegation is implicit: agents act on behalf of users without the user being present for each action. 2. Architecture Overview 2.1. Design Philosophy CB4A follows three architectural principles: 1. Build on SPIFFE/SPIRE, don't build bespoke: The identity, attestation, and certificate management problems are already solved. CB4A adds an agent-specific policy and credential mediation layer on top. 2. Separate policy from credentials: The component that decides "yes" (PDP) MUST never touch credential material. The component that dispenses credentials (CDP) MUST never make policy decisions. Compromise of one does not yield the other. 3. Envelope as evidence, not authorization: The Task Request Envelope is an auditable artifact that the agent produces. It is evaluated by the PDP, but the PDP's decision is based on independent policy evaluation and behavioral baselines (inspired by BeyondCorp [BEYONDCORP]), not on trusting the agent's self- reported justification. 2.2. System Architecture The following diagram illustrates the CB4A system architecture with its trust boundaries: +-----------------------------------------------------+ | AGENT RUNTIME | | | | +----------+ +-------------------+ | | | Agent |--->| Task Request | | | | (SVID) | | Envelope | | | +----------+ | who/what/why/TTL | | | ^ +--------+----------+ | | | | | | | +--------v----------+ | | | | SPIRE Agent | | | | | (workload | | | | | attestation) | | Hartman Expires 30 September 2026 [Page 5] Internet-Draft CB4A March 2026 | | +--------+----------+ | +-------|-------------------|--------------------------| | | mTLS | | +-------|-------------------|--------------------------| | | BROKER INFRASTRUCTURE | | | | | | | +--------v----------+ | | | | Policy Decision | | | | | Point (PDP) | | | | | | +----------+ | | | | - Envelope eval | | Approval | | | | | - Risk scoring |->| Service | | | | | - Tier routing | | (HITL/ | | | | | - NO credential | | MFA) | | | | | access | +----------+ | | | +--------+----------+ | | | | approved | | | | decision | | | +--------v----------+ | | | | Credential | +----------+ | | | | Delivery Point | | Vault | | | | | (CDP) |->| (HSM- | | | | | | | backed) | | | | | - Token minting | +----------+ | | | | - Lease mgmt | | | <----------| - Non-renewable | +----------+ | | short-lived | leases | | Audit | | | scoped token +-------------------+ | Trail | | | | (immutbl)| | | +----------+ | | +------------------------------+ | | | Compromise Detection | | | | - Canary credentials | | | | - Confused deputy detection | | | | - Cross-agent correlation | | | +------------------------------+ | +------------------------------------------------------+ 2.3. Scalability Philosophy CB4A is designed to scale from a single-machine home deployment to a distributed enterprise environment. The same conceptual architecture applies at every scale; what changes is how components are deployed, not what they do. A home user running one agent on a laptop and an enterprise running thousands of agents across data centers both benefit from the same PDP/CDP split, envelope-based evidence, and short-lived tokens. These are architectural properties, not Hartman Expires 30 September 2026 [Page 6] Internet-Draft CB4A March 2026 deployment choices. 2.4. Trust Boundaries +==============+================+=============================+ | Boundary | Separates | Compromise of A yields | +==============+================+=============================+ | Agent / | Workload from | Agent identity (bounded by | | SPIRE Agent | identity | SVID TTL) | +--------------+----------------+-----------------------------+ | SPIRE Agent | Identity from | Ability to submit envelopes | | / PDP | policy | (not approve them) | +--------------+----------------+-----------------------------+ | PDP / CDP | Policy from | Approval decisions (not | | | credentials | credential material) | +--------------+----------------+-----------------------------+ | CDP / Vault | Delivery from | Active credentials (bounded | | | storage | by HSM access policies) | +--------------+----------------+-----------------------------+ | PDP / | Auto from | Auto-approval only (HITL/ | | Approval Svc | human approval | MFA still requires human) | +--------------+----------------+-----------------------------+ Table 1 2.5. Credential Flow 1. Agent constructs Task Request Envelope with SVID identity. 2. Envelope submitted to PDP via mTLS (SPIRE-attested). 3. PDP evaluates envelope against policy, routes to appropriate approval tier. 4. If approved, PDP sends signed approval decision to CDP. 5. CDP mints short-lived, scoped token with non-renewable lease. 6. Token returned to agent, bound to request context. 7. Agent uses token directly against target service. 8. Token expires; re-attestation required for new token. 9. Full chain logged to immutable audit trail. Hartman Expires 30 September 2026 [Page 7] Internet-Draft CB4A March 2026 3. Credential Proxy Models CB4A defines three models for how the broker mediates credential access between an agent and a target service. These models represent different points on a tradeoff between security isolation, operational complexity, and compatibility with existing APIs. 3.1. Model A: Proxy Gateway The agent never receives any real credential. Instead, the broker operates a proxy endpoint that the agent calls. The broker receives the agent's request, validates the agent's session token, injects the real API credential, forwards the request to the target service, and returns the response. The agent never receives, sees, or holds the real credential. The credential travels from the broker to the target service, but never to the agent. Agent --request--> CB4A Proxy --request + real cred--> Target API Agent <-response-- CB4A Proxy <-response------------- Target API Strengths: * Strongest isolation: the agent never sees, holds, or transmits a real credential. * The broker can inspect, log, and filter every request and response in real time. * Works with any target API without requiring the target to support short-lived tokens. Weaknesses: * Every API call becomes two network hops, adding latency. * The proxy is a single point of failure. * The proxy must understand the request/response format of every target API it mediates. * At high scale, the proxy becomes a throughput bottleneck. Best for high-security environments where credential isolation is paramount, or as a fallback for target services that do not support short-lived tokens natively. Hartman Expires 30 September 2026 [Page 8] Internet-Draft CB4A March 2026 3.2. Model B: Short-Lived Token Minting The broker uses the real long-lived credential to mint a derivative short-lived token with narrow scope, then hands that short-lived token to the agent. The agent uses the short-lived token to call the target service directly. The token expires automatically after a brief TTL (seconds to minutes). The specific minting mechanism varies by platform. Agent --req token--> CB4A Broker --mint--> Token Endpoint Agent <-short-lived-- CB4A Broker Agent --req + short-lived token--> Target API (direct) Agent <-response------------------ Target API Platform-specific minting mechanisms: +==========+========================+============================+ | Platform | Mechanism | Description | +==========+========================+============================+ | AWS | Security Token Service | Mints temporary access | | | (STS) AssumeRole | keys with session policies | | | | and configurable TTL | +----------+------------------------+----------------------------+ | Google | OAuth 2.0 + Service | Uses generateAccessToken | | Cloud | Account Impersonation | API to create short-lived | | | | OAuth 2.0 access tokens | +----------+------------------------+----------------------------+ | Azure | Azure AD / Entra ID | Issues short-lived OAuth | | | token endpoint | 2.0 bearer tokens via | | | | client credentials flow | +----------+------------------------+----------------------------+ | GitHub | App Installation | Generates short-lived | | | Tokens | installation access tokens | | | | scoped to repositories | +----------+------------------------+----------------------------+ | Generic | OAuth 2.0 Token | Exchanges long-lived token | | | Exchange [RFC8693] | for short-lived, narrowly | | | | scoped derivative | +----------+------------------------+----------------------------+ Table 2 Strengths: * No proxy bottleneck: the agent calls the target API directly. * Short-lived tokens limit blast radius to the TTL window. Hartman Expires 30 September 2026 [Page 9] Internet-Draft CB4A March 2026 * Proven at massive scale across all major cloud providers. * The broker only handles token minting, not ongoing proxying. Weaknesses: * The agent holds a real (if temporary) credential in memory. * Requires the target service to support short-lived minting. * Scope granularity depends on the target service's token API. This is the RECOMMENDED primary model for CB4A. 3.3. Model C: Credential Wrapping with Scheduled Revocation For target APIs that only support long-lived credentials and have no mechanism for minting short-lived tokens, the broker hands the agent the actual long-lived credential but immediately schedules its revocation after the task completes or the TTL expires. Strengths: * Works with any API regardless of token support. * Simple to implement. Weaknesses: * The agent holds a real, long-lived credential during the window, the weakest isolation of all three models. * Revocation depends on the target service's key management. * If revocation fails, the credential remains live indefinitely. This is the WEAKEST model and is NOT RECOMMENDED for new integrations. Use only for legacy APIs with no alternative. 3.4. Model Comparison +==============+=================+================+================+ | Property | Model A (Proxy) | Model B (Mint) | Model C (Wrap) | +==============+=================+================+================+ | Agent holds | Never | Temporary | Yes (until | | real cred? | | | revoked) | +--------------+-----------------+----------------+----------------+ | Latency | High (double | Low (one-time | None | Hartman Expires 30 September 2026 [Page 10] Internet-Draft CB4A March 2026 | overhead | hop) | mint) | | +--------------+-----------------+----------------+----------------+ | Single point | Yes (proxy) | No | No | | of failure? | | | | +--------------+-----------------+----------------+----------------+ | Works with | Yes | Short-lived | Yes | | any API? | | support only | | +--------------+-----------------+----------------+----------------+ | Blast radius | Minimal | Bounded by TTL | Full until | | | | | revoked | +--------------+-----------------+----------------+----------------+ | Recommended | DPoP fallback | Primary model | Legacy only | | use | | | | +--------------+-----------------+----------------+----------------+ Table 3 3.5. CB4A Model Strategy CB4A uses Model B as the primary credential model wherever the target service supports short-lived token minting. Model A is used selectively as a DPoP enforcement layer. Model C is available as a last resort for legacy integrations but is discouraged and flagged in audit logs. 4. Technical Design 4.1. SPIRE-Based Identity Layer Agents receive identity through SPIRE [SPIRE] workload attestation. Each agent session gets a SPIFFE [SPIFFE] Verifiable Identity Document (SVID), a short-lived X.509 certificate or JWT. SVID Properties: * TTL: matches agent session lifetime (default: 1 hour, configurable). * SPIFFE ID format: spiffe://trust-domain/agent/{user-id}/{session- id} * Attestation: node attestation (platform identity) plus workload attestation (agent process identity). * Non-renewable: agent MUST re-attest to get new SVID. Hartman Expires 30 September 2026 [Page 11] Internet-Draft CB4A March 2026 Trust Domain Federation: For multi-tenant or multi-organization deployments, SPIFFE federation enables cross-domain trust without sharing root CAs. 4.2. Task Request Envelope The envelope is a structured, signed evidence artifact submitted by the agent for every credential request. { "envelope_version": "1.0", "agent_svid": "", "request_id": "", "timestamp": "", "target": { "service": "slack", "action": "chat.postMessage", "resource": "#engineering", "scope": ["channels:write"] }, "justification": { "task_id": "", "description": "Post weekly standup summary" }, "ttl_seconds": 60, "signature": "" } The justification.description field is auditable evidence, NOT an authorization input. The PDP MUST NOT evaluate justification text for approval decisions. Approval is based on: (1) agent identity (SVID), (2) target service/action/scope matching against policy, (3) behavioral baseline comparison, and (4) approval tier routing. The justification exists solely for post-incident forensic reconstruction. 4.3. Policy Decision Point (PDP) The PDP is a stateless service that evaluates envelopes against policy, following the PDP/PEP separation defined in [NIST-ZTA]. It has zero access to credential material. Inputs: * Task Request Envelope * Agent identity (SVID validation via SPIRE) Hartman Expires 30 September 2026 [Page 12] Internet-Draft CB4A March 2026 * Policy rules (loaded from versioned policy store) * Behavioral baseline (historical access patterns) Outputs: * Signed approval decision (approved/denied/escalated) * Approval tier (auto/HITL/MFA) * Scope constraints (may narrow requested scope) * Decision rationale (logged) Scope Granularity: The PDP's scope enforcement is configurable by the administrator. Implementations may range from coarse service-level scoping (e.g., "Slack: read/write") to fine-grained resource-level scoping (e.g., "Slack: write to #engineering only"). The appropriate granularity depends on the deployment's threat model and operational maturity. Policy evaluation MUST use a typed, compiled policy language (not string interpolation). Envelope fields MUST be deserialized into typed structures before evaluation. No string concatenation or template rendering in policy evaluation paths. +===============+===========================+======================+ | Tier | Criteria | Approval Flow | +===============+===========================+======================+ | Tier 1 (Auto) | Low-risk, pre-authorized, | Immediate approval | | | within baseline | | +---------------+---------------------------+----------------------+ | Tier 2 (HITL) | Moderate risk, outside | Async human approval | | | baseline | via notification | +---------------+---------------------------+----------------------+ | Tier 3 (MFA) | High risk, destructive, | Synchronous approval | | | admin-level | with MFA challenge | +---------------+---------------------------+----------------------+ Table 4 4.4. Credential Delivery Point (CDP) The CDP brokers vault [VAULT] interactions and mints short-lived tokens. It accepts only signed PDP approval decisions. Token Minting (Model B): Hartman Expires 30 September 2026 [Page 13] Internet-Draft CB4A March 2026 * CDP receives signed approval decision specifying exact scope and TTL. * CDP retrieves base credential from HSM-backed vault (or encrypted local store for single-machine deployments). * CDP mints a derivative short-lived token using the target service's native mechanism (AWS STS AssumeRole, GCP generateAccessToken, GitHub App installation tokens, OAuth 2.0 Token Exchange [RFC8693], etc.). * For services without native short-lived token support: CDP issues a CB4A proxy token and operates a thin proxy endpoint (Model A fallback). * Token is non-renewable; expiry is absolute, no refresh. Lease Management: * Every issued token has a lease tracked by the CDP. * Leases are non-renewable by default. * On lease expiry: token is invalidated, agent MUST re-attest. * On anomaly detection signal: CDP can revoke active leases immediately. The CDP MUST NOT cache decrypted credentials in memory beyond the minting operation. Credentials are fetched from vault, used to mint derivative token, and immediately zeroed. The CDP process SHOULD run in a hardened runtime with no shell access, restricted outbound network, and memory encryption where platform supports it. 4.5. Sender-Constrained Tokens Ephemeral tokens in agent memory are extractable and replayable. CB4A addresses this with sender-constrained tokens using DPoP [RFC9449]: * At token minting, agent generates an ephemeral key pair. * Agent provides public key to CDP. * CDP binds the minted token to the agent's public key. * On each API call, agent signs the request with its private key (DPoP proof). Hartman Expires 30 September 2026 [Page 14] Internet-Draft CB4A March 2026 * Target service (or CB4A proxy for Model A fallback services) validates both the token and the DPoP proof. * Stolen tokens are useless without the corresponding private key. For services that do not support DPoP natively, the CB4A proxy endpoint validates DPoP proof before injecting real credential. This is the only scenario where Model A (proxy) is used, as a DPoP enforcement layer for services lacking native support. 4.6. Tiered Approval Service Tier 1: Auto-Approval: * PDP evaluates against static policy plus behavioral baseline. * Approval latency: less than 10ms. Tier 2: Human-in-the-Loop: * Push notification to approver's device. * Approver sees: agent identity, requested action, scope, justification. * Timeout: configurable (default 5 minutes), denied on timeout. Tier 3: MFA-Required: * Synchronous approval with multi-factor authentication. * Approver MUST complete MFA challenge (FIDO2/WebAuthn, not SMS/ TOTP). 4.6.1. Approval Routing (Enterprise) In enterprise deployments, approval requests MUST be routed to the appropriate human reviewer, not a generic approval queue. The agent's owner or responsible team is the correct approver because they understand the agent's purpose, expected behavior, and legitimate access patterns. Hartman Expires 30 September 2026 [Page 15] Internet-Draft CB4A March 2026 +===================+===============================+ | Routing Criterion | Example | +===================+===============================+ | Agent owner | Agent sales-report-bot routes | | | to Sales Eng team lead | +-------------------+-------------------------------+ | Service owner | Billing API requests route to | | | Finance team | +-------------------+-------------------------------+ | Escalation chain | Timeout escalates to manager | | | or backup | +-------------------+-------------------------------+ | On-call rotation | After-hours routes to current | | | on-call | +-------------------+-------------------------------+ Table 5 For home/individual deployments, approval routing is trivial. all requests route to the single user. 4.6.2. Approval Fatigue Countermeasures * Rate limiting on approval requests per agent per time window. * Anomaly flagging when approval request patterns change. * Mandatory cool-down periods after N consecutive approvals. * Periodic "challenge approvals" (known-benign requests presented as suspicious) to verify approver attention. 4.7. Immutable Audit Trail Every interaction produces a structured, append-only log entry: Hartman Expires 30 September 2026 [Page 16] Internet-Draft CB4A March 2026 { "event_type": "credential_request|approval|issuance| usage|expiry|revocation", "timestamp": "", "agent_spiffe_id": "spiffe://trust-domain/agent/user/session", "envelope_hash": "", "decision": "approved|denied|escalated|timed_out", "decision_tier": "auto|hitl|mfa", "credential_scope": ["channels:write"], "credential_ttl_seconds": 60, "target_service": "slack", "target_action": "chat.postMessage", "approver_identity": "", "correlation_id": "" } Storage: Write-once storage (append-only log, S3 with object lock, or dedicated SIEM). Log pipeline failures MUST trigger fail-closed behavior; no credentials issued if audit trail is unavailable. Audit trail MUST be written to a separate trust boundary from both PDP and CDP. Neither PDP nor CDP has write access to modify or delete existing log entries. Log integrity is verified via hash chaining. 4.8. Compromise Detection Canary Credentials: Seed the credential store with tokens that should never be used. Any access to a canary triggers immediate alert and session termination. Confused Deputy Detection: Monitor for credential requests where the agent identity and the task context do not match. Cross-Agent Correlation: Monitor for coordinated multi-agent access patterns that individually appear benign but collectively constitute data exfiltration or privilege escalation. Runtime Behavior Monitoring (Recommended): Runtime monitoring of post-issuance credential usage is highly valuable. Even a short- lived token can cause significant damage if misused. Implementations SHOULD include anomaly detection on API call patterns, mid-flight kill switches, and behavioral baselines. 4.9. Secure Degradation CB4A specifies secure degradation behavior for every failure mode: Hartman Expires 30 September 2026 [Page 17] Internet-Draft CB4A March 2026 +=================+======================+==================+ | Failure | Behavior | Rationale | +=================+======================+==================+ | PDP unavailable | Fail-closed | Policy cannot be | | | | evaluated | +-----------------+----------------------+------------------+ | CDP unavailable | Fail-closed | Credentials | | | | cannot be minted | +-----------------+----------------------+------------------+ | Vault | Fail-closed | Base credentials | | unavailable | | inaccessible | +-----------------+----------------------+------------------+ | Audit trail | Fail-closed | Cannot maintain | | unavailable | | chain of custody | +-----------------+----------------------+------------------+ | Approval svc | Tier 1 continues; | Preserve low- | | unavailable | Tier 2/3 denied | risk operations | +-----------------+----------------------+------------------+ | SPIRE | No new sessions; | Identity cannot | | unavailable | existing SVIDs valid | be attested | +-----------------+----------------------+------------------+ Table 6 Emergency Break-Glass: Requires two-person authorization (dual key). Bypasses PDP but still logs through audit trail. Automatically expires after configurable window (default: 30 minutes). Triggers mandatory post-incident review. 4.10. Broker Bypass Prevention A credential broker is only effective if agents cannot circumvent it to access credentials directly. This is analogous to the bypass problem faced by Cloud Access Security Brokers (CASBs), which must prevent users and applications from reaching cloud services outside the broker's mediation. CB4A draws three architectural lessons from CASB deployments: 4.10.1. Lesson 1: Agents Must Not Have Direct Credential Access The most fundamental control: real credentials MUST be stored in a vault that agents cannot access directly. The agent runtime MUST NOT have network connectivity to the vault, IAM permissions to read secrets, or file system access to credential stores. Only the CDP has vault access. This is the CB4A equivalent of a CASB's network- level enforcement: if the agent cannot reach the credentials, it cannot bypass the broker. Hartman Expires 30 September 2026 [Page 18] Internet-Draft CB4A March 2026 4.10.2. Lesson 2: Network-Level Enforcement Over Agent Cooperation CASB experience shows that agent-based enforcement (where the agent voluntarily routes traffic through the broker) is weaker than network-level enforcement (where the network prevents direct access). CB4A implementations SHOULD enforce broker mediation at the infrastructure level: * Network policies (firewall rules, security groups, or Kubernetes NetworkPolicy) that block agent-to-service direct communication for brokered services. * Service mesh sidecars that intercept outbound traffic and validate CB4A tokens before forwarding. * DNS-level controls that resolve brokered service endpoints to the CB4A proxy rather than the real service. Relying solely on the agent's cooperation to use the broker is insufficient; a compromised agent will attempt to call services directly if network-level controls do not prevent it. 4.10.3. Lesson 3: Multimode Detection Even with network-level enforcement, sophisticated bypass attempts may succeed (e.g., tunneling through allowed endpoints). CASB architectures address this with API-based monitoring alongside inline enforcement. CB4A implementations SHOULD: * Monitor target service audit logs for API calls that did not originate from the CB4A proxy or use CB4A-issued tokens. * Alert on credential usage patterns that do not match CB4A audit trail records (indicating credentials were used outside the broker). * Implement canary detection at the service level, not just at the vault level. 4.11. Native Integration Specification (Future) If CB4A achieves sufficient adoption, target services could natively validate CB4A-issued credentials. CB4A-native tokens would be JWTs containing: * iss: CB4A broker SPIFFE ID * sub: Agent SPIFFE ID Hartman Expires 30 September 2026 [Page 19] Internet-Draft CB4A March 2026 * aud: Target service identifier * scope: Requested permissions (service-specific format) * exp: Expiry timestamp (short TTL) * jti: Unique token ID (for replay detection) * cnf: Confirmation claim binding token to DPoP key [RFC9449] * envelope_hash: SHA-256 of the originating Task Request Envelope Discovery: Target services would discover CB4A broker endpoints via a well-known URI (.well-known/cba-configuration) publishing the JWKS URL, supported scopes, and token format version. 5. Scalability Model CB4A separates logical components from their deployment topology. The same security properties hold at every scale. 5.1. Home / Single-Machine Deployment A single user running AI agents on a personal workstation. All CB4A components run as local processes or lightweight containers on the same machine. A minimal deployment uses three components: SPIRE (identity), PDP (policy), and a credential proxy that combines CDP and vault access. The trust model is identical to enterprise, just deployed on one machine instead of across a network. 5.2. Small Team / Startup Deployment A team of 5-50 people with multiple agents across workstations and CI/CD pipelines. Deploys the same three core components as a home deployment (SPIRE, PDP, credential proxy), with the option to separate the credential proxy into distinct CDP and vault integration services as the team grows. 5.3. Enterprise Deployment Thousands of agents across multiple teams, data centers, and trust domains. Typically uses five or more components with dedicated infrastructure per component, including federated SPIRE, HSM-backed vault clusters, and full cross-agent correlation. Hardware attestation (TPM/TEE) is required at enterprise scale. Hartman Expires 30 September 2026 [Page 20] Internet-Draft CB4A March 2026 5.4. CB4A-as-a-Service CB4A's architecture lends itself naturally to a managed service model where a third-party provider operates the broker infrastructure on behalf of customers. In this deployment, the customer runs only the SPIRE agent alongside their AI agents; the PDP, CDP, vault, and audit trail are hosted and operated by the service provider. This model is particularly relevant because CB4A's functionality overlaps significantly with existing Cloud Access Security Broker (CASB) and Secure Access Service Edge (SASE) platforms. Both CASBs and SASE products already operate inline security mediation layers between users/applications and cloud services. Adding agent credential brokering to these platforms is a natural extension of their existing capability: * CASB platforms already mediate access between enterprise users and cloud services, enforce DLP policies, and provide audit trails. Adding CB4A's credential brokering extends this mediation to AI agents as a new class of "user." * SASE platforms already combine network security (firewall, SWG, ZTNA) with WAN optimization. CB4A's PDP/CDP model fits within the SASE policy enforcement architecture as an additional service function. * Zero Trust Network Access (ZTNA) solutions already enforce per- request access decisions based on identity and context. CB4A's Task Request Envelope is an agent-specific extension of the ZTNA access request model. Considerations for CB4A-as-a-Service: * The service provider becomes the trust anchor for credential storage. Customer due diligence on the provider's security posture is critical. * Latency between customer agents and the hosted broker adds round- trip time to every credential minting operation. Edge deployment of broker components mitigates this. * Multi-tenancy introduces isolation requirements: one customer's policy engine and credential vault MUST be isolated from another's. * Regulatory and compliance constraints may require that credentials never leave certain jurisdictions, requiring regional broker deployments. Hartman Expires 30 September 2026 [Page 21] Internet-Draft CB4A March 2026 6. Capability Tiers CB4A defines three capability tiers. Each builds on the previous one. A home deployment at Tier 1 is a complete system, not an incomplete enterprise deployment. 6.1. Tier 1: Core (Minimum Viable CB4A) * SPIRE-based workload identity with agent attestation * PDP with static policy evaluation * CDP with Model B (short-lived token minting) * Task Request Envelope schema, validation, and signing * Tier 1 auto-approval based on policy matching * Append-only audit trail with structured log entries * Non-renewable leases on all issued tokens * Fail-closed degradation for all critical components * Canary credential seeding in the credential store 6.2. Tier 2: Human Oversight * Tier 2 HITL approval workflow * Tier 3 MFA approval (FIDO2/WebAuthn) * DPoP sender-constrained token binding * Behavioral baseline collection and anomaly scoring * Dynamic risk scoring in PDP * Model A proxy fallback for services without native support * Approval fatigue countermeasures * Confused deputy detection * Emergency break-glass procedure Hartman Expires 30 September 2026 [Page 22] Internet-Draft CB4A March 2026 6.3. Tier 3: Advanced Threat Defense * Hardware attestation for agent identity (TPM/TEE) * Runtime behavior monitoring with mid-flight revocation * Cross-agent correlation engine * Per-service scope definition refinement * Log integrity verification via hash chaining * Adversarial testing program * Multi-tenant federation via SPIFFE trust domains 7. Security Considerations The full threat model is provided in Appendix A. Key security considerations include: * The broker (CDP) is the highest-value target in the architecture. It MUST be hardened with no shell access, restricted network, and credential zeroing after minting (TM-1). * Ephemeral tokens in agent memory are extractable. DPoP sender- constrained tokens [RFC9449] MUST be used to prevent replay (TM- 3). * Approval fatigue is a human factors risk that cannot be fully solved with technical controls. Challenge approvals and rate limiting reduce but do not eliminate the risk (TM-4). * Multi-agent scope composition allows individually-scoped credentials to be combined for unauthorized access. Cross- agent correlation is RECOMMENDED (TM-6). * Fail-closed degradation is critical. CB4A MUST NOT default to fail-open under any failure condition (TM-9). * Approval channel spoofing is a threat. High-risk approvals MUST use FIDO2/WebAuthn and signed approval responses (TM-10). * Broker bypass, where agents access services directly without CB4A mediation, MUST be prevented through network-level enforcement, not agent cooperation (TM-11). Hartman Expires 30 September 2026 [Page 23] Internet-Draft CB4A March 2026 8. IANA Considerations This document makes no requests of IANA. 9. References 9.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . 9.2. Informative References [BEYONDCORP] Ward, R. and B. Beyer, "BeyondCorp: A New Approach to Enterprise Security", ;login: vol. 39, no. 6, December 2014. [LITELLM-SECURITY] "Security Update: Suspected Supply Chain Incident", March 2026, . [NIST-ZTA] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST Special Publication 800-207, August 2020, . [SPIFFE] "SPIFFE: Secure Production Identity Framework For Everyone", . Hartman Expires 30 September 2026 [Page 24] Internet-Draft CB4A March 2026 [SPIRE] "SPIRE: SPIFFE Runtime Environment", . [TEAMPCP-LITELLM] "TeamPCP Expands Supply Chain Campaign With LiteLLM PyPI Compromise", March 2026, . [VAULT] "HashiCorp Vault", . Appendix A. Threat Model This appendix presents a systematic threat analysis of the CB4A architecture. Each threat is identified with a unique ID (TM-N), mapped to the architectural component it targets, assessed for severity, and paired with the mitigation specified elsewhere in this document. A.1. Methodology This threat model uses a component-based approach, examining each trust boundary and data flow for potential compromise scenarios. Threats are classified by target, attacker model, severity (Critical/High/Medium), and mitigation cross-reference. A.2. TM-1: Broker Compromise Target: Credential Delivery Point (CDP). Severity: CRITICAL. The CDP must access real credentials to mint derivative tokens. An attacker who compromises the CDP process (via RCE, supply chain attack, or SSRF) can intercept credentials during the minting operation. Mitigation: CDP never caches credentials beyond minting; credentials zeroed immediately. CDP runs in hardened runtime. Audit trail on separate trust boundary. PDP/CDP separation prevents approval of arbitrary requests. Residual Risk: During the brief minting window, the credential exists in CDP memory. This is irreducible for Model B. A.3. TM-2: Revocation Propagation Failure Target: Token lifecycle management. Severity: HIGH. Hartman Expires 30 September 2026 [Page 25] Internet-Draft CB4A March 2026 Immediate revocation across independent downstream services violates distributed systems fundamentals. Services cache auth decisions and experience network partitions. Mitigation: Three configurable revocation strategies. Ultra-short TTLs as primary control. CB4A proxy for unreliable services. Non- renewable leases. Residual Risk: A propagation window will always exist for Model B tokens against caching services. A.4. TM-3: Token Theft and Replay Target: Agent runtime memory. Severity: HIGH. Short-lived tokens in agent memory can be extracted and replayed from an external system within the TTL window. Mitigation: DPoP sender-constrained tokens [RFC9449] bind each token to an ephemeral key pair. Stolen tokens are cryptographically useless without the private key. Residual Risk: Simultaneous extraction of token AND DPoP private key defeats the binding. A.5. TM-4: Approval Bypass and Fatigue Target: Tiered approval service. Severity: HIGH. Bypass: Compromised agent crafts requests to route through auto- approval. Fatigue: High-volume legitimate requests condition approvers to rubber-stamp. Mitigation: Rate limiting, challenge approvals, cool-downs. Cross- agent correlation detects chaining. FIDO2 at Tier 3. Residual Risk: Human factors cannot be fully solved with technical controls. A.6. TM-5: Justification Field Gaming Target: Task Request Envelope. Severity: MEDIUM. Compromised agent crafts adversarially-optimized justification text. Mitigation: Justification is NOT an authorization input. Attack surface removed by design. Hartman Expires 30 September 2026 [Page 26] Internet-Draft CB4A March 2026 Residual Risk: None if implementations adhere to specification. A.7. TM-6: Multi-Agent Scope Composition Target: Blast radius containment. Severity: HIGH. An attacker compromising multiple agents can compose individually- scoped credentials for unauthorized access. Mitigation: Cross-agent correlation engine. Behavioral baselines. Canary credentials. Short TTLs. Residual Risk: Learning period for new deployments. A.8. TM-7: Audit Log Compromise Target: Immutable audit trail. Severity: HIGH. Attacker tampers with or suppresses audit log entries. Mitigation: Separate trust boundary. Hash chaining. Fail-closed on log pipeline failure. Residual Risk: Dual compromise of broker AND audit trail. A.9. TM-8: Policy Engine Injection Target: Policy Decision Point. Severity: MEDIUM-HIGH. Crafted envelope values exploit policy evaluation via injection. Mitigation: Typed, compiled policy language. Input validation. No string interpolation. Residual Risk: Low with correct implementation. A.10. TM-9: Fail-Open Under Pressure Target: Secure degradation model. Severity: HIGH. Organizational pressure creates undocumented bypass mechanisms. Mitigation: Explicit fail-closed for every failure mode. Dual-key break-glass with mandatory post-review. Residual Risk: Governance and compliance issue. Hartman Expires 30 September 2026 [Page 27] Internet-Draft CB4A March 2026 A.11. TM-10: Approver Spoofing Target: Tiered approval service, approval routing. Severity: HIGH. Attacker impersonates an authorized approver via compromised communication channel or intercepted approval webhook. Mitigation: FIDO2/WebAuthn for Tier 3. Cryptographically signed approval responses. Out-of-band verification on authenticated dashboard. Approval routing to agent owners. Residual Risk: Physical theft of approver's security key. A.12. TM-11: Broker Bypass Target: CB4A mediation layer. Severity: HIGH. A compromised agent attempts to access target services directly, bypassing CB4A entirely. If the agent can reach the target API without going through the broker, all CB4A controls (approval, scoping, audit, TTL) are circumvented. This is the credential broker equivalent of the bypass problem that Cloud Access Security Brokers (CASBs) have addressed for over a decade. Attack Scenario: 1. Compromised agent discovers that network-level controls do not block direct access to a target API endpoint. 2. Agent uses credentials obtained through a prior legitimate CB4A interaction (within TTL) to call the service directly, outside the audit trail. 3. Alternatively: agent accesses credentials from an environment variable, configuration file, or process memory of another application on the same host. Mitigation: Network-level enforcement blocking agent direct access to brokered services (Section 4.10). Vault access restricted to CDP only. Service-level audit log monitoring for calls not originating from CB4A. DNS-level controls resolving brokered endpoints to CB4A proxy. Residual Risk: Agents running on hosts with broad network access and weak segmentation. Environments where network policy enforcement is not feasible (e.g., shared development machines without container isolation). Hartman Expires 30 September 2026 [Page 28] Internet-Draft CB4A March 2026 A.13. Threat Summary +=======+===================+==========+=========================+ | ID | Threat | Severity | Primary Mitigation | +=======+===================+==========+=========================+ | TM-1 | Broker compromise | CRITICAL | Hardened runtime, | | | | | credential zeroing | +-------+-------------------+----------+-------------------------+ | TM-2 | Revocation | HIGH | Ultra-short TTLs, | | | failure | | configurable strategies | +-------+-------------------+----------+-------------------------+ | TM-3 | Token theft/ | HIGH | DPoP sender-constrained | | | replay | | tokens | +-------+-------------------+----------+-------------------------+ | TM-4 | Approval bypass/ | HIGH | Rate limiting, | | | fatigue | | challenge approvals | +-------+-------------------+----------+-------------------------+ | TM-5 | Justification | MEDIUM | Field excluded from | | | gaming | | authorization | +-------+-------------------+----------+-------------------------+ | TM-6 | Multi-agent | HIGH | Cross-agent correlation | | | composition | | engine | +-------+-------------------+----------+-------------------------+ | TM-7 | Audit log | HIGH | Separate trust | | | compromise | | boundary, hash chaining | +-------+-------------------+----------+-------------------------+ | TM-8 | Policy engine | MED-HIGH | Typed policy language | | | injection | | | +-------+-------------------+----------+-------------------------+ | TM-9 | Fail-open | HIGH | Explicit fail-closed, | | | pressure | | break-glass | +-------+-------------------+----------+-------------------------+ | TM-10 | Approver spoofing | HIGH | FIDO2/WebAuthn, signed | | | | | approvals | +-------+-------------------+----------+-------------------------+ | TM-11 | Broker bypass | HIGH | Network enforcement, | | | | | vault isolation | +-------+-------------------+----------+-------------------------+ Table 7 Acknowledgments This specification was developed with input from multi-agent architectural review and adversarial analysis. Author's Address Hartman Expires 30 September 2026 [Page 29] Internet-Draft CB4A March 2026 Kenneth G. Hartman SANS Institute Email: khartman@sans.org Hartman Expires 30 September 2026 [Page 30]