Governing SaaS-embedded AI agents: the governance gap you didn't know you had
David Baum 13 min read The agents you didn’t deploy#
How many AI agents are running in your SaaS stack right now?
Not the agents your engineering team built. Not the ones in your registry. The ones your SaaS vendors shipped as feature updates: Salesforce Agentforce, HubSpot Breeze, Zendesk AI agents, Microsoft 365 Copilot agents, ServiceNow Now Assist. Agents that process your customer data, make decisions inside your business systems and take actions on behalf of your employees. Agents that sit completely outside your governance framework because nobody in your organization deployed them. Your vendor did.
Komprise’s 2025 IT Survey found that 90% of IT directors and executives are concerned about shadow AI from a privacy and security standpoint and nearly 80% have already experienced negative AI-related data incidents. Vectra AI’s 2026 analysis reports that 98% of organizations have unsanctioned AI use and warns that agentic shadow AI represents “a fundamentally different risk category” because these agents act autonomously, continuously and across systems.
Gartner predicts that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. Yet according to BetterCloud, only 22% of enterprises prioritized AI governance policy in 2025. The average enterprise runs over 500 SaaS applications (CloudEagle). If even 40% of those now embed AI agents, that’s 200 agents operating in your environment that your governance team may not know about.
This isn’t a future problem. The governance gap isn’t that you haven’t governed the agents you built. It’s that your SaaS vendors are shipping agents into your stack without your governance team’s knowledge, and those agents may already be processing your most sensitive data.
Five governance gaps#
SaaS-embedded agents create five distinct governance gaps that traditional agent governance frameworks don’t address.
Gap 1: Discovery#
You didn’t deploy these agents. Your vendor shipped them as a feature update. They may be enabled by default, turned on by an admin who didn’t understand the governance implications or activated by an end user with one click. Your agent registry doesn’t know they exist because they were never registered. They arrived as a SaaS feature, not as an agent deployment.
Shadow AI isn’t just new tools. It’s hiding in the SaaS you already trust. 87% of enterprises have Microsoft Copilot enabled, more than half the agents access sensitive data, 90% are over-permissioned and they move 16 times more data than humans.
Obsidian Security’s March 2026 analysis reinforces this point. The AI features embedded in your existing, approved SaaS applications are the ones most likely to escape governance review, precisely because the application itself was already approved.
A Roval agent inventory scan typically surfaces 2-3x more SaaS-embedded agents than teams expect, because it discovers agents through API integration metadata rather than relying on manual registration.
Gap 2: Classification#
You can’t classify what you can’t see. Your three-dimension risk classification (data sensitivity, decision authority, blast radius) requires knowing what data an agent accesses, what actions it can take and who is affected. For agents you build, this information is available at registration. For SaaS-embedded agents, it depends on the vendor’s documentation, which may be incomplete, may change without notice and may not map to your governance framework’s terminology.
A Salesforce Agentforce agent processing your customer records has a data sensitivity score of at least 3 (Confidential). If it can autonomously update CRM records or send emails on behalf of your team, its decision authority is 3 (Supervised). If it’s customer-facing, its blast radius is 4 (External). That’s a Tier 3 agent (requiring human oversight, 180-day certification and a production gate) but it was never classified because it was never in your registry.
Gap 3: Data flow opacity#
When a SaaS-embedded agent processes your data, where does that data go? To the vendor’s LLM? To a third-party model provider? Is it used for model training? Is it cached, logged or stored outside your data residency boundary? These questions often have unclear answers and the answers may change when the vendor updates its AI capabilities.
Gap 4: Configuration drift without visibility#
Your vendor can update the agent’s underlying model, change its behavior, expand its capabilities or modify its data access, all without notifying you. This is configuration drift that you can’t detect because you don’t control the system. Your drift detection runs on agents in your registry; SaaS-embedded agents are outside that perimeter.
The next wave of AI failure does not look like rogue tools. It looks like unversioned, unaudited logic embedded inside SaaS platforms.
Eriksvik, a Nordic AI strategist, warned in his December 2025 predictions that SaaS-embedded agent logic represents “a new class of shadow code that executes continuously, changes data, incurs cost and carries regulatory risk without software-grade governance.”
When Salesforce updates Agentforce’s model or HubSpot enhances Breeze’s capabilities, the agents processing your data change, but your certification status, risk classification and compliance documentation don’t reflect the new state. Point-in-time reviews become what Obsidian Security calls “a policy fiction.”
Gap 5: Shared responsibility confusion#
When a SaaS-embedded agent makes an error (gives wrong advice to a customer, mishandles PII, makes an incorrect automated decision), who is responsible? The vendor who built the agent? Your organization that uses the SaaS product? The admin who enabled the AI feature? The employee who interacted with it?
The EU AI Act provides a clear answer that most organizations haven’t internalized yet.
The EU AI Act deployer problem#
This deserves its own section because it’s the most underappreciated compliance risk in the current market.
Article 26 of the EU AI Act assigns obligations to deployers of high-risk AI systems, regardless of who built them. If your SaaS vendor ships an AI agent that qualifies as high-risk under the Act and your organization uses it, you are the deployer. Article 26(1) requires deployers to ensure their use conforms with the provider’s instructions. Article 26(5) requires deployers to monitor the operation of the high-risk AI system. Your vendor’s compliance doesn’t absolve yours.
The EU AI Act distinguishes between providers (who build AI systems) and deployers (who use them). Most enterprise governance programs focus on provider obligations: building AI responsibly. But Article 26 creates a parallel set of obligations for deployers that apply even when you’re using a vendor’s AI, not your own.
For SaaS-embedded agents, the implications are significant. If a SaaS product contains an AI agent that processes personal data for credit decisions, employment decisions or other Annex III use cases, the agent is high-risk and your organization, as the deployer, must meet Article 26 requirements. These include ensuring that input data is relevant and sufficiently representative (Art. 26(4)), monitoring the system’s operation in accordance with the instructions of use (Art. 26(5)) and informing the provider of any serious incident or malfunction (Art. 26(5)).
The Cloud Security Alliance’s January 2026 report confirms the direction: “AI agents will become one of the most important emerging risk factors in SaaS environments. These agents act across systems, manage non-human identities and make changes at machine speed. They do not fit neatly into traditional access models or periodic review processes.”
Full enforcement of the EU AI Act’s high-risk system rules begins August 2, 2026. Organizations using SaaS products with embedded AI agents in EU-regulated contexts have months, not years, to close this gap.
A governance framework for SaaS-embedded agents#
The gap is real. Here’s how to close it in five steps.
The average enterprise runs over 500 SaaS applications. If 40% embed AI agents (Gartner’s 2026 prediction), that’s 200 agents operating in your environment that were never registered, classified or certified by your governance team. Each one may be processing customer data, making decisions and taking actions, all outside your governance perimeter.
Step 1: Discover#
Audit your SaaS stack for embedded AI capabilities. For each application in your SaaS portfolio, answer four questions: What AI features does this application offer? Which are currently enabled in our environment? What data do they access? What actions can they take?
Start with your Tier 1 SaaS applications: the ones that process customer data, financial data, employee data or health data. These are the applications where embedded AI agents carry the highest risk. Build a supplementary registry of SaaS-embedded agents alongside your primary agent registry. The registry entry should include the SaaS application name, the AI feature name, its enabled/disabled status, the data it accesses, the actions it can take and the admin who enabled it.
For many organizations, the discovery audit will be the first time anyone has a complete picture of the AI agents operating in their environment.
Step 2: Classify#
Apply the same three-dimension risk classification to SaaS-embedded agents as you would to agents you build yourself. Data sensitivity is determined by the data in that SaaS system. Decision authority is determined by what the embedded agent can do (recommend vs. act). Blast radius is determined by who is affected (internal users vs. customers).
The classification may reveal that SaaS-embedded agents are higher-risk than agents you built, because SaaS applications often contain your most sensitive data (CRM, HRIS, financial systems) and embedded agents may have broader access than a purpose-built agent you’d scope narrowly.
Step 3: Negotiate#
Work with your SaaS vendors to get the information your governance framework requires. Six questions to add to your vendor review process:
What model powers the AI agent? Which LLM or ML model, which version and how are updates communicated?
Where is data processed and stored? Does data leave the vendor’s infrastructure? Is it sent to a third-party model provider? Does it cross data residency boundaries?
Is data used for training? Can you opt out? Is the opt-out verified and auditable?
What controls exist for disabling or restricting the agent? Can you disable the AI feature at the admin level? Can you restrict which users can access it? Can you limit which data it can process?
What audit logs are available? Can you export logs of the AI agent’s actions, decisions and data access? In what format? At what granularity?
What notification process exists for AI feature changes? Will the vendor notify you before enabling new AI features, changing the underlying model or modifying the agent’s data access scope?
Add these requirements to your vendor contracts and MSAs. For existing contracts, schedule a governance review with your vendor’s security team.
Step 4: Monitor#
For high-risk SaaS-embedded agents (Tier 3-4 based on your classification), implement monitoring at the boundaries. You may not control the agent’s internals, but you can monitor what goes in and what comes out.
This means API log monitoring (what requests the AI features issue), data flow monitoring (what data the AI features process), integration audit trails (what OAuth tokens and API connections the AI features use) and user activity monitoring (which employees interact with AI features, plus what actions result).
Connect this boundary monitoring to your existing guardian agent infrastructure. SaaS-embedded agents that interact with your systems via API can be monitored at the API layer. Agents that operate entirely within the SaaS environment require vendor-provided audit logs.
Step 5: Enforce#
Establish a policy that all SaaS-embedded AI features classified as Tier 3 or higher require explicit enablement approval from the governance team. The default state should be off, not on. This means working with your IT team to ensure that new AI features shipped by SaaS vendors are not automatically enabled and that existing AI features enabled without governance review are identified and assessed.
Include SaaS AI governance in your procurement process for new vendors. Before approving a new SaaS application, assess: what AI features does it include or plan to include? Does the vendor’s contract support the six governance requirements from Step 3? Can the AI features be disabled if they don’t pass classification?
Download: SaaS AI audit checklist
A printable checklist for auditing your SaaS stack for embedded AI agents. Includes the four-question discovery template, the six vendor review questions, the classification scoring rubric adapted for SaaS-embedded agents and a contract amendment template for AI governance clauses.
The invisible agent estate#
The agents you build are the ones you govern. The agents your vendors ship are the ones you don’t. And the vendors are shipping fast. 40% of enterprise applications will have embedded AI agents by end of 2026, according to Gartner.
The governance framework for SaaS-embedded agents is the same framework you use for agents you build (discovery, classification, certification, monitoring, enforcement) but applied at the vendor boundary rather than the engineering boundary. The five-step model gives you the process. The contract layer gives you the negotiating position. The EU AI Act’s deployer obligations give you the urgency.
Start with the audit. Identify which SaaS applications in your stack have AI features enabled. Classify them. And bring them into the same governance regime as every other agent in your organization. The alternative is discovering at your next audit that 200 agents were processing your customer data without classification, certification or oversight and that you were the deployer responsible for all of them.
Sources and further reading#
More in governance
The lethal trifecta: governing the three capabilities you can't remove
Five days in January 2026, four AI productivity tools shipped indirect prompt injection vulnerabilities. Same pattern in every case. Simon Willison named it in June 2025: private data access plus untrusted content plus external communication equals data exfiltration. You can't remove any leg without breaking the agent. Governance has to shift from prevention to containment.
David Baum The confused deputy problem: lessons from Meta's AI agent Sev-1
On March 18 2026, a Meta AI agent exposed restricted company and user data for two hours. The credentials were valid. The governance was not.
David Baum Guardian agents: when AI governs AI
Humans can't watch every agent, every action, every second. Guardian agents (dedicated policy engines that monitor, audit and enforce governance on other agents at runtime) resolve the tension between machine-speed execution and meaningful oversight.
David Baum