How to Implement OWASP Agentic Top 10 Controls [2026]

How to Implement OWASP Agentic Top 10 Controls [2026]

You’ll finish this with a working, framework-agnostic checklist for OWASP agentic top 10 controls: where to put policy gates for tool calls (especially around MCP), what to log for every action, what to block outright, and what to push into CI as regression tests. Give yourself 60–90 minutes to map this onto one agent workflow. A day if you want to wire it into prod.

Agent security is having a moment because we’re shipping “autonomous” features before we’ve agreed on boring guardrails. Tool calling, web browsing, and MCP connectors are basically remote hands attached to a probabilistic brain. If you don’t put a real control plane around that, you’re not building an agent. You’re building a breach.

This is intentionally control-first. I don’t care if you’re using LangGraph, AutoGen, OpenAI Agents, Claude Code, or a homegrown orchestrator. The attack surface looks the same.

Here’s the official explainer video that kicked this topic into my feed:

What is the OWASP Agentic Top 10?

The OWASP Agentic Top 10 is a community threat list for AI agents that can take actions in the real world (via tools, connectors, and workflows), focusing on failures introduced by autonomy, tool use, and complex execution graphs. It overlaps with the OWASP Top 10 for Large Language Model Applications, but the agentic lens cares less about “the model said something wrong” and more about “the model did something expensive, irreversible, or exfiltrating.”

OWASP’s LLM guidance already calls out “Excessive Agency” as a risk category, which is basically the seed crystal for the agentic list. Once an LLM can act, misalignment becomes an incident, not a bad answer. If you want the broader GenAI risk taxonomy, start here: OWASP Top 10 for LLM Applications.

How it differs from the OWASP LLM Top 10 (in practice)

The LLM Top 10 is good at naming classics like prompt injection, data leakage, and insecure output handling.

The Agentic Top 10 forces three questions teams love to hand-wave until something breaks:

1. Where exactly do I authorize actions? Not “we do auth,” but which layer is the grown-up.
2. What’s my blast radius per tool call? Dollars, data, and side effects.
3. Can I reconstruct a full kill chain from logs? If not, you don’t have an audit trail. You have vibes.

If you want a foundation before diving into controls, I’d start with my pillar on AI agents and then the threat-model map in AI security.

The architecture I’m assuming (and where controls actually live)

Most “agent frameworks” bury the only boundary security teams actually care about: the moment text turns into actions.

If you’re using the Model Context Protocol (MCP), that boundary becomes a gift. It’s a standard choke point for authN, authZ, redaction, rate limits, and audit.

MCP describes itself as “an open protocol that enables seamless integration between LLM applications and external data sources and tools.” That’s the whole risk. That’s also the whole control plane. Reference: the MCP organization.

I break enforcement into four layers:

1. Agent framework layer (planner, router, tool-selection logic)
2. MCP gateway / tool proxy (a single place to centralize policy)
3. MCP server (tool implementation + last-mile validation)
4. Downstream API / system (your actual SaaS, DB, infra)

If you only do #1, you will get popped. Models drift, prompts rot, and someone will find the weird path through your graph.

You need at least two independent gates.

CI vs runtime: the split that stops security theater

Teams mix these up constantly.

• CI is where you prove behavior. Red teaming, regression suites, policy unit tests, sandbox escape tests.
• Runtime is where you constrain behavior. Authorization, sandboxing, redaction, rate limiting, human approval.

I learned this the hard way running this blog’s multi-agent publishing pipeline. We ship 261+ posts through deterministic checks before any “smart” review step. The boring gates catch more failures than throwing a bigger model at the problem.

Same idea for agents. Deterministic policy beats “please be safe” prompts.

If you want the testing side, non-deterministic AI system testing pairs well with this.

OWASP agentic top 10 controls: mapping table (controls + enforcement points)

This is the part I wish more people published. Security teams don’t need another taxonomy. They need an implementation backlog.

I’m going to use 10 agentic risk buckets that match what teams are actually dealing with in production: prompt injection chains, tool abuse, data exfil, sandbox escape, identity confusion, supply chain, logging gaps, DoS/cost blowups, unsafe outputs that trigger actions, and model/tool drift.

Use this table as your backlog.

A note on naming: OWASP’s public “Top 10 for LLM Applications” has stable categories today. The “Agentic Top 10” label is still consolidating across the community. I’m mapping to the agent-specific realities while staying aligned with OWASP’s core risks like prompt injection, data leakage, and excessive agency.

Where tool-call authorization should happen (and why “just do it in the agent” is wrong)

If you’re building anything serious, you want defense in depth across at least two layers.

Here’s the model I actually trust:

• The agent framework decides intent. It can propose actions.
• A policy engine decides permission. It must be deterministic.
• The tool server decides validation. It must assume the caller is compromised.

That middle layer is where Open Policy Agent (OPA) shines. OPA is a graduated CNCF policy engine designed to decouple policy from application logic, so teams don’t hardcode allow/deny decisions into the agent. OPA explicitly calls out “AI tool calling” as a use case. The whole pitch is central policy plus auditability: Open Policy Agent.

My recommended placement model (MCP-aware)

1. Agent framework layer (soft gate)
   • Enforce tool allowlists per workflow.
   • Enforce schemas (JSON Schema / Pydantic model) for tool arguments.
   • Enforce “no tool calls while reading untrusted text” rules in code.
2. MCP gateway (hard gate)
   • Central authZ for every tool call.
   • Central redaction for tool inputs/outputs.
   • Central rate limiting and budgets.
   • Central audit events.
3. MCP server (last-mile gate)
   • Validate arguments again.
   • Enforce server-side scopes.
   • Apply row-level or document-level authorization.
4. Downstream API (existing gate)
   • OAuth scopes, service-to-service auth, tenancy.
   • Idempotency keys for side effects.

If you skip the MCP gateway and rely on “agent prompt discipline,” you’re betting your security posture on a string literal.

Concrete “block vs gate” rules I use

These are boring. That’s why they work.

Block outright

1. Tool calls triggered while the model is ingesting untrusted content (web, email, docs) unless the tool is read-only.
2. Any tool call that introduces new network egress destinations (no dynamic URLs).
3. Shell execution with write access to host mounts.
4. “Fetch arbitrary URL” tools without allowlists.
5. Any action lacking a stable trace_id and immutable audit write.

Gate with step-up approval (HITL / JIT)

1. Money movement.
2. Permission changes (IAM, Google Workspace, GitHub org settings).
3. Bulk export (anything above 100 records, 50MB, or 1 minute of continuous retrieval).
4. Writes to production data stores.
5. Deployments.

If you need patterns for approval workflows, 10 HITL tool approval patterns for AI agents is the companion piece.

Logging and audit: the minimum viable trail for incident response

If an agent can act, you need logs that hold up in a post-mortem.

“We logged the prompt” is not an audit trail. It’s a privacy incident waiting to happen.

Here’s what I consider non-negotiable for every agent action:

• Identity & intent
  • end_user_id (or subject_id), tenant_id
  • agent_id, workflow_id, run_id
  • requested_capabilities (tool categories)
• Decision chain
  • tool_name, tool_version, mcp_server_id
  • policy_engine (e.g., OPA), policy_version, policy_decision (allow|deny|step_up)
  • approval_required + approval_actor (if any)
• Context provenance
  • retrieval_sources_count (number)
  • retrieval_source_types (e.g., web, drive, confluence)
  • untrusted_input_present (boolean)
• Safety + privacy
  • redaction_hits (number)
  • data_classification (e.g., public, internal, pii, secrets)
• Cost + performance
  • tokens_in, tokens_out (numbers)
  • tool_latency_ms, model_latency_ms
  • tool_retries (number)

If you want a concrete schema, reuse the exact shape from AI agent observability logging schema and wire it into OpenTelemetry instrumentation for AI agents.

One hard rule: log hashes, not raw secrets. If you need to reconstruct, store redacted payloads separately with a tighter access-control path and a real retention policy. My deeper playbook is LLM data leakage playbook.

Sandboxing risky tools (browser, shell, code exec) without lying to yourself

If your agent runs code, browses the web, or touches files, you’re executing untrusted workloads. Treat it that way.

This is where a real sandbox matters. I like gVisor because it’s explicitly positioned as “the missing security layer for running containers efficiently and securely,” intercepting syscalls and reducing host-kernel exposure. It’s designed for running user-uploaded or LLM-generated code. Source: gVisor documentation.

A practical sandbox blueprint

For each “risky tool” (browser, shell, code interpreter), I want:

1. No host filesystem mounts
   • Mount an ephemeral working directory.
   • If you must mount, mount read-only and only a narrow path.
2. Network egress control
   • Default deny.
   • Allowlist domains (by suffix) and IP ranges.
   • Block link-local (169.254.0.0/16), metadata endpoints, and internal RFC1918 ranges unless explicitly needed.
3. Secrets isolation
   • No ambient credentials.
   • Inject short-lived, scoped tokens per tool call.
   • Rotate at least every 15 minutes for high-risk connectors.
4. Resource limits
   • CPU quota.
   • Memory ceiling.
   • Hard wall-clock timeout (e.g., 30s for browser fetch, 120s for code execution).
5. Observable denials
   • Every blocked syscall and denied egress should emit an event.
   • If your sandbox blocks silently, your agent will retry and amplify cost.

If you’re not on Kubernetes, a VM-based approach can still be clean. I wrote a full recipe in AI agent sandbox Linux VM.

The uncomfortable truth about “browser tools”

A browsing tool is not “read-only.” The web is full of indirect prompt injection payloads. If your agent can read a page and then call send_email, that’s a write primitive.

So I treat browser outputs as untrusted input, always.

• Browser tool output must be tagged untrusted.
• Any subsequent tool call requires a stricter policy.
• The agent must summarize and extract facts, not pass through raw page content.

Pair this with indirect prompt injection in AI agents and prompt injection regression testing.

Redaction + data minimization: do it four times, not once

Most teams implement redaction like a checkbox. They redact the prompt going into the model and call it done.

That’s wrong.

Agent systems have multiple leak points:

1. Prompt assembly
2. Tool inputs
3. Tool outputs
4. Traces/logs

If you don’t cover all four, you’ll leak anyway.

The control pattern that works

• Before the model: redact secrets and PII from user input and retrieved context.
• Before tools: redact or transform tool arguments (e.g., replace emails with stable pseudonyms).
• After tools: filter tool outputs to remove sensitive fields before they re-enter the agent context.
• Before logging: apply a log redaction layer with deterministic rules.

Concrete example: if a tool returns a JSON object with 50 fields, the agent probably needs 5. Strip the rest. If you don’t, you’re increasing both leakage risk and LLM cost through token bloat.

For implementation patterns, see field-level redaction for RAG pipelines and the CLI-oriented version in redact secrets in an AI coding CLI tool.

One data anchor I can defend from my own site work: in my benchmarks and tooling writeups, the single biggest driver of cost and risk is context size. Based on the agent cost breakdowns I’ve published on this blog (see agent per-task cost calculation), tool traces and verbose retrieval payloads routinely dominate token usage when teams turn on “helpful” logging. The fix is simple. Log structured metadata, store redacted payloads separately, and set retention policies that don’t make your legal team roll their eyes.

CI: continuous red teaming, evals, and regression suites that actually catch agent failures

Runtime guardrails are necessary. They’re not sufficient.

You also need CI gates that prove:

• Prompt injection attempts don’t trigger tool calls.
• Data leakage attempts don’t exfiltrate.
• Tool failures don’t cause runaway retry loops.
• Policy changes don’t silently expand permissions.

Microsoft’s red teaming guidance frames it as systematic adversarial testing across the product lifecycle, and it recommends doing an initial manual pass before you formalize measurement. Source: Microsoft Learn red teaming guidance.

A CI recipe I’d ship for any agent feature

1. Injection regression suite
   • At least 50 attack prompts.
   • Include indirect injection payloads from HTML, PDFs, and “helpful instructions” in docs.
   • Fail the build if any high-risk tool call is attempted.
2. Policy unit tests (OPA / policy-as-code)
   • Test allow/deny across tenants, roles, and tool scopes.
   • Treat policy like code. Code review it.
3. Sandbox escape tests
   • Attempt blocked syscalls.
   • Attempt metadata endpoint access.
   • Attempt file reads outside the working directory.
4. Leakage evals
   • Seed canary secrets.
   • Confirm they never appear in tool outputs, model outputs, or logs.
5. Chaos tests for tool failures
   • 429s, timeouts, partial responses.
   • Verify circuit breakers and retry caps.

If you want a head start on harnesses, stitch together AI engineering evals gates, agent tool call failure testing, and RAG data leakage test suite.

The number you should actually enforce

Pick a small set of deterministic budgets and enforce them:

• Max tool calls per run: 20 (most real tasks should fit)
• Max retries per tool call: 2
• Max tokens per run: 50,000 (tune by workload)
• Max wall time: 120s (unless you’re in async workflow land)

If your agent can’t complete a task inside those budgets, it’s not “smart.” It’s unstable.

A 7-step implementation checklist (start here)

If you’re implementing OWASP agentic top 10 controls this week, do this in order:

1. Inventory every tool and classify it as read, write, or irreversible.
2. Put an authorization gate in front of _every_ tool call (OPA or equivalent).
3. Add step-up approval for irreversible tools.
4. Sandbox code execution and browsing (gVisor or a VM). Default deny network.
5. Implement redaction at four points: prompt, tool-in, tool-out, logs.
6. Ship structured audit events with trace_id and policy_version.
7. Add CI regression suites for injection, leakage, policy, and runaway loops.

This sounds like a lot. It’s not. It’s the minimum if you want to sleep.

If you’re deep in MCP specifically, pair this with: How to secure MCP servers: auth + authZ.

Agent security is going to split teams into two camps.

One camp will keep shipping agents as “smart scripts” and keep acting shocked when a browser payload turns into a tool call that turns into an incident.

The other camp will build a real control plane. Policy gates. Sandboxes. Redaction. Audit that makes their agents boring to attack.

My prediction: by the end of 2026, “agent framework” won’t be the buying decision. Policy and auditability will be. If your agent platform can’t tell you who approved a tool call, what policy allowed it, and what data left the building, it’s not an enterprise product. It’s a demo with a runway.

Photo by Mike Meyers on Unsplash.