Notifications
Clear all
Topic starter
19/08/2026 3:27 pm
TL;DR: AI systems increasingly inherit permissions through applications, APIs, service accounts, machine identities, and user roles, making access governance a central AI risk issue according to BigID. The practical shift is from knowing where AI exists to understanding what it can do, what data it can reach, and who owns its permissions.
NHIMG editorial — based on content published by BigID: AI Permissions Explained
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- When AWS credentials 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 organisations govern AI permissions in existing enterprise systems?
A: Start by tracing each AI workload to the identity that actually grants access, whether that is an application, API, service account, machine identity, or delegated user role.
Q: Why do AI permissions create more risk when they inherit access from other systems?
A: Inherited access is risky because the AI layer often borrows trust without inheriting the original governance discipline.
Q: What do security teams get wrong about AI access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it.
Practitioner guidance
- Inventory AI inherited access paths Build a register that links each AI system to the application, API, service account, machine identity, or user role that grants its effective access.
- Tie AI permissions to data sensitivity Classify permissions by the sensitivity of the records, documents, and systems they can reach.
- Recertify AI access on lifecycle changes Require access review when an AI use case changes, when ownership changes, and when the underlying workflow is retired.
What's in the full article
BigID's full article covers the operational detail this post intentionally leaves for the source:
- A stepwise breakdown of how AI permissions are inherited through applications, APIs, service accounts, machine identities, and user roles.
- Operational examples of excessive AI permissions and how they translate into business risk across different access types.
- The specific questions BigID recommends teams ask when tracing ownership, access paths, and sensitive-data exposure.
- How BigID positions AI Access Governance in practice for organisations trying to inventory and control AI permissions.
👉 Read BigID's analysis of AI permissions and access governance →
AI permissions governance: what IAM and security teams need to know?
Explore further
19/08/2026 4:11 pm
AI permissions have become an identity governance problem, not just an AI governance problem. The article shows that AI systems usually do not invent access on their own. They inherit it through applications, APIs, service accounts, machine identities, and user roles, which means traditional IAM controls now define the AI blast radius. Practitioners should treat AI permissions as a governed identity layer, not as an app feature.
A question worth separating out:
Q: How can teams tell if AI permissions are drifting out of control?
A: Look for access that cannot be tied to a current business use case, permissions that exceed the data sensitivity of the task, and inherited rights that were never re-reviewed after rollout. If ownership is unclear and revocation is slow, the AI permission model is already drifting beyond its intended boundary.
👉 Read our full editorial: AI permissions governance is becoming a core security control
