Your AI agent is now an authorization boundary. If you haven't designed it that way, an attacker can use the agent's reasoning to perform actions your credentials were never supposed to allow.
The Problem
AI agents fail at authorization in a specific way: they can be prompted into translating an instruction they received at high privilege into an action that executes with whatever credentials the agent holds — regardless of whether those credentials are appropriate for the requested action. This isn't a traditional privilege escalation. The agent isn't breaking an access control. It's reasoning about the request and taking what it believes is the right action, using the permissions it has.
Brendan Dolan-Gavitt and Vincent Olesen documented this at [un]prompted 2026, building a system to detect authorization vulnerabilities in AI agents. Their two-checkpoint validation architecture is the most transferable design pattern from that work.
Full research → https://thecyberarchive.com/talks/ai-agents-auth-vulnerability-detection/
Defense 1: Separate Agent Reasoning from Authorization Enforcement
The "auth transmogrification" pattern from the NYU/Dolan-Gavitt research is the core fix. Instead of letting an agent directly execute any action it decides to take, insert a translation layer: a dynamically generated script that converts the requested action into its minimum-privilege equivalent before execution.
In practice: the agent requests "delete this user record." The translation layer converts that into "mark this user record as inactive" using read-write credentials rather than admin-level delete. The agent never knows the translation occurred. The system enforces least privilege without requiring the agent to reason about it.
Implementation note: the translation must be generated dynamically per-action, not as a static lookup table. Static lookup tables miss novel action patterns. Dynamic generation handles arbitrary agent requests.
Defense 2: Implement Two-Checkpoint Validation Before Any Action Is Reported or Executed
Dolan-Gavitt and Olesen's validator model is the second critical piece. Their rule: agents reason, validators confirm. Nothing gets reported or executed without both checkpoints clearing.
The two checkpoints they used:
- Browser state checkpoint: verify the action is consistent with expected session state
- API auth checkpoint: verify the requesting credential is authorized for this specific action at this specific resource
A finding or action that clears reasoning but fails either validator gets dropped — not flagged for human review, dropped. This keeps the signal-to-noise ratio high enough that human oversight stays manageable.
Applied to your architecture: identify the two most load-bearing trust assertions for any action your agent can take. Build validators for those two specifically. Start there before adding more complexity.
Defense 3: Use Sequential Pipelines, Not Autonomous Orchestration
Jeffrey Zhang and Siddh Shah at Stripe ([un]prompted 2026) ran a direct architectural comparison. Their autonomous orchestrator inconsistently skipped pipeline stages — it made routing decisions that occasionally bypassed agents it judged unnecessary. Those routing decisions were wrong enough to degrade reliability across the board.
Sequential pipelines with explicit handoffs between named agents solved this. Each stage runs deterministically. No stage can be skipped by an orchestrator's judgment. The pipeline is predictable and auditable.
For authorization specifically: if your pipeline has a step that checks whether a requested action is authorized, that step cannot be in a position where an autonomous orchestrator can skip it. Put authorization validation in a sequential stage with an explicit handoff requirement.
Full Stripe architecture → https://thecyberarchive.com/talks/ai-security-agents-production-stripe-guardrails-playbook/
Defense 4: Add Security Constraint Descriptions to Your Repository
This is the lowest-effort high-value control from McMillan and Lopopolo at OpenAI ([un]prompted 2026). Two sentences in a security.md file describing the constraints your code should never violate — path traversal, privilege escalation, unauthorized data access — are enough for an AI-assisted CI/CD pipeline to catch violations automatically.
This works as a defense-in-depth layer for agent code specifically: if your CI/CD pipeline includes AI-assisted code review and your security.md explicitly states "agents must not execute actions using credentials above the permission level specified in the request context," that description becomes a reviewable invariant. Violations surface before deployment.
Full CI/CD implementation → https://thecyberarchive.com/talks/ai-security-guardrails-cicd-the-free-approach/
The Bottom Line
- Auth transmogrification: translate every agent action to minimum-privilege equivalent before execution
- Two-checkpoint validation: browser state + API auth must both confirm before any action proceeds
- Sequential pipelines only: no autonomous orchestrators that can skip authorization stages
- Security constraint descriptions in
security.md: make authorization invariants explicit and reviewable - Classical IDORs are a separate problem — agent auth attacks exploit reasoning, not access control gaps
Browse AI agent security talks → https://thecyberarchive.com/topics/ai-agent-security/
Top comments (0)