Topic starter
16/01/2026 11:03 am
TL;DR: AI adoption is creating blind spots because security teams cannot consistently see who is using AI, what they access, or how agents behave, according to Permiso Security. The governance problem is identity-based, not tool-based, and runtime visibility now matters more than static inventory.
Editorial analysis by NHI Mgmt Group, based on content published by Permiso Security: “8 Critical AI Security Challenges and How Permiso Solves Them”.
By the numbers:
- 80% of actual AI activity is invisible to traditional tools that only track licensing and static configurations, according to Permiso Security.
- AI agents can operate with up to 90% unused permissions, according to Permiso Security.
- Fewer than 40% of organisations currently govern AI agents as they proliferate across teams and business units, according to Permiso Security.
Key questions
Q: What breaks when AI access is managed like normal application access?
A: Normal application access assumes stable ownership, predictable usage, and clear review cycles.
Q: Why do AI agents increase the risk of overpermissioning?
A: AI agents increase that risk because teams often expand scopes to unblock early use cases, then keep those permissions because the original need is hard to prove or remove.
Q: How can security teams tell whether AI lifecycle controls are working?
A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current.
Practitioner guidance
- Define AI actors by identity type Map employees, builders, AI agents, and service accounts separately so policy can follow the actual actor rather than the AI product name.
- Measure runtime AI activity Correlate federated logins, API calls, and session data to see which AI services are being used and what they are accessing in production.
- Rightsize agent permissions against task scope Review each AI agent’s connected systems and remove unused access that is not required for its current operating task.
Bottom line: AI security failures are increasingly identity failures, because access paths and runtime behaviour matter more than tool labels.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
11/10/2026 3:31 am
AI security is now an identity governance discipline, not a tool category. The article is right to collapse AI monitoring, agent control, and user activity into one identity problem. That matters because security teams do not lose control only when AI is malicious, but when access is granted through the wrong account model and then becomes untraceable at runtime. Practitioners should treat AI adoption as an expansion of IAM scope, not a standalone exception.
A few things that frame the scale:
- 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to the State of Secrets Sprawl 2026.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should organisations do when AI-generated code touches credentials or service accounts?
A: Apply stricter review and approval rules whenever generated code creates, stores, rotates, or calls machine credentials. Those paths can expand NHI exposure quickly, so the code should be treated like privileged automation. Require explicit ownership, logging, and pre-merge checks for credential handling.
👉 Read our full editorial: AI security is identity security, and blind spots are growing