OWASP, NIST, AWS, Google, Microsoft, the Cloud Security Alliance and MITRE have all published guidance on AI agent risk. They overlap, and each uses its own words.
This page lines them up and maps them to controls you can deploy, including an AI agent allow list for web navigation.
They are not competitors. Each was written for a different reader and a different job.
Threat catalogues: OWASP agentic threats, Microsoft's failure-mode taxonomy, MITRE ATLAS.
Scoping tools: the AWS agentic AI security scoping matrix.
Method: CSA MAESTRO, a layered threat-modelling approach for agents.
Management systems: NIST AI RMF and its generative AI profile.
Design principles: Google's approach to secure AI agents and SAIF.
None of them lists products. The crosswalk below turns them into controls.
Two warnings before you start. None of these frameworks is a certification you can pass.
And none replaces the others: a threat catalogue without a management system produces findings nobody owns.
From OWASP's Agentic Security Initiative. A catalogue of 15 agent-specific threats with mitigations.
A general AI risk framework with four functions: Govern, Map, Measure, Manage.
Sorts agents into four scopes by how much agency they have, then lists controls per scope.
Google's Secure AI Framework plus its published approach to secure agents.
A whitepaper that classifies how agentic systems fail, both security and safety failures.
A threat-modelling method built for multi-agent systems, organised in layers.
A knowledge base of adversary tactics and techniques against AI systems, modelled on ATT&CK.
Summaries reflect each publisher's own descriptions. Always use the latest published version.
Highlighted threats are the ones where controlling which pages an agent may open directly reduces the risk.
Seven of the fifteen involve the agent doing something on a web page. That is why navigation policy belongs in any agent threat model.
| Action page type | What the agent could do | OWASP threat |
|---|---|---|
| signup | Create accounts in your company's name | T9 identity spoofing |
| password_reset | Take over or lock out an account | T3 privilege compromise |
| cart and checkout | Spend money without approval | T2 tool misuse |
| subscribe | Start recurring charges or mailing lists | T2 tool misuse |
| upload | Push files or data to outside services | T11 code execution, data loss |
| post_create and comment | Publish content as your organisation | T13 rogue agents, T15 manipulation |
The model only answers. It takes no actions.
Web control: none needed for the model itself.
Actions follow fixed workflows that people designed.
Web control: allow only the pages the workflow needs.
The agent plans its own steps, with human approval points.
Web control: deny action pages, require approval to pass.
The agent acts on its own over long tasks.
Web control: default-deny, page-type policy on every request.
The higher the scope, the less you can rely on the agent's instructions. Scope 3 and 4 agents need deterministic boundaries.
A pricing-watch agent visits a fixed list of vendor pricing pages each week. Everything else is denied.
A procurement agent researches freely, but any signup or checkout page sends an approval request to a buyer.
A long-running research agent works for days. Action pages and unclassified hosts are denied, and every request is logged.
Read across a row to see which framework asks for the control. Read the last column for what to deploy.
| Control | OWASP agentic | NIST AI RMF | AWS matrix | What to deploy | |
|---|---|---|---|---|---|
| Agent inventory | T13 rogue agents | Map | All scopes | Human controllers | AI-SPM or governance register |
| Scoped agent identity | T3, T9 | Manage | Scope 3 and 4 | Limited powers | Non-human identity platform |
| Approved tools only | T2 tool misuse | Manage | Scope 2 and up | Limited powers | MCP gateway allowlist |
| Page-level web policy | T2, T3, T9, T11 | Manage | Scope 3 and 4 | Limited powers | AI agent allow list data at tool or proxy |
| Default-deny egress | T13 | Manage | Scope 4 | Limited powers | Egress proxy with unclassified = deny |
| Injection detection | T6 | Measure | Scope 3 and 4 | Observable actions | Runtime protection |
| Human approval points | T10 | Govern | Scope 3 | Human controllers | Workflow approvals on denied action pages |
| Full action logging | T8 | Measure | All scopes | Observable actions | Observability plus decision logs |
| Pre-release testing | All | Measure | Scope 3 and 4 | Assurance | Red teaming |
| Incident response | T8, T13 | Manage | All scopes | Observable actions | Playbook, kill switch, audit trail |
Mappings are our reading of each framework, meant as a starting point for your own control matrix.
Rows marked "all scopes" apply even to the simplest agent. Start there if you can only do a few things this quarter.
Every framework says agent powers must be limited. On the web, that means a check before each request.
About 60 high-risk hosts, such as cloud metadata endpoints, always denied.
28 page types on 40M+ domains, with action pages denied by default.
About 40 URL rules for risky patterns on any domain, such as wiki edits and WebDAV.
A fourth layer denies anything unclassified. Details: agent guardrails and the egress rules library.
| Your situation | Start with | Add next |
|---|---|---|
| You already run an AI governance programme | NIST AI RMF | OWASP agentic threats for the agent layer |
| You build agents on AWS | AWS scoping matrix | OWASP threats per scope |
| You need a threat model this month | OWASP agentic threats | CSA MAESTRO for multi-agent designs |
| You run a red team | Microsoft taxonomy | MITRE ATLAS for technique IDs |
| Your SOC needs detections | MITRE ATLAS | OWASP threats for context |
| You design agent products | Google's agent principles | AWS scopes to size controls |
Name, owner, tools, credentials, and whether it reaches the web.
Use the four AWS scopes. Be honest about full agency.
From the 15 OWASP threats, keep the ones each agent can realistically face.
Use the crosswalk above. One control can cover several threats.
Test each control, keep the logs, and review after every agent change.
Agents gain tools over time, so scopes and controls must be re-checked.
| Evidence requested | Framework link | Source system |
|---|---|---|
| Register of agents with owners | NIST Govern and Map | Governance tool or AI-SPM |
| Proof that agent powers are limited | Google principles, AWS scopes | Identity scopes, tool allowlists, page policy |
| List of blocked action attempts | OWASP T2 and T13 | Page-policy decision log |
| Record of every page an agent opened | OWASP T8 | Egress proxy or tool logs |
| Test results before release | NIST Measure | Red-team reports |
| Response to a past incident | NIST Manage | Incident tickets and timelines |
A page-policy decision log answers two of these rows directly: blocked attempts and pages visited.
Keep those logs for at least as long as your incident review window. Auditors often ask for twelve months of history.
The honest fine print — the same two assumptions we publish, plus two operational ones
One page-type check before each request, mapped to every framework above.
