AI risk repositories expose the governance gap in enterprise AI

At a glance

What this is: This is an analysis of why AI risk repositories are becoming a core control for managing AI threats, compliance, and operational accountability at enterprise scale.

Why it matters: It matters to IAM and security practitioners because AI systems now create governance gaps across access, data exposure, and accountability that traditional security frameworks do not cover cleanly.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 17 minutes

👉 Read Obsidian Security's analysis of the AI risk repository and enterprise AI threat mapping

Context

AI risk repositories exist because AI systems now generate governance, compliance, and security problems that are too broad to manage in isolated spreadsheets or point controls. The primary gap is visibility: organisations may know they are deploying AI, but not which risks each model, workflow, or integrated agent introduces across data, privilege, and accountability.

For IAM and identity leaders, the important question is not whether AI exists in the business, but how its access, data use, and decision paths are being catalogued and governed. That makes the repository more than a compliance record, because it becomes the operational bridge between AI governance, access control, and auditability.

Key questions

Q: How should security teams build an AI risk repository that actually changes behaviour?

A: Start with a taxonomy that separates model, data, access, and integration risks, then assign ownership for each category. Link repository entries to approval, exception, and remediation workflows so the record drives decisions, not just documentation. If a repository does not affect deployment or access, it is not governing risk effectively.

Q: Why do AI systems create identity risk as well as model risk?

A: Because AI systems rarely act alone. They depend on service accounts, API tokens, cloud permissions, and data access paths, which means a model can behave safely while its identity layer is over-privileged. Treating AI risk as only a model problem misses the access surface where misuse and lateral movement usually begin.

Q: What signals show that an AI risk repository is not working?

A: The clearest signals are duplicated risk entries, missing owners, stale assessments, and no linkage to access controls or remediation. If teams cannot answer which AI systems touch sensitive data or which permissions they hold, the repository is not providing operational visibility.

Q: Who is accountable when a third party introduces compliance or AI governance risk?

A: The organisation that engaged the third party remains accountable for many of the resulting obligations, even when the vendor performed the activity. That is why contracts, oversight, and evidence collection must be built into vendor governance from the start, not added after an incident.

Technical breakdown

Why AI risk repositories need a defined risk taxonomy

An AI risk repository is only useful if it turns scattered concerns into a consistent taxonomy. That means separating model risks such as drift and bias from security risks such as prompt injection, data poisoning, credential exposure, and unauthorised tool use. Without that structure, teams cannot compare risk across systems or assign ownership cleanly. The repository becomes the control plane for documenting what the AI system can touch, what can go wrong, and which mitigations apply. Practical implication: define risk categories up front and map them to business owners, security owners, and compliance owners.

Practical implication: define risk categories up front and map them to business owners, security owners, and compliance owners.

How AI risk repositories support AI RMF and EU AI Act governance

The NIST AI Risk Management Framework expects organisations to identify, measure, manage, and govern AI risks over time, while the EU AI Act requires traceable evidence for high-risk systems. A repository supports both by preserving an auditable record of risk identification, assessment, mitigation, and review. That record matters because AI risk is not static. Models change, prompts change, data changes, and integrations change. If the repository does not track those changes, the organisation loses its governance memory. Practical implication: treat the repository as living evidence, not a one-time compliance file.

Practical implication: treat the repository as living evidence, not a one-time compliance file.

Why AI repositories must connect security controls to identity and access

AI risk does not stay inside the model. It reaches data stores, APIs, software tools, and human workflows, which is why identity governance belongs in the repository design. If an AI system can access sensitive data or invoke privileged actions, then its permissions, service accounts, tokens, and delegation paths are part of the risk surface. This is where AI governance and identity governance converge. For NHIs, the repository should record which agents, workloads, or integrations hold credentials and what constraints limit them. Practical implication: inventory AI-connected identities alongside the models they enable.

Practical implication: inventory AI-connected identities alongside the models they enable.

NHI Mgmt Group analysis

AI risk repositories are becoming the missing governance layer for enterprise AI. Traditional security controls can monitor systems, but they do not create a durable record of AI-specific exposure, ownership, and remediation. That gap matters when models, workflows, and agents change faster than review cycles. The organisations that treat the repository as a control plane will have better auditability and fewer blind spots.

The most important failure mode is not lack of AI policy, but lack of risk memory. If teams cannot retain a structured history of what each AI system accesses, what it can do, and what mitigations were accepted, governance becomes episodic. This is especially relevant where AI systems intersect with service accounts, tokens, and delegated access. Practitioners should assume that undocumented AI access is unmanaged AI risk.

AI governance and identity governance now overlap in practice. Once an AI system can read data, call tools, or make decisions, its permissions become part of the enterprise identity model. That means AI risk repositories should not sit only with compliance teams. They belong across IAM, security architecture, MLOps, and risk functions so that access, data handling, and accountability are governed together.

Risk repositories are only useful when they drive action, not documentation volume. A growing repository that does not change deployment decisions, access controls, or exception handling is just compliance theatre. The stronger pattern is to use the repository to trigger review, block unsupported use cases, and prioritise controls where AI systems touch sensitive data or privileged workflows. Practitioners should measure whether the repository changes behaviour.

What this signals

AI risk repositories will increasingly function as operational controls, not just governance artefacts. As AI adoption expands, the organisations that can continuously inventory model exposure, permissions, and exceptions will be better positioned to keep pace with policy obligations and internal risk tolerance. The practical test is whether the repository changes approvals, access, and monitoring in real time.

Identity teams should treat AI systems as governed access holders. Once an AI workflow can invoke tools or touch regulated data, its permissions need lifecycle control, review, and revocation paths just like any other high-risk identity. That is especially true for non-human identities that operate beyond standard human access review cycles.

AI governance debt accumulates when repository data does not feed control decisions. The more AI systems an enterprise deploys, the more important it becomes to connect evidence to enforcement. Without that linkage, the organisation gains records but not resilience, and the repository becomes a static reporting layer rather than a decision layer.

For practitioners

• Define a risk taxonomy for AI systems Separate model behaviour risks, data risks, access risks, and third-party integration risks so each can be assigned and reviewed consistently across the organisation.
• Inventory AI-connected identities and permissions Record the service accounts, API tokens, delegated permissions, and tool connections used by AI systems, then tie each entry to an owner and review cadence.
• Link repository entries to governance workflows Trigger review, approval, or remediation workflows when a new AI system touches sensitive data, privileged actions, or regulated use cases.
• Use the repository as audit evidence Preserve assessment dates, mitigations, exceptions, and revalidation history so the repository can support internal audit and regulatory scrutiny.

Key takeaways

• AI risk repositories address the governance gap created when AI systems expand faster than policy, ownership, and audit processes.
• The key value is not documentation alone, but the ability to track data access, identity exposure, and mitigation state across the AI estate.
• Practitioners should connect repository records to identity controls, approval workflows, and evidence retention before AI adoption scales further.

Key terms

• AI Risk Repository: A central record of the risks tied to AI systems, their data, access paths, and mitigations. It turns scattered concerns into structured governance evidence so security, compliance, and engineering teams can track exposure, ownership, and remediation in one place.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Risk Taxonomy: A risk taxonomy is a consistent method for grouping and scoring security findings so different teams can compare them using the same logic. In practice, it reduces ambiguity by separating people, application and infrastructure issues while keeping business impact visible.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the AI risk repository implementation stages and maturity progression used by the vendor.
• Examples of how the repository maps to regulatory obligations such as the EU AI Act, NIST AI RMF, and ISO 42001.
• Role-specific guidance for CISOs, MLOps engineers, compliance teams, and legal teams on maintaining the repository.
• Practical examples of risk categories including adversarial attacks, model drift, data poisoning, and privacy violations.

👉 The full Obsidian Security article covers implementation stages, governance roles, and regulatory alignment in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle management. It helps security and identity practitioners build the governance muscle needed for systems that access data and act independently.