Notifications
Clear all
Topic starter
22/08/2026 12:01 pm
TL;DR: AI agents in production are already accessing databases, calling APIs, and moving regulated data across documents and collaboration tools, according to Trust3, but the governance stack was built for deterministic software and human users. The core failure is structural: existing IAM can authorize access, yet it cannot govern what an agent does with data after access, especially when tool chaining and runtime reasoning expand the blast radius.
NHIMG editorial — based on content published by Trust3: AI agents are already running in production and breaking existing governance models
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams govern AI agents that move across multiple trust boundaries?
A: They need runtime controls that follow the agent rather than staying attached to one platform.
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 agents inherit human IAM controls?
A: Human IAM controls break because they assume a person makes a request, waits, and can later be reviewed or deprovisioned.
Practitioner guidance
- Map agent-to-data-to-destination chains Inventory every production agent, the tools it can call, the data classes it can touch, and every place its outputs can land.
- Separate source access from output control Define policy for what an agent may do with data after it reads it.
- Review MCP connections as compound risk Assess each Model Context Protocol connection as a multiplier, not a standalone integration.
What's in the full article
Trust3's full article covers the operational detail this post intentionally leaves for the source:
- The full breakdown of the Discover, Observe, Secure framework and how the series is structured across four parts.
- The article’s examples of AI agents depositing regulated data into documents, Slack, emails, and external APIs.
- The detailed comparison of traditional IAM assumptions versus agent behaviour across identity, permission, and data movement.
- The closing questions Trust3 suggests CISOs and CIOs should ask as they inventory agent activity.
👉 Read Trust3's analysis of why AI agent governance breaks existing security models →
AI agent data movement: what identity teams are missing?
Explore further
22/08/2026 12:02 pm
AI agent governance is now a non-human identity problem first and an AI problem second. The article shows that agents already behave like production identities because they authenticate, access systems, and move data across tools. That means the governance gap sits in identity lifecycle, entitlement scope, and destination control, not only in model safety. Practitioners should stop treating agents as experimental software and start treating them as governed identities.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Who is accountable when an AI agent accesses regulated data improperly?
A: Accountability sits with the teams that govern the agent's identity, the data classification, and the policy that allowed the access path. If those controls are disconnected, no single owner can explain why the access existed or why it was not removed sooner. Shared context is what makes accountability traceable.
👉 Read our full editorial: AI agent governance breaks when data moves after access
