Blank white background with no objects or features visible.

TrueFoundry announces the acquisition of Seldon AI, expanding its Control Plane for Enterprise AI. Full press release →

Governing AI Agents Across Multiple Platforms

By TrueFoundry

Published: July 7, 2026

Most enterprises did not decide to adopt AI agents across five platforms. It happened to them. Microsoft Copilot arrived with the productivity suite. ServiceNow shipped Now Assist into the ticket queue. Salesforce turned on Agentforce inside the CRM. Other data and SaaS platforms began running agents next to the systems of record. Each platform brought its own AI runtime — and, quietly, its own governance story that stops at the platform’s edge.

The result is a governance gap that is hard for any one application-platform vendor to close alone. When an agent inside one platform calls an API, who authorized it? When an agent in another summarizes a sensitive document, which policy governed the response? And when an agent misbehaves in production, who can quickly contain it — without coordinating across multiple vendor consoles or support queues?

This is not a future-state risk. It is the operational reality for any organization that adopted more than one AI platform independently — which is increasingly common in large enterprises.

The shape of the problem

Before anyone talks about a solution, it’s worth being precise about why this is genuinely hard. The difficulty is structural, and it shows up in four places at once.

Discovery

You can’t govern what you can’t find

Agents appear four ways: built by platform teams, built by business users (shadow agents), licensed from vendors, or generated by tooling with no human review. A registry that only holds the agents you already knew about misses most of the risk.

Policy

Policy that lives in one platform stops there

A DLP rule in one ecosystem does not apply to an agent in another calling the same sensitive data. A rate limit in one tool does not constrain a job in the next. Siloed policy is no policy at all.

Identity

Each platform issues its own identity

An agent’s identity in one platform means nothing to another. Without a shared principal, “who is this agent and what is it allowed to do” has a different answer on every platform.

Lifecycle

No consistent emergency-control path

When an agent goes wrong, the response window is often minutes. Coordinating containment across multiple vendor consoles or support queues can stretch what should be a quick action into hours.

And there is a fifth problem that only becomes visible the moment a user tries to actually do something with a third-party agent: the credential tax.

The hidden credential tax

Consider a routine prompt sent to an official third-party agent installed inside a Copilot-style assistant. The first time a user touches it, the agent can’t answer until the user signs in to that third-party service directly.

A third-party agent prompting the user to sign in via OAuth before it can respond
Fig. 01 · The per-tool OAuth prompt. The first time a user touches a third-party agent, they’re handed a sign-in wall. Every third-party agent in the store follows the same pattern — repeated per user, per tool.

This is not a bug. It is the only safe architecture when each agent is a separately-vended product. But stacked across an enterprise’s full tool inventory, it has real operational consequences:

  • Per-user, per-tool friction. Every employee re-authorizes every agent the first time they use it. Multiply by the workforce, then by the tool inventory.
  • Token sprawl. OAuth tokens for every connected service end up scattered across user identity stores. Compliance becomes a per-vendor question instead of a single audit trail.
  • No central revocation. When a contract changes or an incident requires cutting access, the org chases it through each vendor relationship rather than at one chokepoint.

How a cross-platform control plane can work

An architectural pattern that addresses this gap directly is to govern at the layer all these platforms have in common. Every agent, no matter which platform hosts it, eventually makes an LLM call or a tool call. Intercept and govern there, and you govern the agent activity that routes through that shared execution layer — without asking every application platform to rebuild itself.

This is the premise behind TrueFoundry’s Agent Gateway: a dedicated control layer for AI agents in production, sitting in front of the models and tools every agent depends on. TrueFoundry draws a sharp line between an AI gateway, which manages stateless prompts and tokens, and an agent gateway, which is the data plane for agentic AI — stateful sessions, multi-step execution, and the data moving between agents and their tools. It behaves like a service mesh built specifically for agentic systems.

Above the gateways sits a fourth layer: the Agent Harness. A harness is the runtime around an LLM — the orchestration loop that plans, calls tools, manages context, gates sensitive actions through approvals, and records every step into a trace. It is what turns a model call into a reliable, long-running agent.

Agent Harness diagram: the harness orchestrates the run between a user goal and a final response, routing between model, tools and MCP servers, sandbox, and approval gates, while enforcing guardrails and recording a full trace
Fig. 02 ¡ What an Agent Harness does. Sits between a user goal and the final response. Orchestrates the agent run, routes between model, tools, sandbox, and approval gates, enforces guardrails, and records a full trace for transparency and debugging.

TrueFoundry ships this as a managed service rather than a framework. A sandboxed execution environment runs code and long-running tasks. Human-in-the-loop approval gates pause sensitive tool calls until a user approves. A versioned Skills Registry holds reusable instructions with RBAC. And critically — no API keys or credentials ever live in agent definitions; they live in the gateways, where platform teams configure access once and agent builders never touch secrets.

TrueFoundry agent overview dashboard with registry, active users, runtime, and analytics
Fig. 03 · A single operational view. Agent registry count, active users, runtime hours, pending requests, agents at risk, agents without owners, and analytics — the operational primitives an admin team expects, with the data plane running in the customer’s own infrastructure.

Crucially, discovery isn’t limited to agents you built on the platform. Agents running elsewhere — on Bedrock, LangGraph, a custom HTTP service, or another vendor’s platform — register into the same inventory as remote agents, with the same metadata and the same controls. The fragmented fleet becomes one map.

Agent map clustering agents by source platform: third-party, Microsoft, Agent Builder, others
Fig. 04 · The fleet, clustered by source. Agents grouped by origin — third-party, Microsoft-native, platform-built, and others — so an operator can see at a glance what fraction of the fleet comes from where, and govern the registered/routed portion from one place.

Five capabilities worth looking for

For teams evaluating how to close this gap, the following five capabilities are worth examining closely — with a note on what each one tends to require under the hood.

1

A centralized control plane across routed agent traffic

One layer that can govern agent traffic you route or register from Copilot, ServiceNow, Salesforce, and custom systems — rather than relying only on separate consoles.

How: the gateway can enforce policy on routed model and tool calls regardless of originating platform, so logging and limits apply uniformly where traffic passes through it — at typically under 5ms of overhead.
2

Discovery and a registry with rich metadata

Discovery and registration of governed agents, with owner, environment, model, tool permissions, and activity captured where integrations or routing provide visibility.

How: remote-agent registration can bring agents from multiple sources into one inventory; gateway telemetry keeps metadata live for governed traffic.
3

Unified governance — identity, policy, observability, lifecycle

One verifiable identity per agent, policies defined once, traces you can actually read, and a single place to manage state.

How: gateway-issued principals with federated SSO, step-level OpenTelemetry traces, and token/cost attribution by agent, team, and environment.
4

Policy enforcement across otherwise siloed ecosystems

PII filtering, guardrails, rate limits, budgets, and tool allowlists that hold consistently for traffic routed through the shared model/tool layer.

How: because the gateway sits at the shared model/tool layer, a policy written once is enforced consistently across routed traffic — pre- and post-call.
5

Fast containment for governed traffic

A single action that pauses, blocks, or revokes a misbehaving agent’s traffic at the gateway, with a timestamped audit trail. For agents whose traffic routes through the platform, this gives a single emergency-control path; agents living entirely inside another platform still require that platform’s own controls.

How: the registry holds real-time lifecycle state for governed agents; one API call or click takes effect across every model and tool call that flows through the gateway.
Why this matters operationally In practice, the difference between governance that stops at a platform edge and governance at the shared execution layer can mean the difference between hours and seconds when something goes wrong — and between a per-vendor compliance scramble and a single audit trail.

Production-grade architecture

A control plane is only useful if it can carry real load without becoming the bottleneck it was meant to remove. TrueFoundry reports the kind of numbers that matter at enterprise scale:

99.99%
Uptime via centralized failover & routing
10B+
Requests processed per month
~30%
Average cost optimization

It runs entirely in your environment — VPC, on-prem, air-gapped, or across multiple clouds — so no data leaves your domain, with SOC 2, HIPAA, and GDPR posture maintained by design. And because the underlying agent gateway is a Linux Foundation open-source project, the control layer isn’t a proprietary black box, and you aren’t locked into one vendor’s framework.

This doesn’t replace your platform investments

An important clarification, because it’s the most common objection: governing at the execution layer is not a rip-and-replace of the platform-native tools you already use. If your sensitive knowledge-worker data lives in M365, a tool like Microsoft Agent 365 governs that surface well — identity, data, and distribution inside the Microsoft ecosystem. Based on Microsoft’s launch materials and public coverage available as of June 2026, Agent 365 also extended its discovery surface across clouds at GA via Registry Sync to AWS Bedrock and Google Gemini Enterprise — a credible cross-cloud move on the discovery side.

Based on the same launch materials, the SaaS platforms where a significant share of enterprise agent work runs today have not been part of that initial sync scope — agents inside Salesforce Agentforce and ServiceNow AI Agents, both generally available since 2024, were not in the initial Registry Sync coverage, and policy enforcement for any synced agent still flows through Microsoft’s own controls rather than the source platform’s. Microsoft’s connector coverage may expand over time; readers should verify the current list before relying on this detail. The execution layer remains a surface that every platform genuinely shares.

Architectural surface area: platform-native governance for the M365 surface, execution-layer governance underneath everything
Fig. 05 · Layered, not competing. Platform-native governance handles its own surface — identity, data, distribution. An execution-layer control plane handles model access, tool access, and the agent runtime underneath everything. The mature pattern uses both.

Where to start

The fastest way to know whether this closes your gap is to prove it on your own traffic, scoped to the capabilities that hurt most today:

  • Deploy the gateway in a sandbox VPC and route a slice of real agent traffic through it. Confirm the latency overhead and the observability output.
  • Register a handful of existing agents from at least two different platforms. Confirm the metadata and the unified inventory.
  • Define two or three cross-platform policies — a PII filter, a rate limit, a tool allowlist — and confirm they hold across the registered/routed agents in scope.
  • Time the containment for governed paths: trigger to enforcement, with the audit log to show for it.

See it govern your own fleet

Deploy in your environment, route the agent traffic you control through one governed layer, and see where cross-platform policy takes hold.

Explore the Agent Gateway →

‍

⚠ Editorial Disclaimer This article is published by TrueFoundry, Inc. for informational purposes only, based on analysis of publicly available vendor documentation as of June 2026. All views expressed are corporate positions of TrueFoundry, not those of any individual contributor, and do not constitute professional, legal, or purchasing advice. Microsoft has not reviewed, endorsed, or sponsored this article. Product features, pricing, and roadmaps are subject to change without notice; figures shown are sourced from public materials or are illustrative diagrams. Original analysis, text, and diagrams are the property of TrueFoundry, Inc.; all third-party product names and trademarks are the property of their respective owners. Verify all information against current vendor documentation before making architectural or purchasing decisions.

Sources

  1. Microsoft Learn — Microsoft Agent 365 Overview (GA, observe / govern / secure pillars).
  2. Microsoft Learn — Microsoft Agent 365 SDK Overview.
  3. Windows Central — Microsoft 365 E7 plan announcement ($15/user/month standalone; $99/user/month in E7 bundle).
  4. Registry Sync scope referenced in this article is based on Microsoft's public GA materials and contemporaneous coverage as of June 2026; readers should verify the current connector list against Microsoft's documentation before relying on it.
  5. TrueFoundry — Agent Gateway product page (control pillars, stateful agent mesh, 99.99% uptime, 10B+ requests/month, ~30% cost optimization, Linux Foundation project, VPC / on-prem / air-gapped deployment).
  6. TrueFoundry Docs — AI Gateway (1,000+ LLMs, latency overhead) and Agent Harness Overview (managed runtime, sandbox, HITL approvals, Skills Registry, no-keys credential model).

The fastest way to build, govern and scale your AI

Sign Up
Table of Contents

One Gateway for Every LLM, Agent and MCP Server

Book a 30-min with our AI expert

Book a Demo

The fastest way to build, govern and scale your AI

Book Demo
Summarize with
ChatGPT logo by OpenAI
Perplexity AI logo
Blurry red snowflake on white background, symmetrical frosty design with soft edges and abstract shape.

Discover More

No items found.
TrueFoundry AI gateway is an enterprise alternative to OpenRouter and Bifrost
July 7, 2026
|
5 min read

Bifrost vs OpenRouter: A Practical Comparison for Engineering Teams in 2026

No items found.
TrueFoundry AI gateway is an enterprise alternative to OpenRouter and Helicone
July 7, 2026
|
5 min read

Helicone vs OpenRouter: Which Platform Fits Your Production Stack?

No items found.
July 7, 2026
|
5 min read

Governing AI Agents Across Multiple Platforms

No items found.
July 7, 2026
|
5 min read

Online Evaluation and Quality Monitoring at the Gateway

No items found.
No items found.

Recent Blogs

Black left pointing arrow symbol on white background, directional indicator.
Black left pointing arrow symbol on white background, directional indicator.
Take a quick product tour
Start Product Tour
Product Tour