Notifications
Clear all
Topic starter
15/08/2026 6:12 pm
TL;DR: AI risk repositories centralise AI threats, tracking, and mitigation across the enterprise, and Obsidian Security argues they are becoming necessary as organisations face model drift, data poisoning, adversarial attacks, and AI governance requirements from the EU AI Act, NIST AI RMF, and ISO 42001. The real shift is that AI risk management now needs structured inventory, accountability, and continuous monitoring, not ad hoc spreadsheet control.
NHIMG editorial — based on content published by Obsidian Security: Inside the AI Risk Repository, Mapping the Threat Landscape
By the numbers:
- 17 minutes, redentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
Q: Why do AI systems create identity risk as well as model risk?
A: Because AI systems rarely act alone.
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.
Practitioner guidance
- 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.
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.
👉 Read Obsidian Security's analysis of the AI risk repository and enterprise AI threat mapping →
AI risk repositories: are your governance controls keeping up?
Explore further
15/08/2026 6:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI risk repositories expose the governance gap in enterprise AI
