Cross-platform AI agent governance exposes a shared execution gap

At a glance

What this is: This is an analysis of cross-platform AI agent governance, and the key finding is that platform-native controls stop at the application edge while the shared execution layer remains the real control point.

Why it matters: It matters because IAM, IGA, and PAM teams need one governance model for AI agents that span multiple platforms, or they will lose visibility, revocation speed, and audit consistency.

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.

👉 Read TruFoundry's analysis of governing AI agents across multiple platforms

Context

AI agent governance fails when each platform issues its own identity, policy boundary, and incident response path. In that model, the enterprise gets separate control stories for Microsoft, ServiceNow, Salesforce, and custom systems, but no shared view of what the agent is allowed to do once it crosses a platform edge.

The problem is not that AI agents are hard to observe in one product. It is that multi-platform deployment creates fragmented accountability, where discovery, authorization, audit, and containment all depend on which vendor happens to host the runtime. That is why cross-platform governance is now an IAM and NHI issue, not just an application-team issue.

TrueFoundry’s article is typical of the current market because it describes a real enterprise pattern rather than an edge case: the more platforms independently adopt agents, the faster governance becomes operationally inconsistent.

Key questions

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. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

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. That increases the number of access paths security teams must supervise. The result is a stronger need for task-scoped access, explicit ownership, and continuous monitoring of what the agent can reach.

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. That produces false confidence in governance coverage, weakens access review quality, and makes containment harder because operators do not know the full agent fleet. Discovery must follow the traffic and the source inventory, not just internal approvals.

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.

Technical breakdown

Why platform-native AI governance stops at the edge

Most platform-native controls are scoped to the vendor’s own runtime, identity store, and policy engine. That works until an agent calls a tool, API, or document store outside the host ecosystem. At that point, authorization becomes fragmented because the receiving system, the host platform, and the enterprise security team may each have a different view of identity and policy. The practical issue is not policy absence, but policy non-portability across execution surfaces.

Practical implication: treat platform-bound governance as local control, not enterprise control, whenever agents can cross systems.

What an agent gateway changes in the control plane

An agent gateway is a shared execution layer that intercepts model calls, tool calls, and runtime traces before they fan out into multiple systems. In architectural terms, it behaves like a service mesh for agents, giving operators one place to enforce policy, inspect traces, and pause traffic. The security value comes from governing the shared layer that all routed agents must traverse, rather than trying to rebuild equivalent controls inside every application platform.

Practical implication: place policy enforcement where agent traffic converges, not where it originates.

Why discovery, identity, and lifecycle must be unified

Cross-platform agent governance breaks when discovery is incomplete, identity is non-portable, and lifecycle state is trapped in vendor silos. A registry that only knows about platform-built agents misses shadow agents, third-party agents, and externally hosted agents. Without a shared principal and a consistent offboarding path, audit and containment become platform-by-platform exercises instead of a single operational process. That is the real governance gap: no common control surface for the agent fleet.

Practical implication: build one inventory and one lifecycle process for all governed agent sources, including remote and third-party systems.

Threat narrative

Attacker objective: The objective is to use fragmented agent governance to expand access, move laterally across platforms, and delay containment long enough to increase data exposure or operational disruption.

1. Entry happens when a third-party or shadow agent is introduced inside one platform, then begins reaching other systems through API and tool calls.
2. Escalation happens when the same agent inherits separate identities, tokens, and policy gaps across platforms, allowing broader access than any single control plane can see.
3. Impact occurs when misbehaving agent traffic continues until operators coordinate containment across multiple consoles, extending exposure and slowing audit response.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Agent identity without portability creates governance blind spots: each platform issuing its own identity means the same agent can appear differently depending on where it is running. That breaks the assumption that a principal is stable across systems, which is foundational to access review and revocation. The implication is that agent identity must be normalized before lifecycle governance can work.

Discovery is the first control that fails in shadow agent environments: if the registry only captures agents created by central teams, then business-built, vendor-supplied, and remote agents remain outside policy scope. This is a classic visibility failure, but it is amplified by AI because agents are often deployed faster than governance can enumerate them. The practitioner conclusion is that discovery must include sources, not just approvals.

Lifecycle governance has to operate at the shared execution layer or it will remain partial: the article’s core contribution is the reminder that containment windows shrink when agents can run across multiple platforms with different support queues and different revocation paths. That is a governance assumption built for single-platform control, and it no longer holds. The implication is that emergency control needs one operational chokepoint for governed traffic.

Credential sprawl is the hidden cost of multi-platform agent adoption: every per-user, per-tool OAuth flow expands the operational burden and complicates compliance evidence. The result is not just friction, but a larger revocation surface and more places where access can outlive intent. Practitioners should treat token sprawl as a governance debt, not a usability nuisance.

From our research:

• 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.
• For a deeper model of how agentic systems change identity assumptions, see OWASP Agentic AI Top 10 for the risk patterns practitioners are now mapping into control design.

What this signals

Agent fleet governance will increasingly converge on execution-layer controls: as more organisations run agents across multiple platforms, the key programme question is no longer whether each platform has a native control panel, but whether the enterprise can see and stop agent traffic in one place. That shift favours inventory, traceability, and revocation over isolated product dashboards, and it pushes identity teams closer to runtime operations.

With 80% of organisations already reporting agent behaviour beyond intended scope, the control debate has moved past hypothetical risk and into operational containment. Teams that can correlate agent identity, token ownership, and tool access will be able to absorb multi-platform adoption without losing auditability, especially if they pair their programme with the OWASP Agentic AI Top 10.

Cross-platform agent adoption also raises the value of lifecycle metrics that IAM teams have not historically tracked for software actors: owner coverage, revocation time, and the percentage of governed traffic that can be blocked from one control point. Those signals matter because the cost of delay is no longer theoretical; it is the difference between seconds and hours.

For practitioners

• Map every agent source into one inventory Include platform-built agents, third-party agents, shadow agents, and remote agents from external runtimes. If an agent can reach sensitive data or tools, it belongs in the inventory even when the hosting platform is outside the primary stack.
• Centralise policy at the shared execution layer Enforce allowlists, rate limits, PII filters, and approval gates where model and tool traffic converges. Do not rely on separate platform consoles to produce equivalent control outcomes across Microsoft, ServiceNow, Salesforce, and custom systems.
• Separate agent identity from platform identity Require a verifiable principal for each governed agent and avoid treating platform tenancy as proof of identity. Normalize owner, environment, tool scope, and trace metadata so access reviews do not depend on where the agent happens to run.
• Test containment on governed traffic only Measure the time from detection to block, pause, or revoke for traffic that routes through the gateway. If the response still requires multiple vendor consoles, the containment path is not operationally ready.
• Track OAuth and token sprawl as a governance metric Count per-user, per-tool authorizations, then verify where each token lives and how quickly it can be revoked. Repeated third-party sign-ins are a signal that access is being distributed faster than it can be governed.

Key takeaways

• Multi-platform AI agent adoption fragments identity, policy, and containment unless governance moves to the shared execution layer.
• Agent discovery and revocation are the two control areas most likely to fail when teams rely on platform-specific consoles alone.
• IAM and IGA teams should treat agent inventories, token sprawl, and containment speed as core programme metrics, not adjacent operational details.

Key terms

• Agent gateway: The local or remote control layer that authenticates, pairs, and orchestrates an AI agent’s actions across connected tools. In practice it becomes an identity concentrator, because one gateway session can govern messages, commands, and downstream systems with far broader reach than the user interface suggests.
• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• Token Sprawl: Token sprawl is the accumulation of too many active, forgotten, or overlapping tokens across SaaS and automation workflows. It creates visibility gaps, increases the chance of over-privilege, and makes revocation slow when an incident forces a response.

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.

👉 The full TruFoundry article covers the execution-layer architecture, registry model, and containment workflow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.