Cross-platform AI agent governance exposes a shared execution gap

At a glance

What this is: This is an analysis of why governing AI agents across multiple enterprise platforms breaks down at the shared execution layer rather than within any single app console.

Why it matters: It matters because IAM, IGA and security teams need one way to discover, authorise, observe and revoke agent activity across platforms instead of inheriting fragmented control planes.

Context

AI agent governance becomes a cross-platform identity problem when each SaaS or productivity platform issues its own runtime, policy boundary and operational console. In that model, discovery, authorisation and containment no longer live in one place, so the governance programme has to account for the shared execution layer where agents actually act.

TruFoundry’s analysis focuses on the practical gap created when enterprises adopt multiple agent-enabled platforms independently. The issue is not whether each platform has controls, but whether those controls remain consistent when an agent calls APIs, handles sensitive content or needs to be stopped quickly across vendor boundaries.

Key questions

Q: What breaks when AI governance is limited to one platform instead of the systems where models and agents actually operate?

A: Governance breaks when control stays detached from the tools, data sources, and workflows used by AI systems. Teams lose visibility into actual access paths, policy drift goes unnoticed, and enforcement becomes inconsistent. Effective AI governance needs integration points that connect policy decisions to the operational environment where AI runs and interacts with data.

Q: Why do cross-platform AI agents create more access risk than single-platform agents?

A: Because each platform adds its own identity, consent and token lifecycle, which multiplies the number of places access can drift or persist. The risk grows when a single business process is split across several runtimes and no one layer owns the complete authorisation picture.

Q: How can organisations tell whether AI agent governance is actually working?

A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level. If the organisation cannot show which runtime acted, what it touched, and which endpoint or command it used, then governance is still too coarse. Effective control produces auditable decisions, not just authentication events.

Q: What should IAM teams do when an AI agent is used across several SaaS platforms?

A: Establish one authoritative inventory and one lifecycle path for the agent, then decide which policy and revocation actions must be enforced at the shared execution layer. Platform-native controls can still matter, but they should not be the only place where governance exists.

Technical breakdown

Why platform-local agent identity breaks down

When each platform issues its own agent identity, the same agent has different meaning in different systems. Identity, policy and audit state are therefore not portable, which makes governance dependent on where the workload happens to run. This is structurally different from human SSO, where the user principal can often be federated across apps. For agents, the runtime itself becomes the identity boundary, and that creates drift in authorisation, traceability and revocation. Practical implication: treat platform-local identities as partial control surfaces, not a complete governance model.

Practical implication: Treat platform-local identities as partial control surfaces, not a complete governance model.

How the credential tax multiplies access risk

Cross-platform agents frequently force per-user, per-tool OAuth consent and token storage. That creates a hidden credential tax: every new agent expands the number of authorisations, tokens and revocation points that security teams must manage. The risk is not only exposure of tokens, but also the operational burden of proving which connected service still needs access when contracts change or incidents occur. In practice, the credential estate becomes more distributed as agent adoption scales. Practical implication: map token issuance, consent and revocation as one lifecycle, not as isolated application events.

Practical implication: Map token issuance, consent and revocation as one lifecycle, not as isolated application events.

What an execution-layer control plane changes

A shared execution layer governs the model and tool calls that every agent eventually makes, regardless of which platform hosts it. That allows policy, traces, rate limits and containment actions to apply at the point where agent activity is actually executed, rather than only inside the source platform. This is a governance pattern for stateful agent runs, not just stateless prompts. For identity teams, the key architectural shift is that enforcement moves closer to action and away from fragmented app-native consoles. Practical implication: evaluate whether your control layer can see routed traffic before you assume platform-native governance is sufficient.

Practical implication: Evaluate whether your control layer can see routed traffic before you assume platform-native governance is sufficient.

NHI Mgmt Group analysis

Cross-platform AI agent governance is an execution-layer problem, not an app-console problem. Once agents span Copilot, ServiceNow, Salesforce and custom systems, no single platform owns the full identity, policy and lifecycle picture. That means governance has to move to the shared execution layer where agent actions are actually routed, observed and constrained. Practitioners should stop assuming that platform-native controls add up to enterprise-wide control.

The hidden credential tax is the clearest sign that agent governance has become lifecycle sprawl. Per-user, per-tool OAuth consent multiplies tokens, revocation points and audit obligations across the enterprise. This is not just friction for users, it is a lifecycle management problem for machine identities that outgrows application-by-application administration. The practical conclusion is that agent access now needs central lifecycle oversight, not just local app approval.

Discovery is now a control requirement, not an inventory nicety. Agents appear as platform-built, business-built, vendor-supplied or tool-generated assets, and many will never be visible in the place where security teams expected to find them. The result is shadow AI at the identity layer, where undiscovered agents can still reach sensitive data or tools. Practitioners should treat cross-platform discovery as the first governance dependency, because what cannot be found cannot be governed.

Shared execution governance will increasingly define the market boundary for enterprise agent controls. Platform-native controls remain necessary, but they do not answer the enterprise question of how to govern routed traffic, traces, policies and emergency containment across systems. That is why the category is moving toward control planes that sit above individual agent runtimes. For IAM and IGA teams, the near-term task is to decide where the authoritative enforcement point should live.

Cross-platform agent identity needs a consistent principal model before it needs more policy text. If an agent’s identity changes meaning from one platform to the next, policy inheritance and audit reconstruction will remain brittle. The governance problem is not merely missing rules, it is inconsistent subjects of control. Practitioners should focus on whether every governed agent has one verifiable principal, one lifecycle state and one revocation path.

From our research library:

• 62% of organisations are at least experimenting with AI agents, but only 23% have scaled one into a single business function, according to McKinsey's 2025 State of AI survey.
• Read next: Agentic AI Identity Guide

What this signals

Shared execution governance is becoming the decisive control plane for enterprise agent programmes. When agents spread across multiple platforms, the question is no longer whether each vendor has a security story, but whether the organisation can govern routed traffic, traces and containment from one place. That pushes IAM teams toward execution-layer policy and away from console-by-console exception handling.

Shadow AI now includes undiscovered agent identities as much as undiscovered models. The discovery problem is not limited to rogue prompts or hidden chatbots. If a business unit or vendor can stand up an agent without registering it in the central control path, the organisation loses the ability to certify ownership, revoke access or prove policy coverage.

Agent lifecycle management has to absorb OAuth sprawl before the operational burden becomes the security debt. Per-tool consent and token storage create an expanding revocation surface that traditional application administration was never designed to reconcile. The practical signal is simple: if you cannot answer where an agent’s credentials live, you do not yet govern the agent.

For practitioners

• Define the shared enforcement layer Map which agent actions are governed only inside platform consoles and which can be moved to a shared execution layer that sees routed model and tool traffic.
• Inventory all agent sources Build one registry that includes platform-built agents, business-built shadow agents, vendor-supplied agents and remote agents registered from other runtimes.
• Centralise OAuth consent and revocation Track per-user, per-tool authorisations as a single lifecycle so token sprawl and revocation work are visible before incidents force cleanup.
• Test containment across consoles Measure how long it takes to pause or revoke a misbehaving agent when more than one vendor platform is involved, then compare that with your response target.
• Require one principal per governed agent Do not allow the same agent to have different governance identities in different platforms if you need consistent audit, policy and lifecycle handling.

Key takeaways

• Cross-platform AI agents create a governance gap because identity, policy and revocation do not automatically follow the agent across vendor runtimes.
• Discovery and containment become harder as agents move between platforms, since every runtime can introduce its own principal, token and audit state.
• IAM and IGA teams need one authoritative inventory and one enforcement layer for governed agent traffic if they want consistent control across platforms.

Key terms

• Shared Execution Layer: The common runtime path where an AI agent’s model calls, tool calls and stateful actions are actually executed. In cross-platform environments, governing this layer is often more effective than relying on separate platform consoles because it sees the traffic that the agent emits, regardless of where it was created.
• Agent Principal: An agent principal is a distinct identity issued to an AI agent so it can authenticate and be audited separately from the human it serves. In practice, it should have its own lifecycle, scoped credentials, and revocation path, because borrowing a human session collapses accountability and widens blast radius.
• Configuration Tax: Configuration tax is the ongoing operational cost created when a security control requires frequent manual tuning just to remain effective. It shows up as analyst time, coordination overhead, and knowledge concentration. Over time, the tax can become the hidden work that preserves baseline performance rather than improving security outcomes.
• 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.

Deepen your knowledge

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