Threat dossier · P1
Identity spoofing and confused deputy
Agents act on natural-language claims of identity and intent, so a spoofed principal can redirect tools, credentials, and approvals that were granted to someone else.
Direct answer
What is identity spoofing and confused deputy?
Identity spoofing lets an attacker or tool output impersonate a trusted principal — a user, an upstream agent, or a service — so a consequential action is authorized on behalf of the wrong identity, the classic confused-deputy failure.
Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.
Representative attack path
Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.
Step 1
Attacker crafts a message, tool response, or delegated request claiming to be a trusted user, service, or upstream agent.
Step 2
The agent cannot cryptographically verify the claim inside the conversation.
Step 3
The spoofed identity is treated as authority for a sensitive action.
Step 4
The action executes with the agent’s real credentials and permissions.
Coverage boundary
What this control can cover
- Consequential actions requested under a spoofed claim still pass runtime policy before execution on supported action surfaces.
- Decision evidence records the claimed origin so the spoof is reviewable after the fact.
What it does not prove or prevent
- Cryptographic attestation of who or what produced a prompt, tool result, or delegation.
- Identity or session infrastructure outside the supported integration boundary.
Policy pattern
Policy pattern for identity spoofing and confused deputy
Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.
Use when: Agents act on natural-language claims of identity and intent, so a spoofed principal can redirect tools, credentials, and approvals that were granted to someone else.
Decision pattern
- Identify the trust boundary and consequential action class.
- Apply least privilege and the narrowest supported policy.
- Require review for sensitive or ambiguous actions.
- Preserve only redacted, versioned evidence needed to reproduce the decision.
Limitations
- Cryptographic attestation of who or what produced a prompt, tool result, or delegation.
- Identity or session infrastructure outside the supported integration boundary.
If you suspect prompt injection
Step 1
Response 1
Halt the affected workflow and revoke tokens issued for it.
Step 2
Response 2
Compare the claimed identity against provider-side authentication logs.
Step 3
Response 3
Reduce the spoofed principal’s standing permissions where possible.
Step 4
Response 4
Replay the exchange with synthetic fixtures before restoring access.
Sources and mappings
Related dossiers
Neighboring threat classes that share attack paths or trust boundaries with this dossier.