---
title: "Agentic AI Security Risks: A Copyable Risk Register With Scoring"
description: "Twelve agentic AI security risks in a register you can copy, with exposure and impact scoring, proof to attach and a case for scoring paths instead of categories."
author: "Renn Calloway"
category: "Defensive Architecture & Security Controls"
date: 2026-11-02T10:25:04.754Z
canonical: "https://agenticcyber.co/blog/agentic-ai-security-risks-risk-register"
---

# Agentic AI Security Risks: A Copyable Risk Register With Scoring

![cctv surveillance camera, cctv, security](https://cdn.pixabay.com/photo/2022/06/17/09/50/cctv-surveillance-camera-7267551_1280.jpg?w=1200&q=75)

> Twelve agentic AI security risks in a register you can copy, with exposure and impact scoring, proof to attach and a case for scoring paths instead of categories.

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](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)). OWASP's page is a download, so the entry names here come from a secondary summary ([Cycode](https://cycode.com/blog/owasp-top-10-agentic-applications/)), 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

  ![](https://images.unsplash.com/photo-1717656695899-21359e624878?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwxfHxIb3clMjB0aGUlMjBtYXJrcyUyMHdvcmt8ZW58MXx8fHwxNzkxOTM1NTE1fDA&ixlib=rb-4.1.0&q=75&w=960&auto=format)
  Photo by [Brett Jordan](https://unsplash.com/@brett_jordan) on [Unsplash](https://unsplash.com)

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

#RiskTypical pathControl that cuts it mostProof to file

1Goal hijack (ASI01)Hostile text in mail or a page redirects the agent's taskShrink what it can reach; gate outbound actionsMap of inputs; canary test outcome
2Tool misuse (ASI02)A permitted tool is chained or looped into harmNarrow tool list; validate each parameterWhich agent may call which tool
3Abuse of identity or privilege (ASI03)A borrowed or oversized credential does what its owner never intendedOne identity per agent; tokens that expireIdentity inventory with lifetimes
4Compromised dependencies (ASI04)An imported plugin, server or prompt turns out to be hostileVet, then freeze versionsApproved list with version numbers
5Unplanned code execution (ASI05)Generated code runs on a host holding secretsSandbox containing no credentialsA recorded escape attempt
6Poisoned memory or context (ASI06)Bad content stored today steers decisions next weekSeparate stores; tag where content came fromNote on how memory is built
7Unsafe agent-to-agent messaging (ASI07)A forged or altered message travels along a delegation chainAuthenticated channels; scopes that narrow at each hopRegister of peers
8Cascading failure (ASI08)One fault spreads through linked agentsRate caps; a stop that has been triedDate and time of the last drill
9Human trust exploitation (ASI09)A reviewer approves what the agent described, not what it will doApproval text written by the platformCaptured prompts next to the logs
10Rogue agents (ASI10)An agent nobody sanctioned runs with real accessDiscovery, then revocationLatest discovery report
11Endpoint credential theftMalware lifts tokens and configs from a laptopOS credential store; brief token lifeReview of where secrets live
12Tamperable recordsThe agent edits its own traceLogging done outside the agentLogging 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](https://www.gendigital.com/blog/insights/research/infostealers-your-ai-agent)). 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](https://arxiv.org/abs/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](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)).

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

  ![](https://images.unsplash.com/photo-1717505694141-ada870f2bb95?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwyfHxIb3clMjB0aGUlMjBtYXJrcyUyMHdvcmt8ZW58MXx8fHwxNzkxOTM1NTE1fDA&ixlib=rb-4.1.0&q=75&w=960&auto=format)
  Photo by [Brett Jordan](https://unsplash.com/@brett_jordan) on [Unsplash](https://unsplash.com)

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

- Start with five agents: those closest to sensitive data or with the most side effects.

- Fill it in a two-hour session with the agent owner and a security engineer.

- Attach proof, not opinions, and mark a row stale if its proof is older than a quarter.

- Re-score when tools, data sources or users change, and when a canary test contradicts a low score.

- 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](/agentic-ai-risk-management-program-in-six-steps), the [OWASP practical guide](/owasp-top-10-agentic-applications-practical-guide) and the [framework map](/owasp-agentic-top-10-mitre-atlas-nist-mapping). Logging detail is in [audit log evidence requirements](/agentic-ai-audit-log-evidence-requirements), and the [infostealer article](/infostealers-target-ai-agent-tokens-and-mcp-configs) 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

## FAQ

### One register or one per agent?

One register with rows per risk per agent, or per path. Group agents that share the same design.

### Who owns the register?

Security facilitates it, and each agent owner owns the rows for that agent.

### How is this different from a generic AI risk register?

It names tools, credentials and input sources, so every row has a control and a proof item that someone can check.

### Where do the risk names come from?

Ten follow the OWASP Top 10 for Agentic Applications, taken here from secondary summaries. Check the official file. Two rows are our additions.


---
Source: https://agenticcyber.co/blog/agentic-ai-security-risks-risk-register