AG03:2026 — Identity and Privilege Abuse

QUESTION 01 OF 05

An IT admin agent holds SSH credentials in memory after completing a server patch. Later, a support engineer with limited access prompts the agent to set up SSH access for them — and it does, using the cached admin credentials. What is the core reason this is a security failure?

Correct — this is the memory-based privilege retention pattern. The admin's SSH credentials were never revoked from the agent's context after the original task ended. When the next user interacted with the same agent, those credentials were still available. No exploit, no social engineering — just credentials that persisted past their intended scope.

Not quite — the key here is memory persistence. The SSH server had no vulnerability, no engineering trickery was involved, and tool usage wasn't the issue. The failure was architectural: the agent's memory wasn't cleared between sessions, so admin credentials from an earlier task were still accessible to whoever prompted the agent next.

QUESTION 02 OF 05

A finance manager agent delegates a reporting task to a DB query sub-agent, passing its full permission set. An attacker steers the sub-agent to access HR and legal data. What is the underlying vulnerability?

Correct — un-scoped privilege inheritance. The finance agent delegated the task but passed its full permission context rather than a narrowly scoped token that only allows reading the specific report table. The attacker who compromised the sub-agent effectively compromised the finance manager's full access, because the delegation chain didn't enforce scope boundaries.

Not quite — the issue is scoping at delegation time. The DB query agent didn't have admin access independently, and no encryption was broken. The attacker didn't need to exploit the tool — they just steered the sub-agent that already had the finance manager's full privileges. The fix is narrowing the token at the point of delegation, not at the tool level.

QUESTION 03 OF 05

A crafted email instructs an email-sorting agent to forward a payment instruction to a finance agent. The finance agent processes the payment because it trusts messages from internal agents. What security principle does this violate?

Correct — this is the confused deputy pattern. The finance agent trusted an internal agent's forwarded message as implicitly authorized — but it never verified whether the original sender had authority to issue a payment instruction. Per-action authorization (MIT 03) would require the finance agent to re-verify the original authorization source for any payment action, regardless of who forwarded the request.

Not quite — per-action authorization is the key principle violated here. Least privilege isn't the issue (the email agent was doing its job). Memory isolation doesn't apply. Data minimization doesn't explain why the payment happened. The problem is that the finance agent accepted a payment instruction from an internal relay without verifying the original user's authorization for that specific payment.

QUESTION 04 OF 05

A procurement agent validates a user's $50,000 spending limit at the start of a long-running workflow. Midway through, the limit is reduced to $10,000 — but the agent isn't notified and completes the full $50,000 transaction using the original token. What type of vulnerability is this?

Correct — this is the TOCTOU (Time-of-Check to Time-of-Use) authorization drift pattern. The check happened at one point in time; the action happened later, after the authorization had changed. The token was valid when issued, but the underlying permission it represented had been revoked. This is why both MIT 01 (time-bound tokens) and MIT 03 (per-action authorization) are needed — tokens must expire, and re-verification must happen at the point of action, not just at session start.

Not quite — authorization drift is the answer. Memory retention is about credentials persisting across sessions (which isn't what happened here). Delegated privilege is about scope expansion in a chain. Synthetic identity is about forged agents. This scenario is specifically about the gap between when a permission was validated and when it was used — and how that gap can be exploited if authorization state changes mid-workflow.

QUESTION 05 OF 05

Why does giving agents managed non-human identities (with their own distinct identity records and credentials) improve security — rather than just using the deploying user's credentials?

Correct — the attribution gap is the root cause of most AG03 failures. When an agent borrows a human's identity, you can't enforce least privilege on the agent independently (you'd be constraining the human). You can't audit what the agent did separately from what the human did. You can't revoke the agent's access without affecting the human. A managed non-human identity solves all three: the agent has its own bounded, auditable, revocable identity that is distinct from any human account.

Not quite — managed identities aren't about more power or automatic encryption. They're about attribution and control. When an agent uses a managed identity, every action it takes is logged against that identity, its permissions can be scoped independently of any human account, and its access can be revoked without affecting any user. This is the structural fix for the attribution gap that makes least privilege enforcement possible in agentic systems.