This is a working map from agentic risk themes to controls you can switch on and tests you can run. It follows the categories in the OWASP work on agentic applications, which cover risks such as goal hijacking, tool misuse, identity abuse and weak oversight. We describe the themes in our own words here. Check the published OWASP document for its exact item names and numbering before you cite them.
For each theme you get three things: what it looks like in practice, the control, and how to test it.
How to use this map
Read it as a gap list. For each theme, ask whether you have the control, whether it is switched on for every agent, and whether you have ever tested it. A control nobody has tested is a guess.
The risk themes
Goal hijacking
In practice: a web page, email or document the agent reads contains instructions, and the agent follows them instead of the user's request.
Example: a support agent summarises an inbound ticket that quietly asks it to send the customer list to an outside address. The summary is harmless. The risk is the send-mail call that follows, and that is the call the policy should deny, because the context came from untrusted content.
Control: guardrails on prompts, retrieved documents and tool results, plus a policy that denies high-impact calls when the context came from untrusted content.
Test: run indirect prompt injection plugins and multi-turn strategies such as crescendo against the agent, and confirm the high-impact call is denied.
Tool misuse and over-broad permissions
In practice: an agent connected to a mail tool can also delete mail, because the tool was granted whole.
Example: a calendar tool is granted whole, so the agent can read, create and delete events for everyone. Its real job is to read one person's free slots. A policy that allows reads on that calendar only, with a limit on the parameters, means a delete call fails even though the tool is connected.
Control: least-privilege tool policies, written as code, checked at every call, with parameter limits.
Test: replay real calls through the policy simulator, then try calls outside the intended scope and confirm they are denied.
Identity and privilege abuse
In practice: several agents share one API key, or an agent inherits a person's full access instead of a slice of it.
Control: one identity per agent, rotating credentials, and signed delegation tokens that record who delegated what.
Test: list credentials by agent, confirm no sharing, and try a call that exceeds the delegated scope.
Memory and context poisoning
In practice: a bad fact gets written into long-term memory or a vector store and shapes every later run.
Control: scanning on retrieval and document stages, and behaviour alerts when parameters drift from the agent's baseline.
Test: use a memory-poison conversation strategy to plant an instruction, then check whether a later session acts on it.
Insecure inter-agent communication
In practice: one agent trusts whatever another agent sends, so a compromised agent can steer the rest.
Control: identity on both sides, delegation depth limits, and alerts on unusual delegation depth or new initiators.
Test: have one agent send a forged task to another and confirm the receiver checks the sender's identity and scope.
Supply chain of tools and MCP servers
In practice: a tool description is changed after you approved it, or a lookalike server name is installed by mistake.
Control: an outbound allowlist at the MCP gateway and catalog checks for poisoned descriptions, over-broad scopes, lookalike names and drift after approval.
Test: run the MCP catalog checks on every connected server, and rerun them on a schedule to catch drift.
Insufficient logging and human oversight
In practice: nobody can say which person an action was for, and the risky ones ran without anyone looking.
Control: approvals bound to the run that raised them, with separation of duties, and a hash-chained audit log with an offline verifier.
Test: pick a risky action from last week and reconstruct who asked, who approved and what ran. If you cannot, the log is not enough.
Cascading failures
In practice: one bad output feeds the next agent, and a small error becomes a large one across a pipeline.
Control: behaviour baselines with alerts for denial bursts and volume spikes, and a kill switch that stops an agent quickly.
Test: trigger a burst of denied calls in a staging agent and confirm the alert fires and the kill switch works.
Unexpected code execution
In practice: the agent writes and runs code, or passes model output into a shell, a query or a template.
Control: a policy that treats code-running tools as high impact, requires approval, and checks a signed one-use receipt at your executor before anything runs.
Test: send injected payloads through tool parameters and confirm the executor rejects calls without a valid receipt.
Rogue agents
In practice: an agent nobody remembers keeps running with live credentials, or one behaves outside its purpose.
Control: discovery across your platforms to find agents, expiry on credentials, new-tool and off-hours alerts, and a kill switch.
Test: compare the discovered inventory with your list of approved agents. Every difference needs an owner.
Testing as a routine
Run the red-team set before each release and on a schedule afterwards. Findings can go out as SARIF to your code scanning, through a GitHub Action, or as Jira tickets, so they sit next to other defects. Keep the evidence for the controls that pass as well as the findings that fail, because you will be asked for both.
How to run this as a quarterly exercise
A map only helps if someone works through it on a calendar. Here is a routine that fits in a few days.
- Scope the agents. List the agents in use, including ones found by discovery that nobody listed. Name an owner for each, and mark which ones can reach customer data, send messages or run code. Start with those.
- Pick the themes. You do not need all ten every time. Choose the themes that match what the scoped agents can do, and rotate the rest in over the following quarters so nothing goes untested for long.
- Run the red-team plugins and MCP catalog checks. Use the plugins and strategies named under each theme against the scoped agents, and run the MCP catalog checks on every connected server so drift since the last approval shows up.
- Review approvals and receipts. Sample the risky actions from the quarter. For each one, confirm who asked, who approved, and that the executor checked a valid receipt. Gaps here are findings, even if no attack ran.
- File findings. Send them to Jira or GitHub, or as SARIF to code scanning, so they land in the queue the owning team already reads. Each one needs an owner and a date.
- Retest. When a fix ships, run the same test again. A finding is closed when the test that found it now fails, not when the ticket is closed.
- Keep the evidence pack. Store the plugin results, the approval samples, the fixed and retested findings and the inventory comparison together. The next quarter starts from this pack, and it is what you hand over when someone asks what you tested.
Where Aynigma fits
Aynigma covers this map across four products. Agent IAM handles identity, tool policies, approvals, receipts, behaviour alerts and the MCP gateway. AI Protect scans prompts, responses, tool calls, tool results, retrieval and documents. Assess runs 63 attack plugins in 9 categories, with crescendo, TAP and memory-poison strategies, plus MCP catalog checks. Prove maps results to readiness packs, including OWASP Agentic Top 10 2026, as a readiness aid and not a certification. See AI red teaming, Agent IAM and compliance monitoring.