TL;DR: AI copilots and agents embedded in enterprise workflows create governance gaps when data controls are treated as enough, according to Securiti’s analysis of safe AI agent scaling. The core issue is that agent behaviour, delegated access, and mistake containment need identity-aware controls, not just data protection.
NHIMG editorial — based on content published by Securiti: Agent Commander and the scaling of safe AI agents
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Q: What breaks when AI privacy controls are used as a substitute for access governance?
A: The control gap is accountability.
Practitioner guidance
- Define agent identities and ownership Assign each production AI agent a named owner, a documented purpose, and a distinct identity that can be reviewed, rotated, and revoked independently of the application that uses it.
- Scope tool access to tasks Limit each agent to the smallest set of tools and actions needed for the specific workflow, and separate read, write, and execute permissions wherever possible.
- Add runtime policy checks Enforce policy at each action boundary so the agent cannot chain unapproved calls, access new systems, or continue after a policy violation without intervention.
What's in the full article
Securiti's full blog covers the operational detail this post intentionally leaves for the source:
- Product and workflow specifics for Agent Commander and how it fits into Securiti's broader AI governance stack
- Implementation detail on how the platform enforces controls across AI agent actions, data access, and response handling
- Examples of how enterprises can operationalise safe AI agent scaling across data, access, and governance workflows
- The source article's framing of the acquisition context and why the combined offering is being positioned now
👉 Read Securiti's analysis of safe AI agent scaling with Agent Commander →
AI agent governance: what IAM and security teams are missing?
Explore further
AI agent governance is becoming an identity problem before it is a data problem. Agents only become operationally risky when they can act, call tools, and persist across workflows with authority that outlives the original intent. That is why IAM, PAM, and NHI teams need to govern delegated execution, not just data exposure. The practitioner conclusion is clear: if the identity model is weak, the rest of the AI control stack will be brittle.
A question worth separating out:
Q: How do IAM and PAM teams split responsibility for AI agent access?
A: IAM should define what the agent can reach, while PAM should control when elevated access is available and how it is revoked. For AI agents, those responsibilities must be coordinated because programmatic identities do not fit a human session model. If scope and elevation are managed separately without a shared lifecycle view, privilege can persist longer than anyone expects.
👉 Read our full editorial: AI agent governance needs identity controls beyond data access