The Vendor in Your Environment You Didn't Hire: Third-Party Embedded AI Risk

TBDCyber | Agentic AI Security Series

This is the fourth article in our Agentic AI Security Series.

Your vendor risk management program knows how to handle third-party software. You conduct security assessments. You review SOC 2 reports. You negotiate data processing agreements. You check for encryption, access controls, and incident notification clauses. For two decades, this model has been the foundation of enterprise third-party risk management.

That model was designed for passive software. Software that processes data when a human user instructs it to, then waits. Software that does not initiate actions, make autonomous decisions, or interact with other systems on its own.

The software model is no longer what you are procuring.

When your organization last renewed its Salesforce contract, it inherited Agentforce. When your Microsoft 365 agreement was renewed, it included Copilot. When ServiceNow was upgraded, AI Agents were included. Workday, SAP, your ITSM platform, your HRIS - each of these has either already embedded agentic AI capabilities or will do so within the next renewal cycle.

You did not specifically approve the deployment of an autonomous agent in your environment. Your procurement decision did. And that agent is now operating with real credentials, real access to sensitive data, and real capacity to initiate actions inside a governance framework that was never designed to govern it.

The Inherited Agent Population

Enterprise organizations today are carrying a significant population of vendor-embedded AI agents that arrived not through explicit deployment decisions but through the normal cadence of SaaS licensing, upgrades, and feature rollouts.

These are not experiments or pilots. Salesforce Agentforce can autonomously manage customer cases, draft communications, and initiate workflows across the Salesforce data estate. Microsoft 365 Copilot can search, retrieve, draft, and send on behalf of users with access to the full breadth of an organization's Microsoft environment. ServiceNow AI Agents can independently resolve tickets, escalate incidents, and trigger changes across IT and business workflows. Workday AI operates inside HRIS and financial data. SAP Joule reaches into procurement and supply chain records.

In each case, the agent's business value proposition rests on its access footprint. It is useful precisely because it can reach across the organization's data and workflows. And its governance challenge is identical: the access footprint that makes it valuable is the same one that makes its governance inadequate.

The critical questions most organizations have not answered are: for each of these platforms, what identity does the agent use? Who provisioned it? Is it visible in the organization's identity directory? What is its lifecycle policy? What access does it actually have, not what the sales team described, but what the credential can reach?

In most cases, the answer is: we don't know.

The Identity and Credential Problem

When a vendor-embedded agent operates in your environment, a fundamental question that most procurement processes do not ask arises: what credential does this agent use, and who controls it?

The answer varies across vendors and platform architectures, but common patterns create consistent governance exposure. In many implementations, vendor agents authenticate using service accounts or OAuth tokens provisioned at deployment time and scoped to the vendor's platform. These credentials are often long-lived, may not appear in the organization's central identity directory, and may not be subject to the same rotation, review, and deprovisioning cycles applied to internally managed service accounts.

The organization did not provision the credential. The vendor did, or the platform provisioned it automatically during onboarding. The organization may have no direct access to rotate, audit, or revoke it without disrupting the platform's functionality.

This is an active condition in most enterprises running modern SaaS platforms. The vendor's agent is operating inside your environment, authenticating with a credential that does not appear in your identity directory, accessing data that may include your most sensitive records, under governance controls that belong to the vendor, not to you.

The Audit Trail You Don't Own

The identity problem has a direct consequence for accountability, and it is one that most security leaders have not yet mapped to their regulatory obligations.

When a vendor-embedded agent takes an action (e.g., accesses a record, initiates a workflow, transmits data, modifies a configuration), that action is logged. The question is: logged where, in whose system, in whose format, and available to whom?

In many vendor-embedded architectures, the agent's activity is logged within the vendor's platform. The organization can access that log through the vendor's interface, in the vendor's format, subject to the vendor's retention policies. Whether those logs can be ingested by the organization's SIEM, whether they contain sufficient detail to reconstruct what happened at the level a regulator would require, and whether they would be available in a form usable as evidence in a dispute or investigation are questions most organizations have not answered for their vendor-embedded agent population.

In regulated industries, this dependency is not merely inconvenient. Financial services organizations subject to SEC, FINRA, or NAIC requirements, healthcare organizations subject to HIPAA, and critical infrastructure operators subject to sector-specific frameworks all face audit obligations that assume organizational control over the evidence trail. An audit trail that lives within a vendor's platform, is accessible only through that vendor's tooling, and is subject to that vendor's retention policies may not satisfy the evidentiary control requirements imposed by those frameworks.

If a vendor-embedded agent caused a data exposure or compliance violation today, could you reconstruct what it did, what it accessed, and what authority it had to do so from your own systems, without depending on the vendor to provide the evidence? For most organizations, the answer is no.

The Five Questions Procurement Never Asks

Standard vendor security assessments (e.g., SOC 2 reviews, penetration test summaries, data processing agreements, encryption confirmations) address the security posture of the vendor's infrastructure. They do not address the identity governance posture of the agents that infrastructure enables in your environment.

Extending vendor risk assessment to cover embedded AI requires at least five specific questions for any platform with agentic capabilities.

Identity: What credential or service account does the vendor agent use to authenticate within our environment? Is that credential visible in our identity directory? What is its lifecycle policy (when do credentials expire, how are they rotated, who controls revocation)?

Scope: What data can the vendor agent access directly and through platform integrations? Has a least-privilege review been conducted against the agent's actual access footprint rather than its intended one? What is the cumulative data exposure if the agent credential is compromised?

Behavior: Is the agent's activity logged in a format that can be ingested by our SIEM? Can we establish a behavioral baseline and detect anomalies in the agent's activity pattern? Is logging configurable by us, or is it fixed by the vendor?

Accountability: If this agent causes data exposure or a compliance violation, do we have a sufficient audit trail in our own systems, in our own format, to reconstruct what happened and meet our regulatory reporting obligations without relying on the vendor to provide the evidence?

Contractual rights: Does our contract with the vendor provide audit rights, logging access, incident notification obligations, and the ability to restrict or disable agent capabilities? Do we have the right to understand and approve material changes to the agent's behavior and access scope before they are deployed?

Most vendor contracts do not address these questions explicitly. Most vendor security questionnaires do not ask them. AI-capable platforms should become a standard component of initial assessment and renewal review.

The Platform Vendor Governance Limit

There is a further governance dimension specific to the largest platform vendors that deserves explicit attention.

ServiceNow can govern the agents it creates. Microsoft can govern the agents operating within the Microsoft 365 ecosystem. Salesforce can govern the agents operating within Salesforce. Each of these vendors offers native agent governance capabilities (e.g., activity monitoring, access controls, and behavioral guardrails) that are genuinely useful within their respective perimeters.

But the governance they provide is bounded by their own ecosystem. A Microsoft agent that moves data from SharePoint to an external system via a third-party integration is within Microsoft's governance perimeter for SharePoint access but outside it for the external integration. A Salesforce agent that triggers a downstream workflow in your ERP is governed by Salesforce within Salesforce and ungoverned from Salesforce beyond it.

There is also a structural conflict of interest worth naming directly. Platform vendors have a commercial interest in the adoption and expanded use of their AI capabilities. Their governance frameworks are designed to make their agents trustworthy enough to deploy, not to provide the independent organizational oversight that enterprise governance requires. Relying on a platform vendor's governance tooling as the primary accountability mechanism for agents the platform enabled is structurally equivalent to asking a contractor to self-certify their work. It may be better than nothing. It is not the same as independent governance.

What Security Leaders Should Do Now

The vendor-embedded agent problem is not primarily a procurement problem. By the time the contract is signed, most of the governance exposure is already determined. The work is to identify what is operating now, establish minimum governance baselines against it, and update the procurement process for what comes next.

Inventory your vendor-embedded agent population now. For each significant SaaS platform in your environment (e.g.,  CRM, HRIS, ERP, ITSM, productivity suite), determine whether it has AI agent capabilities, whether those capabilities are active or in evaluation, what credential the agent uses, and who the internal owner is. This inventory does not require new tooling to start. It requires asking the question and documenting the answer.

Apply the five questions retroactively to active deployments. For platforms already running AI agents, work through the five governance questions above. Identify which questions cannot currently be answered. The gaps are the priority. Escalate the questions about logging and the audit trail first. The credential and scope problems create exposure, but the audit trail problem means you cannot demonstrate what exposure occurred when something goes wrong.

Update your vendor risk assessment template. Add AI agent governance as a mandatory assessment category for any platform with agentic capabilities, effective immediately for renewals and new procurements. The five questions above are a workable starting point. The goal is to make governance of embedded AI agents a standard, non-negotiable assessment criterion.

***

The agents that arrived with your SaaS renewals are not going away. The platforms enabling them will expand their capabilities with each release cycle. The governance gap between the access they hold and the oversight your organization has over how they use it is real, measurable, and in most enterprises, not yet adequately addressed.

The organizations that get ahead of this will be the ones that stop treating vendor-embedded AI as a variation on the software security problem they already know how to manage, and start treating it as an identity governance problem that requires a different set of questions, a different set of controls, and a different kind of accountability architecture.

This is the fourth article in TBDCyber's Agentic AI Security series. For the complete picture of how vendor-embedded agents fit into the broader governance gap, see our full research report.

The next article examines a specific dimension of this problem that warrants its own treatment: the structural conflict of interest in which platform vendors govern the agents they also profit from deploying.

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