Agentic AI Security Risks: A Copyable Risk Register With Scoring

Saying that agents are risky is not a finding. A finding names one agent, one path, a worst case, an owner and a date. A register is the working document that produces such findings, yet many teams keep none for agents, or borrow a generic AI list that never mentions a credential.

This page supplies a twelve-row register for agentic AI security risks, a scoring method, the proof to attach and a worked case. Ten labels follow the OWASP Top 10 for Agentic Applications, which appeared on 9 December 2025 (OWASP). OWASP's page is a download, so the entry names here come from a secondary summary (Cycode), and the names agree across the summaries we read. Compare them with the official file. Scores and controls are our judgement, the scale is our convention, and nothing here is an audit.

How the marks work

Mark one agent at a time, not the company. Give two numbers between 1 and 5. Exposure is plausibility: consider what the agent ingests and who may put words in front of it. Impact is the worst realistic result, set by the tools and data the agent can touch. Multiply the two. At 16 or above, name an owner and a date. From 9 to 15, write a plan. Below 9, accept the risk in writing. Tune these cut-offs to your appetite.

Twelve rows to copy

#	Risk	Typical path	Control that cuts it most	Proof to file
1	Goal hijack (ASI01)	Hostile text in mail or a page redirects the agent's task	Shrink what it can reach; gate outbound actions	Map of inputs; canary test outcome
2	Tool misuse (ASI02)	A permitted tool is chained or looped into harm	Narrow tool list; validate each parameter	Which agent may call which tool
3	Abuse of identity or privilege (ASI03)	A borrowed or oversized credential does what its owner never intended	One identity per agent; tokens that expire	Identity inventory with lifetimes
4	Compromised dependencies (ASI04)	An imported plugin, server or prompt turns out to be hostile	Vet, then freeze versions	Approved list with version numbers
5	Unplanned code execution (ASI05)	Generated code runs on a host holding secrets	Sandbox containing no credentials	A recorded escape attempt
6	Poisoned memory or context (ASI06)	Bad content stored today steers decisions next week	Separate stores; tag where content came from	Note on how memory is built
7	Unsafe agent-to-agent messaging (ASI07)	A forged or altered message travels along a delegation chain	Authenticated channels; scopes that narrow at each hop	Register of peers
8	Cascading failure (ASI08)	One fault spreads through linked agents	Rate caps; a stop that has been tried	Date and time of the last drill
9	Human trust exploitation (ASI09)	A reviewer approves what the agent described, not what it will do	Approval text written by the platform	Captured prompts next to the logs
10	Rogue agents (ASI10)	An agent nobody sanctioned runs with real access	Discovery, then revocation	Latest discovery report
11	Endpoint credential theft	Malware lifts tokens and configs from a laptop	OS credential store; brief token life	Review of where secrets live
12	Tamperable records	The agent edits its own trace	Logging done outside the agent	Logging architecture sketch

Why we added two rows

On 8 September 2026 Gen Digital's threat researchers wrote that infostealer collection rules now list files from AI coding tools, including access tokens, MCP configuration credentials and stored prompt histories. The report is careful to say it counts detections and not successful infections, and that it describes no new vulnerability in the agents (Gen Digital). That is one vendor's telemetry, and it changes how row 3 should be scored for any agent that stores tokens on a laptop.

A September 2026 preprint from Qin and co-authors found that, apart from one, each local agent harness tested let an agent erase its own execution trace on request (arXiv:2609.30266). It is a single preprint. If it holds for your tooling, a row that relies on agent-written logs deserves a higher impact score.

Example: marking an email triage agent

Picture an assistant that sorts incoming mail, writes draft replies and may send on the user's behalf. Row 1: any sender can reach it, so exposure is 5, and sending with attachments makes impact 4, for a product of 20. That demands an owner and a date, and the control is an approval screen showing the true recipient and files before anything leaves. Row 3: a token in a config file gives exposure 3 and impact 4, a product of 12, which earns a plan to adopt expiring delegated tokens this quarter. Row 12 gets exposure 2 and impact 3, giving 6, which can be accepted and reviewed next quarter.

Score paths, not categories

The OWASP categories overlap, and a register built row by row on them can double-count. A hijacked goal, an abused tool and a stolen identity are often the same incident seen from three angles. The NCSC makes the underlying point: because prompt injection cannot be fully mitigated, systems should be designed to limit impact, with deterministic safeguards on what an agent can do (NCSC blog).

That leads to a recommendation. Keep the twelve rows as tags, and score at the level of a path: one input source reaching one action through one identity. An email triage agent has a few such paths, and each gets its own score and its own control. A path is concrete enough that an owner can say whether a control exists, which a category never allows.

The advice costs more rows. It is the wrong choice for a small organisation with a handful of simple agents, where a category-level register is faster and good enough. Switch to paths when agents multiply, when one agent holds several tools, or when an auditor asks you to show a specific route.

Common scoring slips

Four mistakes show up repeatedly. Teams rate exposure by the agent's popularity and not by who can write to its inputs. They rate impact by the average action and not by the worst tool it holds. They copy last quarter's scores after the agent gained a connector. And they let the agent's builder score alone, which tends to flatter the design. Pair the owner with a security engineer, score from the permission table and the input map, and compare the number with any canary result. If a canary succeeds against a row you scored low, the score was wrong.

Also watch how scores cluster. If every row lands between 10 and 15, the scale has stopped discriminating, and it is time to separate the paths that really differ in reach.

Keeping it alive

1. Start with five agents: those closest to sensitive data or with the most side effects.
2. Fill it in a two-hour session with the agent owner and a security engineer.
3. Attach proof, not opinions, and mark a row stale if its proof is older than a quarter.
4. Re-score when tools, data sources or users change, and when a canary test contradicts a low score.
5. Report the top five risks to leadership each quarter, and turn the top three rows into a roadmap with a control, an owner, a date and the proof you will attach.

For the surrounding programme, read the six-step risk programme, the OWASP practical guide and the framework map. Logging detail is in audit log evidence requirements, and the infostealer article covers row 11 in depth.

What stays uncertain

• No standard scale for agent risk exists, so ours is a convention.
• The OWASP entry names come from secondary summaries here.
• Data on real attack likelihood is thin, so exposure marks lean on judgement.

Register FAQs