Who Governs the Agents You Didn't Build? The Platform Vendor Conflict of Interest

TBDCyber | Agentic AI Security Series

This is our fifth article in our Agentic AI Security series.  Our first two articles have discussed the problem framework (see The 45 Billion Identity Problem Nobody Is Talking About and The Identity Paradox: Why Agentic AI Breaks IAM by Design). Articles 3-4 mapped internal and external agent risk (see Shadow AI Is Already Here, And Your Security Team Doesn't Know It and The Vendor in Your Environment You Didn't Hire: Third-Party Embedded AI Risk). In this article, we discuss the platform vendor governance accountability gaps.

***

When security leaders ask how to govern the AI agents embedded in their enterprise platforms, vendors are ready with an answer. ServiceNow has Agent Control Tower. Microsoft has policy controls for Purview and Copilot Studio. Salesforce has Agentforce governance. AWS has AgentCore with Cedar policy enforcement. The message from each is consistent: our platform enables the agents, and our governance tooling manages them. You are covered.

That answer deserves more scrutiny than most organizations are currently giving it.

Not because platform-native governance tools are without value. Several are technically sophisticated and genuinely useful within their scope. But because the scope is the problem. And beneath the scope question lies a conflict of interest that is structural, not incidental, and has direct implications for whether platform-vendor governance can ever serve as a substitute for independent enterprise oversight.

The Walled Garden Problem

ServiceNow can govern the agents it creates. Microsoft Purview can monitor agents built in Copilot Studio and deployed in the Microsoft 365 ecosystem. Salesforce governs Agentforce within the Salesforce perimeter. AWS AgentCore applies Cedar policy enforcement to agents running on AWS infrastructure.

Each of these capabilities is real and, within its perimeter, meaningful. The problem is that the perimeter ends precisely at the edge of the platform.

Consider an organization running agents across a reasonably standard enterprise stack: ServiceNow for ITSM, Salesforce for CRM, Microsoft 365 Copilot for productivity, and a custom agent deployed on AWS. That organization has four separate agent governance perimeters, four separate agent inventories, and four separate audit trails. There is no unified view across them. There is no consistent policy enforced at the organizational level. There is no mechanism by which the security function can see the complete agent population, assess cumulative access footprint, or detect anomalies that span platform boundaries.

This is not a maturity gap that will close as each vendor adds features. It is the structural consequence of governance architectures designed to manage agents within a platform, rather than govern identities across an enterprise. A vendor whose business model is built on a platform has every reason to make that platform's agents governable. They have no structural incentive to make it easy to govern agents that live outside their ecosystem, that might be replaced by a competitor's offering, or that a customer might choose to move.

The unified governance view is not a product that any single platform vendor can credibly deliver. Their perimeter is the limit of their governance. The enterprise's governance requirement extends beyond any single vendor's perimeter.

The Conflict of Interest

The perimeter problem is structural. The conflict of interest is commercial, and it runs deeper.

Platform vendors have a strong and direct financial incentive to expand agent deployment within their platforms. More agents built in Copilot Studio means more Microsoft 365 usage. More Agentforce deployments mean deeper Salesforce entrenchment. More ServiceNow agents mean more workflow automation, which creates lock-in, expands the platform's footprint, and increases renewal value. Agent adoption is not a neutral feature for these vendors; it is a strategic revenue driver.

Their governance tooling is designed in this context. The goal is to make agent deployment safe enough to proceed broadly, not to impose the constraints that an independent security function, unencumbered by commercial considerations, would apply. These are different design objectives, and they produce different outcomes.

This does not make the tooling malicious or the vendors bad actors. AWS's Cedar policy language is technically sophisticated and genuinely useful for deterministic permission enforcement. ServiceNow's Agent Control Tower provides real visibility into ServiceNow-native agents that would otherwise be difficult to track. The point is not that these tools should be discarded. It is that the governance they provide reflects the platform vendor's risk calibration, not the enterprise's.

A security function that accepts a platform vendor's governance tooling as its primary accountability mechanism for agents enabled by the platform has, in effect, delegated its governance judgment to an entity with a commercial interest in permissive outcomes.

The Opt-In Governance Problem

There is a third structural limitation that warrants specific attention in the context of citizen-developer agents, which we examined in the previous article.

When a business user creates an agent in Microsoft Copilot Studio or ServiceNow's low-code environment, the platform's governance controls can, in principle, apply to that agent. But only if those controls have been configured by the security or IT team in advance. Platform governance tooling operates on an opt-in model: governance capability is provided, but it is not enforced by default.

The organizational assumption is that "the platform handles it,” and that is precisely the condition under which shadow agent populations grow unchecked within licensed enterprise tools. A security team that has not explicitly configured Copilot Studio's data classification controls, sensitivity labels, and agent scope restrictions has not gained the governance those features could provide. They have licensed a platform with governance features. That is not the same thing.

The configuration gap matters because the business users creating agents are not waiting for the security team to configure the governance controls before they build. They are building now with default settings and permissions, against live production data. By the time the security team has finished the configuration exercise, an unknown number of ungoverned agents may already be operating under the human credentials of users who built them months ago.

Platform governance is not self-executing. It requires active configuration, maintenance, and monitoring to deliver on its promises. Organizations that treat platform procurement as a substitute for governance investment will discover the difference when an incident exposes the gap.

What Independent Governance Actually Requires

Understanding the limits of platform-native governance is not an argument against using it. It is an argument for treating it as a necessary but insufficient component of a governance architecture that the enterprise security function independently owns and operates.

Independent governance in the agentic era requires several capabilities that platform vendors cannot provide on their own.

A unified agent inventory that does not depend on each platform's own reporting. The security function needs a view of the full agent population across all platforms (developer-deployed, citizen developer, vendor-embedded) that is maintained independently of the vendors whose agents populate it. If the only record of a ServiceNow agent's existence is in ServiceNow's own inventory, the organization's ability to govern that agent depends on ServiceNow maintaining and surfacing accurate information. For most governance purposes, that dependency is an unacceptable single point of trust.

Cross-platform behavioral monitoring. Threats that manifest as anomalies spanning multiple platform perimeters (e.g., an agent in Salesforce exfiltrating data that appears in a Microsoft 365 communication chain) are invisible to any single platform's behavioral monitoring. The security function needs detection capability that operates at the organizational level, ingesting agent activity signals from multiple platforms into a unified behavioral model. This requires that each platform's agent logs be available in a format the SIEM can ingest, which is itself a contractual requirement.

Platform-independent policy authority. The policies that govern what agents can do, what data they can access, and which actions require human authorization should be defined by the enterprise security function and enforced across platforms.  Not defined separately by each vendor according to their own defaults. This is a harder governance problem than it sounds, because the technical mechanisms for cross-platform policy enforcement are immature. But the principle is the starting point: organizational policy is not a setting in each vendor's administrative console. It is a governance function that the enterprise owns.

A Practical Assessment Framework

Given the structural limitations of platform-native governance, security leaders evaluating their current posture should work through a short set of questions for each major platform in their environment.

Does our governance view extend beyond this platform's own reporting? If the only source of truth for agents operating in this platform is the platform itself, the organization's oversight is bounded by the vendor's perimeter.

Has the platform's governance tooling been explicitly configured? Not licensed, configured. What policies are active? What defaults were accepted without review? Which agent capabilities are available to business users without the security team's involvement?

Can this platform's agent activity be ingested into our SIEM independently of the platform's own interface? If agent activity is only visible through the platform's reporting tools, behavioral monitoring depends on the vendor's alerting rather than the organization's detection capability.

Who in our security function owns the governance posture for this platform's agents? Not the platform administrator. The security function. If there is no named owner in the security organization for each major platform's agent governance posture, a gap exists.

Does our contract provide the audit rights, logging access, and incident notification obligations required by our regulatory frameworks? The platform's governance terms are set by the vendor's standard agreements. The defaults may not satisfy the organization's regulatory obligations.

***

Platform vendors have built genuinely useful governance capabilities. They have also built those capabilities to serve their own architecture, commercial interests, and customers' desire for frictionless deployment. Those are legitimate design goals. They are not the same as the independent governance mandate that enterprise security functions carry.

The organizations that govern agentic AI effectively will be the ones that use platform-native tools where they add value, while maintaining an independent governance function that owns the unified view, the cross-platform policy authority, and the audit trail that no single vendor can provide on its own.

This is the fifth article in TBDCyber's Agentic AI Security series. Our full research report examines this conflict of interest in more depth, alongside the broader agentic AI governance landscape. Read the whitepaper here.

The next article addresses a risk that most compliance teams have not yet fully mapped: the Bring Your Own Agent problem, and what happens to your governance posture when the agent belongs to the employee, not the organization.

TBDCyber advises security leaders on identity governance, agentic AI security, and emerging threat architectures. To discuss what this means for your organization, contact us.