Slide 17 of 28
Part 3 — Attack ScenariosSlide 17
Slide 17 · The Pattern
Every ASI02 scenario has the same root cause
Nine different scenarios. One underlying failure. Fix the root cause and you address all of them.
The root cause

Authorization and intent are separated. A tool is authorized once — at setup time — for a purpose. But the agent can invoke it for any purpose it can conceive. There is no per-invocation check asking: "Does this use of this tool match the intent the tool was authorized for?"

In every scenario, the same failure appears

Scenario 01–02 (injection and pivot): The tool was authorized. The authorizing developer never considered that the tool could be invoked in response to content the agent reads — not just user requests.

Scenario 03–04 (over-privileged APIs): The tool's scope was set to "everything it can do," not "everything this agent needs." No one asked: what is the minimum the agent needs to accomplish its task?

Scenarios 05–06 (typosquatting, DNS): The tool was approved based on its name or category, not its full behavior profile. No validation of what the tool actually does at invocation time.

Scenarios 07–09 (misalignment, loops): There was no ceiling — no budget, no scope limit, no human gate before irreversible actions were taken at scale.

The thing that makes ASI02 uniquely hard to stop

Traditional security controls (firewalls, access control lists, IAM policies) check who is calling and what they're allowed to call. They cannot check why the call is being made. Intent validation is the missing control in agentic AI, and it doesn't exist in most current deployments.

One line to remember

Every ASI02 attack exploits the gap between what the tool is authorized to do and what this agent should be doing right now. Close that gap and you address the entire category.

← Back Now I get it → How do we defend against this?