TL;DR: AI agents are already touching sensitive data, APIs, and cloud services, and Token Security argues that least privilege, simulation, and continuous governance are needed to keep that access within scope. The real issue is that agent behaviour can change faster than human-paced access review cycles can keep up.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams right-size permissions for AI agents?
A: Start by defining the agent’s intended task, the systems it must touch, and the exact actions it is allowed to perform.
Q: Why do AI agents create more privilege risk than traditional service accounts?
A: AI agents can adapt their behaviour during execution, which means their access needs may shift faster than static entitlement models can handle.
Q: How do organisations know whether AI agent access is still appropriate?
A: Compare the agent’s observed actions, data access, and system interactions against the original intent description.
Practitioner guidance
- Build agent-specific permission baselines Document the intended purpose, target systems, and allowed operations for every AI agent, then translate that description into the narrowest workable permissions.
- Simulate agent behaviour before production Run planned agent workflows against proposed IAM policies so you can identify over-privilege, missing controls, and unintended cross-environment access before deployment.
- Monitor for privilege creep continuously Compare actual agent activity to approved intent on an ongoing basis, then remove permissions that are no longer justified by observed use.
What's in the full announcement
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- The interactive permission-sizing workflow that lets teams test agent scope before deployment
- Example inputs for cloud and SaaS agent use cases, including AWS, Azure, Google Cloud, and business applications
- The policy output format for translating intended actions into IAM policies and roles
- The platform-level visibility and retirement functions for agents already operating in production
👉 Read Token Security's blog on right-sizing permissions for AI agents →
AI agent permissions and least privilege: are controls keeping up?
Explore further
AI agent privilege management is now an identity governance problem, not a prompt-safety problem. The article is correct to focus on permissions because the security risk lives in what the agent can access and change across systems, not only in how it is prompted. When an AI agent can touch cloud services, internal APIs, and sensitive data, the governing question becomes entitlement scope and accountability. Practitioners should treat AI agent identity as part of the access model, not a sidecar to application security.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own governance when AI agents are granted enterprise access?
A: Ownership should sit with the team responsible for the agent’s business purpose, working alongside IAM or NHI governance teams for policy, review, and offboarding. Without clear ownership, agent permissions linger after the use case changes. That creates unmanaged non-human access with no accountable steward.
👉 Read our full editorial: AI agent privilege governance is moving from theory to enforcement