Notifications
Clear all
Topic starter
20/08/2026 5:31 pm
TL;DR: AI systems now access sensitive data continuously across copilots, agents, applications, APIs, and machine identities, and BigID argues that traditional identity governance is incomplete without data context, because permissions alone do not show what sensitive information those actors can actually reach. The practical break point is that AI identity risk and data risk are inseparable, so least privilege and exposure control must be evaluated together.
NHIMG editorial — based on content published by BigID: AI Identity Governance: Key Takeaways and operational guidance
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern sensitive data used by AI systems?
A: Security teams should treat AI as a data consumer that needs policy boundaries, not just authentication.
Q: Why do AI systems increase identity risk even when they improve security operations?
A: AI can help defenders, but it also helps attackers scale phishing, impersonation, and credential abuse.
Q: What do teams get wrong about machine identity security in AI programmes?
A: They often assume confidence means coverage.
Practitioner guidance
- Map AI access to sensitive data classes Identify which copilots, agents, applications, APIs, and service accounts can reach regulated or confidential data, then document the specific data classes each path can expose.
- Review machine identities behind AI workflows Treat the service accounts and API credentials supporting AI workflows as governance objects, not implementation details.
- Bind least privilege to data sensitivity Do not approve AI access based on application role alone.
What's in the full article
BigID's full article covers the operational detail this post intentionally leaves for the source:
- Its framework for correlating AI systems, permissions, activity, and sensitive data exposure across cloud and SaaS environments.
- Its operational breakdown of how to identify excessive AI access and prioritise the riskiest machine identities.
- Its explanation of how data classification and identity governance can be combined to reduce exposure in AI workflows.
- Its use cases for governing copilots, agents, applications, and service accounts against specific data sensitivity scenarios.
👉 Read BigID's analysis of AI identity governance and sensitive data risk →
AI identity governance and data context: are IAM controls keeping up?
Explore further
20/08/2026 6:18 pm
AI identity governance is really data governance with an identity layer attached. The article is right that permissions alone are not enough, because exposure depends on what data the AI can actually reach and how it can reuse that data across workflows. For IAM and IGA teams, the useful shift is to stop treating access review as a complete answer and to make data sensitivity part of the access decision.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do organisations know if AI identity governance is working?
A: They should be able to answer three questions quickly: which agents exist, which credentials each one uses, and who is accountable for each identity’s lifecycle. If any of those answers require manual searching across teams, the governance model is still incomplete and the environment remains difficult to audit.
👉 Read our full editorial: AI identity governance is now a data context problem
