OWASP Top 10 for Agentic Applications control mapping

OWASP's Top 10 for Agentic Applications frames security problems created when systems plan, delegate, remember and act through tools. A useful response is not a logo on a compliance page. It is a dated threat-to-control map for the actual workflow, with tests and evidence.

This mapping summarizes control questions rather than reproducing OWASP's text. Review the primary source and tailor the threat model to the deployed system.

How should the risks map to controls?

OWASP agentic risk area	Preventive control	Test and evidence
Agent goal hijack	Separate instructions from untrusted content; enforce policy outside the model	Adversarial content corpus, denied-action events
Tool misuse and exploitation	Typed operations, least privilege, parameter validation and egress control	Invalid-operation and boundary tests, tool receipts
Identity and privilege abuse	Workload identity, delegation limits, ABAC and credential isolation	Cross-role, expired-token and confused-deputy tests
Agentic supply chain	Signed artifacts, provenance, allowlists and controlled updates	Bill of materials, verification and rollback exercise
Unexpected code execution	Sandboxing, restricted interpreters and prohibited arbitrary execution	Escape, filesystem, network and command-negative tests
Memory and context poisoning	Source labeling, trust partitions, retention controls and revalidation	Poisoned-memory fixtures and provenance inspection
Insecure inter-agent communication	Authenticated messages, schemas, authorization and replay defense	Spoof, replay, tamper and delegation-chain tests
Cascading failures	Budgets, circuit breakers, bounded recursion and reconciliation	Dependency loss, retry storm and partial-success tests
Human-agent trust exploitation	Clear attribution, material-action review and anti-deception design	Usability study, approval-quality and override review
Rogue agents	Inventory, attestation, revocation, behavior bounds and kill paths	Unknown-agent, revoked-agent and stop-procedure tests

Risk names and details evolve. Keep the authoritative OWASP publication as the source of record.

Why must controls sit outside the model?

The model is part of the system being governed. It can recommend a tool call, explain a decision or flag suspicious input, but it should not be the sole authority deciding whether its own action is permitted.

Place identity, policy, schema validation, approval and evidence at deterministic boundaries around the model. If a prompt injection succeeds at changing the plan, the action still faces the same authorization and consequence rules.

How should tools be designed?

Expose narrow operations with explicit parameters and responses. Separate read from write. Avoid generic shell, arbitrary HTTP and broad database access when a bounded adapter can express the approved task. Apply destination, tenant and classification constraints inside the boundary.

Treat the target response as untrusted. Validate it, distinguish accepted from completed work, retain an idempotency key and reconcile ambiguous timeouts before retrying.

How should identity and delegation work?

Every agent, human and service needs a traceable identity. A delegated action should retain who initiated it, which agent accepted it, the permitted scope, the delegation depth and the expiration. Downstream services should not receive a reusable credential broader than the action.

Test the confused-deputy path: an authorized agent is asked by an unauthorized context to perform an otherwise permitted action. The policy needs both subject and context, not just possession of a token.

How should teams handle memory and provenance?

Label the origin, trust level, time and allowed use of memory. Separate instructions, verified facts, user content, retrieved documents and model-generated summaries. Revalidate sensitive facts before consequential action and expire content that no longer has a supportable basis.

Preserve enough provenance to answer which sources affected a decision. Do not store unrestricted sensitive context merely to make later reconstruction easier.

Which failure tests reveal cascading risk?

Interrupt each dependency at multiple points: before request, after acceptance, during result retrieval and during audit commitment. Exercise retry budgets, recursive delegation limits, queue backpressure, reviewer unavailability and model-route failure.

The safe state must be explicit. Depending on the operation, that may be deny, hold, retry with the same idempotency key, reconcile or require operator action. Silent best-effort continuation is not a recovery design.

What should a release evidence package contain?

Include the scoped architecture, threat model, risk-to-control table, policy suite, negative tests, tool contracts, identity and delegation model, approval design, audit coverage, evaluation results, known limitations and rollback procedure. Bind every artifact to the release and environment tested.

Security posture changes when a tool, model, memory source, identity provider or deployment boundary changes. Reopen the affected risks rather than carrying an evergreen claim forward.