Slide 17 of 28
Part 3 — Attack ScenariosSlide 17
Slide 17 · The Pattern
All seven scenarios share the same root cause
The specific attacks look different — delegation, memory, phishing, forgery — but they all exploit the same architectural gap.
The root cause

Agents don't have governed identities of their own. They borrow identity from their operators, their users, or each other. They carry privilege across contexts it was never scoped for. They trust other agents without verifying the original source of authority. They hold credentials past the session that authorized them.

The access control systems surrounding them were designed to ask: "Is this user authorized for this action?" They were not designed to ask: "Is this agent carrying identity and privilege that is currently valid, correctly scoped, and genuinely appropriate for the task it is attempting right now?"

Three questions that current systems don't ask

1. Where did this privilege come from? Was it granted directly for this task, or inherited through a delegation chain? If inherited — was the scope narrowed at each step?

2. Is this privilege still valid? Was it granted for a session that has ended? For a user whose authorization has since changed? For a task that has already completed?

3. Who is this agent, really? Is its claimed identity verified by something stronger than its own descriptor? Is there cryptographic attestation that it is who it says it is?

Why this matters for defenders

Defenders who only look at whether a specific tool call was authorized are missing the full picture. Authorization at the action level is necessary — but not sufficient. You also need to verify that the agent executing the action has authority that is currently valid, correctly sourced, and appropriately scoped. That requires a different set of controls.

That's what Part 4 covers.

← Back Part 4 → How to defend against this