"What is the borrowed-credential problem, and why is it the most common enterprise agent identity failure?"	"Engineers paste their personal credentials (OAuth token, AWS keys, Slack token) into the agent's env var 'to get it working.' The agent inherits the human's FULL privilege — including everything the human can do that the task does not require. The blast radius is the credential's scope, not the task's requirement. An injected agent with borrowed admin credentials is an admin compromise — and it looks legitimate in access logs because the credential was never stolen, it was handed over."	c2b::b5::recall
"What is a non-human identity (NHI), and why is it the correct model for agents?"	"An NHI is an identity that authenticates a workload, service, or process (not a person) — service accounts, workload identities, scoped tokens. An agent is an NHI, not a human, and its identity should reflect that. NHIs have three properties borrowed human credentials lack: (1) scoped to the workload (privilege = task's requirement, not human's access), (2) independently revocable (rotate the NHI without disabling the human), (3) auditable as non-human (logs say 'agent did X' not 'engineer did X'). NHIs are the fastest-growing identity category in cloud security."	c2b::b5::recall
"Name the three properties an NHI has that a borrowed human credential lacks."	"(1) SCOPED TO THE WORKLOAD — the NHI is minted with exactly the permissions the workload requires, not the human's full access. (2) INDEPENDENTLY REVOCABLE — the NHI can be revoked/rotated without disabling the human whose credentials were borrowed. (3) AUDITABLE AS NON-HUMAN — access logs distinguish 'the agent did this' from 'the human did this,' which matters for incident response (an anomalous NHI action is an agent event, not a user event)."	c2b::b5::recall
"What is least privilege at the agent layer, and how does it differ from role-level privilege?"	"An agent should have exactly the permissions its CURRENT TASK requires, no more — not the permissions the agent's role might need across a day. A support agent looking up an order and the same agent issuing a refund are two tasks with different privilege requirements. If the agent holds both at all times, an injection during lookup can trigger a refund. If it holds only lookup privileges during the lookup task, the credential does not permit escalation. The operational realization is per-task scoped credentials."	c2b::b5::recall
"What is RFC 8693 (OAuth 2.0 Token Exchange), and why is it the technical anchor for per-task scoped credentials?"	"RFC 8693 lets a client trade one token for another with a different scope, audience, or subject. The flow: (1) the agent authenticates and receives a SESSION token (NHI-scoped, TTL of minutes-hours); (2) for each action, the harness exchanges the session token for an ACTION token (narrower scope, specific audience, TTL of seconds-minutes); (3) the harness uses the action token for the call. KEY PROPERTY: the agent never holds a long-lived secret. An injected agent that captures the action token gains at most one action against one audience for the token's remaining TTL (seconds) — it cannot pivot to other APIs, scopes, or principals."	c2b::b5::recall
"What is SPIFFE/SPIRE, and what property does it give the agent?"	"SPIFFE (Secure Production Identity Framework for Everyone) with reference implementation SPIRE is a cryptographically-attested workload identity standard. The agent process does NOT possess a key — it requests a signed SVID (SPIFFE Verifiable Identity Document) from the SPIRE agent on the host, which vouches for the workload based on platform attestation (pod identity, VM instance, process selector). The SVID is short-lived (minutes) and continuously re-attested. PROPERTY: a compromised agent cannot steal 'its' credential because it does not have one — the moment the platform stops vouching (task ends, pod torn down), the identity ceases to be valid."	c2b::b5::recall
"State the four stages of the credential lifecycle and the control each provides."	"(1) ISSUANCE — the credential is minted; scope is set here (and over-scoping happens if the engineer copies a broad policy 'to save time'). (2) SCOPING — the credential's scope is narrowed to the task via token exchange (RFC 8693); least privilege is enforced here. (3) ROTATION — the credential is refreshed before expiry; short-lived credentials rotate continuously, making a stolen credential worthless within minutes. (4) REVOCATION — the credential is invalidated before its TTL (task cancelled, agent compromised); immediate revocation is the kill switch for an active compromise. The lifecycle is short by design — seconds to minutes, not months."	c2b::b5::recall
"What is the single most important design decision in B5 regarding where credentials live?"	"Credentials live in a SECRETS MANAGER THE HARNESS ACCESSES, not in the agent process. The agent NEVER sees the raw credential. The agent process has no AWS_SECRET_ACCESS_KEY in its env, no OAuth token in a config file, no API key in its system prompt. The harness retrieves the credential from the vault, mints the action token via token exchange, makes the authenticated call, and returns ONLY the result to the agent. The agent sees 'I called lookup_order and got this result' — it does not see the token, key, secret, or authorization header."	c2b::b5::recall
"What is the failure mode that credential isolation prevents, and how?"	"FAILURE MODE: an agent that can read its own credentials (env var, config file, system prompt) can exfiltrate them. An injected agent that reads AWS_SECRET_ACCESS_KEY from its env and posts it to an attacker endpoint has handed over a long-lived, broadly-scoped credential — the injection didn't need to USE the credential, only READ and exfiltrate it. PREVENTION: the credential is never in the agent's environment. The harness retrieves it from a vault at call time; the agent process has no reference to the vault. The agent cannot exfiltrate what it does not possess."	c2b::b5::recall
"What is DD-20 IronCurtain's credential quarantine, and how does it relate to B5's vault approach?"	"IronCurtain (Course 1 DD-20): the agent runs with only FAKE API keys. A TLS-terminating MITM proxy, controlled by the harness, hot-swaps fake keys for real ones at the boundary. The agent never holds a real credential — even a fully-compromised agent cannot exfiltrate real credentials because it doesn't have them. RELATIONSHIP TO B5: B5's vault + token-exchange flow achieves the SAME property (agent never holds real credentials) without a proxy. IronCurtain is the conceptual north star; the vault approach is the practical realization. Both achieve: the agent cannot exfiltrate what it does not possess."	c2b::b5::recall
"Name the two OWASP Agentic Top 10 risks B5 owns and what each means at the identity layer."	"ASI03 (Excessive Agency): the agent has more permission than its task requires — over-provisioned NHI, broad scopes (orders:* instead of orders:read). ASI10 (Broken Access Control): the agent acts on behalf of an under-authenticated principal, or a scope-check gap lets it exceed its intended privilege — privilege-escalation chains. Both are identity-layer failures. ASI03 is over-privilege at issuance; ASI10 is missing enforcement at the check/API layer. When both fail, an injected agent can escalate beyond its intended scope."	c2b::b5::recall
"Why is putting an API key in the system prompt the single worst credential anti-pattern?"	"The system prompt is TEXT THE MODEL READS. An injected agent can be coerced into repeating the prompt's contents — including the API key — to an attacker. The key is in the context window, fully visible to the model, and extractable via prompt injection. Unlike an env var (which at least requires the agent to read its environment), the system prompt key is already in the model's working memory. CURE: credentials live in a vault the harness accesses; the system prompt contains NO secrets, ever."	c2b::b5::recall
"Describe the classic ASI10 privilege-escalation chain in agents."	"(1) The agent holds a session token scoped to orders:read. (2) An injection coerces the agent into calling a tool that performs orders:delete. (3) CORRECT behavior: the API rejects the call (token lacks orders:delete scope). (4) ASI10 FAILURE: the harness doesn't check the token's scope before the call (assumes the model wouldn't request unauthorized action), the API's scope check is missing/misconfigured, or the token was over-scoped at issuance (orders:* instead of orders:read). The action succeeds — the agent exceeded its intended privilege. When combined with ASI03 (over-provisioned NHI), the chain is: over-provisioned NHI + missing scope enforcement = full privilege escalation."	c2b::b5::recall
"What are the four layers of defense-in-depth at the identity layer, and which is the deterministic gate B5 implements?"	"(1) PER-TASK SCOPED CREDENTIALS (B5.2) — token narrow at issuance via token exchange. (2) SCOPE-CHECK MIDDLEWARE (B5.3) — the DETERMINISTIC GATE this module implements; verifies the token covers the requested action before the call, no model in the loop, no bypass rate. (3) CREDENTIAL ISOLATION (B5.3) — agent cannot steal a broader credential because it holds none. (4) API-SIDE SCOPE ENFORCEMENT — the target API verifies the token's scope on its end (last line). The conjunction holds: any single layer can fail; the identity layer is secure when an injection must defeat ALL FOUR to escalate. Layer 2 is the analogue of B2's Layer 3 taint gate."	c2b::b5::analysis
"Why does B5's scope-check middleware embody the B2.3 resolution (determinism on the structural boundary) applied to the privilege boundary?"	"B2.3 resolved the probabilistic-vs-deterministic tension by putting determinism on the STRUCTURAL boundary (taint: tainted? high-impact? — enumerable, no bypass rate) and probability on the SEMANTIC boundary (content: is this an injection? — open space, needs a model). B5 applies the SAME resolution to identity: the scope check is STRUCTURAL — 'does this token permit this action?' is a compiled boolean (scope in token.scopes, audience matches, not expired). No model judgment, no bypass rate, no probability. The token's scope is a compiled claim, not a prompt-level instruction the model can be coerced into ignoring. The agent cannot talk its way past a boolean."	c2b::b5::analysis
"How does B5's identity layer relate to B2's Layer 5 (capability minimization) and B4's tool-trust gate?"	"B2's Layer 5 and B4's gate both DEPEND on a credential substrate neither built — that substrate is B5. B2 Layer 5 (capability minimization) is the deterministic floor that says 'the agent cannot call what does not exist' — but if the agent's credential permits more than the capability allowlist, the floor is undermined. B4's tool-trust gate verifies tool provenance but routes over-privilege residuals to B5 (B4's teaching doc: 'capability-minimization residual: over-privilege — closed by B5'). B5 is the blast-radius floor every other defense rests on: an agent with no credentials cannot exfiltrate even if fully injected; an agent with an admin's credentials can exfiltrate the account the moment injection succeeds."	c2b::b5::analysis
"An engineer gives a support agent their personal AWS keys to call the orders API. The agent is later injected and exfiltrates the keys. Describe the full failure chain and the B5 fix."	"FAILURE CHAIN: (1) borrowed human credential — agent inherits engineer's full AWS privilege (read-write, all buckets, not just orders). (2) credential in agent's env — the agent can read AWS_SECRET_ACCESS_KEY. (3) injection succeeds (~50% against undefended agents, per B2/InjecAgent). (4) injected agent reads and exfiltrates the key to an attacker endpoint. (5) the key is long-lived and broadly-scoped — the attacker now has the engineer's full access for months. The compromise looks legitimate in logs. B5 FIX: (a) mint an NHI scoped to orders:read only; (b) put the credential in a vault the harness accesses, not the agent's env; (c) use token exchange so the agent holds only a short-lived action token; (d) scope-check middleware before every call. The injected agent finds no credential to exfiltrate and cannot escalate beyond orders:read."	c2b::b5::analysis
"Contrast IronCurtain's fake-key-swap proxy with B5's vault-and-token-exchange approach. What property do they share, and what are the trade-offs?"	"SHARED PROPERTY: the agent never holds a real credential — it cannot exfiltrate what it does not possess. IRONCURTAIN: agent holds fake keys; a TLS-terminating MITM proxy hot-swaps fake for real at the boundary. Pros: the agent's code is unmodified (it thinks it has real keys); defense is transparent. Cons: requires a proxy in the network path; operational complexity; single point of failure. B5 VAULT: agent holds NO keys; the harness retrieves from a vault and performs token exchange per action. Pros: no proxy needed; works with standard OAuth/cloud IAM; the agent's tool-call path is the integration point. Cons: requires the harness to intercept every tool call (which B2/B4 already do). Both achieve credential isolation; the vault approach is the practical realization for most deployments, IronCurtain is the conceptual north star."	c2b::b5::analysis
"Design the token-exchange flow for an agent that needs to (a) read a customer's orders, then (b) issue a refund. How do the credentials differ between the two actions?"	"(a) READ ORDERS: harness exchanges session token for action token with scope=orders:read, audience=orders-api, TTL=60s. scope_check verifies orders:read covers the lookup call. Token used, discarded. (b) ISSUE REFUND: harness exchanges session token for a DIFFERENT action token with scope=orders:refund, audience=orders-api (or payments-api), TTL=60s. scope_check verifies orders:refund covers the refund call. KEY POINT: the two action tokens have DIFFERENT scopes — the read token cannot be used for the refund, and vice versa. If the agent is injected during the read task and coerced into requesting a refund, the harness mints a read-scoped token (the task is a lookup), the scope_check fails for orders:refund, and the call is blocked. The credential's scope is the task's requirement, not the agent's role's full capability."	c2b::b5::analysis
"Why are short-lived credentials (TTL: seconds to minutes) a defense even if the agent is compromised, and how does this relate to the 'stolen credential' problem?"	"A short-lived credential is worthless to an attacker within minutes of theft. If the action token has a 60-second TTL, an attacker who captures it has at most 60 seconds to use it — and only for the narrow scope and single audience it was minted for. This contrasts with a long-lived human key (TTL: months), which remains useful to an attacker indefinitely. The property: rotation makes stolen credentials expire faster than they can be operationalized. Combined with credential isolation (the agent never holds the session token, only the harness does), the attack surface for credential theft shrinks to near-zero: the action token is the only credential the agent's call path touches, and it is narrow and ephemeral. This is why B5's principle is 'the agent never holds a long-lived secret' — not 'the agent never holds any credential.'"	c2b::b5::analysis
"How does the NHI population in a typical cloud account relate to the human population, and why does this matter for agent deployments?"	"NHIs outnumber humans 10:1 or more in a typical cloud account — and growing. Every service account, every managed identity, every IAM role for a pod, every deploy key is an NHI. Every agent you deploy adds another. Enterprise identity teams that spent a decade on human IAM (SSO, MFA, joiner-mover-leaver) are now confronting a non-human population that their existing tooling and processes were not designed for. This matters because: (1) NHIs don't have MFA, don't get offboarded when a human leaves, and are often over-provisioned because 'it's just a service.' (2) Agent NHIs are the most powerful — they take actions on data — and the least managed. The NHI is the identity surface that B5 governs, and it is the surface real deployments fail on."	c2b::b5::analysis
"What is the role of the authorization server in B5's token-exchange flow, and what must it support for per-task scoping to work?"	"The authorization server (e.g., AWS STS, GCP Workload Identity Federation, Azure AD token endpoint) is the entity that VALIDATES the session token and ISSUES the action token. For per-task scoping to work, it must support: (1) TOKEN EXCHANGE (RFC 8693) — accept grant_type=token-exchange with a subject_token and issue a new token. (2) SCOPE-NARROWING — the client requests specific scopes (orders:read) and the server grants ONLY those, even if the session token's role entitles the agent to more (orders:*). The server must NOT grant broader scopes than requested. (3) AUDIENCE RESTRICTION — the action token is valid only for the specified audience (orders-api), not other APIs. (4) SHORT TTL — the server issues action tokens with TTLs of seconds to minutes. If the server grants broad scopes or long TTLs, the per-task scoping discipline fails at the issuance layer (ASI03)."	c2b::b5::analysis