Notifications
Clear all
Topic starter
20/08/2026 5:56 pm
TL;DR: Enterprises adopting AI agents across multiple platforms inherit a governance gap that no single vendor console can close, according to TruFoundry’s analysis of cross-platform agent control. The core problem is fragmented identity, policy, discovery, and lifecycle control across separate runtimes, plus a hidden credential tax that multiplies OAuth prompts, token sprawl, and revocation work.
NHIMG editorial — based on content published by TruFoundry: Governing AI Agents Across Multiple Platforms
By the numbers:
- While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing 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 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 make non-human identity governance harder?
A: AI agents make governance harder because they can request tools, act autonomously, and change behaviour across sessions while still relying on machine credentials.
Q: What breaks when agent discovery is limited to one platform?
A: Shadow agents, vendor-supplied agents, and remote agents stay outside the control set even when they reach the same sensitive data.
Practitioner guidance
- Map every agent source into one inventory Include platform-built agents, third-party agents, shadow agents, and remote agents from external runtimes.
- Centralise policy at the shared execution layer Enforce allowlists, rate limits, PII filters, and approval gates where model and tool traffic converges.
- Separate agent identity from platform identity Require a verifiable principal for each governed agent and avoid treating platform tenancy as proof of identity.
What's in the full article
TruFoundry's full article covers the operational detail this post intentionally leaves for the source:
- Layer-by-layer product architecture for the agent gateway, harness, and sandboxed execution environment.
- The operational primitives behind the unified registry, including owner, environment, model, tool permissions, and activity metadata.
- Step-by-step containment examples for pausing, blocking, or revoking governed agent traffic across routed paths.
- The article's own performance and deployment claims, including latency, uptime, and infrastructure placement options.
👉 Read TruFoundry's analysis of governing AI agents across multiple platforms →
AI agent governance across platforms: what IAM teams are missing?
Explore further
20/08/2026 6:36 pm
Cross-platform AI agent governance is now an identity problem, not a tooling problem: once agents live in multiple runtimes, the enterprise no longer has one principal, one policy boundary, or one audit path. That fractures IAM, IGA, and incident response at the same time. The practitioner conclusion is straightforward: governance must be designed around the shared execution layer, not the product boundary.
A few things that frame the scale:
- 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, according to AI Agents: The New Attack Surface report.
- The same report says 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented policies to do so.
A question worth separating out:
Q: How do organisations reduce risk when third-party agents require repeated sign-in?
A: They should treat repeated sign-in as a signal to tighten lifecycle control, not as a user inconvenience to accept. Every per-user, per-tool OAuth flow expands token sprawl and revocation complexity. Organisations should centralise authorization visibility, shorten the time to revocation, and ensure that every connected token has a clear owner and offboarding path.
👉 Read our full editorial: Cross-platform AI agent governance exposes a shared execution gap
