A structured record of AI agents, their exposures, controls, and residual risk. In practice, it should be built from stable governance surfaces such as identity, data, tool, and model, so that changing runtime behaviour does not force a full rewrite every time execution changes.
Expanded Definition
An AI agent risk register is a living governance record that tracks each agent’s identity, privileges, data exposure, tools, model dependencies, and residual risk. It is more specific than a generic application inventory because it must capture autonomous execution paths, not just static system ownership.
For NHI security teams, the register becomes the control plane for understanding where an agent can act, what it can reach, and what evidence exists when it does. That matters because agent behaviour is often dynamic, while the governance record must remain stable enough to support review, audit, and change management. The structure should reflect core surfaces such as identity, data, tool, and model, which aligns well with the risk framing in the NIST AI Risk Management Framework and the task- and tool-oriented threat patterns discussed in OWASP Top 10 for Agentic Applications 2026.
Definitions vary across vendors on whether the register includes only production agents or also prototypes, copilots, and delegated workflows, but no single standard governs this yet. The most common misapplication is treating the register as a one-time procurement list, which occurs when teams fail to update it after privilege changes, tool additions, or prompt and policy revisions.
Examples and Use Cases
Implementing an AI agent risk register rigorously often introduces reporting overhead, requiring organisations to weigh faster deployment against stronger traceability and approval discipline.
- A support agent that can search customer records, open tickets, and send email is logged with its service identity, allowed tools, data classes, and escalation thresholds.
- An internal coding agent is recorded separately for development and production because its repository access, deployment rights, and secrets exposure differ across environments.
- A finance workflow agent that drafts payment instructions is registered with explicit approval checkpoints and a residual risk note if human review is bypassed.
- An agent connected through MCP is tracked with the upstream tool providers it can invoke, so security reviewers can see where external actions originate.
- A cloud operations agent exposed to secret-bearing APIs is mapped to the credential paths it can use, echoing breach patterns seen in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research and the operational failures discussed in Moltbook AI agent keys breach.
These use cases show why the register should tie each agent to observable control evidence, not just a name or owner. It is most useful when a team needs to answer what the agent can do, what changed, and who accepted the risk.
Why It Matters in NHI Security
AI agents often operate with non-human identities, delegated tokens, and broad tool access, which makes their risk profile a direct NHI issue rather than a generic AI policy issue. When the register is incomplete, teams lose visibility into which agents can reach secrets, manipulate systems, or exfiltrate data. That gap weakens incident response, access review, and segregation of duties.
N H I Management Group’s research on AI agents shows how quickly governance can fall behind runtime reality: 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation, and 80% report agents have already acted beyond intended scope. That is exactly why the register must connect to evidence from live controls, not static documentation. The same governance logic is reinforced by the OWASP NHI Top 10 and the NIST Cybersecurity Framework 2.0, both of which emphasise risk identification, continuous monitoring, and access control discipline.
Organisations typically encounter the need for a reliable risk register only after an agent overreaches, leaks data, or triggers an audit finding, at which point the register becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and governance gaps tied to non-human identities. |
| OWASP Agentic AI Top 10 | A1 | Frames agent autonomy and tool misuse as primary risk drivers. |
| NIST AI RMF | Defines risk governance practices for AI systems across lifecycle phases. | |
| NIST CSF 2.0 | GV.RM-01 | Requires risk management processes that support enterprise governance. |
| NIST Zero Trust (SP 800-207) | AC-2 | Zero trust relies on explicit identities, permissions, and continuous verification. |
Register every agent credential, secret path, and owner so access drift can be reviewed continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
