---
title: "Governing SaaS-embedded AI agents: the governance gap you didn't know you had"
date: 2026-04-10
author: david
excerpt: "Gartner predicts 40% of enterprise applications will embed AI agents by end of 2026. These agents process your data and take actions in your systems, but sit outside your governance framework because your vendor deployed them, not you."
category: governance
tags: [saas, shadow-ai, governance, eu-ai-act, vendor-risk, ai-agents]
draft: false
tldr: "SaaS vendors are shipping AI agents into your stack as feature updates: Salesforce Agentforce, HubSpot Breeze, Zendesk AI, Microsoft Copilot agents. These agents create five governance gaps: discovery, classification, data flow opacity, configuration drift and shared responsibility confusion. Under the EU AI Act, you are the deployer and carry compliance obligations regardless of who built the agent."
seo:
  title: "Governing SaaS-embedded AI agents: the governance gap | Roval"
  description: "How to discover, classify and govern the AI agents your SaaS vendors ship into your stack. Five gaps and a five-step framework to close them."
faqs:
  - question: "What are SaaS-embedded AI agents?"
    answer: "AI agents that your SaaS vendor ships as a feature of their product, not agents your team built and deployed. Examples include Salesforce Agentforce, HubSpot Breeze, Zendesk AI agents and Microsoft 365 Copilot agents. These agents process your data, make decisions and take actions inside your business systems, but they were never registered, classified or certified by your governance team."
  - question: "How do I find out which SaaS tools have AI agents?"
    answer: "Start with a discovery audit of your SaaS portfolio. For each application, check the vendor's product documentation for AI features, review your admin console for AI feature toggles and ask your vendor's security team directly. Focus first on SaaS applications that process sensitive data: CRM, HRIS, financial systems, customer support platforms."
  - question: "Am I responsible for AI agents my SaaS vendor deployed?"
    answer: "Yes. Under the EU AI Act (Article 26), deployers of high-risk AI systems have compliance obligations regardless of who built the system. If a SaaS product contains an AI agent that qualifies as high-risk and your organization uses it, you are the deployer. This means you must monitor the system's operation, ensure data quality and report serious incidents, even though you didn't build the agent."
  - question: "How do I classify SaaS-embedded agents?"
    answer: "The same way you classify agents you build: score across three dimensions (data sensitivity, decision authority, blast radius) and compute a composite risk tier. The key difference is that the information needed for scoring may come from vendor documentation rather than your own engineering team. If the vendor can't provide sufficient information for classification, treat the agent as Tier 3 (High) by default until assessed."
  - question: "What should I add to vendor contracts?"
    answer: "Six clauses: AI feature change notification, data processing transparency, opt-out of training data usage, disable/restrict capability, audit log access and incident response for AI-related issues. For existing contracts, schedule a governance review with the vendor's security team."
  - question: "Where does Roval fit?"
    answer: "Roval's agent registry supports both agents you build and SaaS-embedded agents. Register SaaS-embedded agents with their vendor, feature name, data access scope and enabled status. Classify them using the same three-dimension model. Certify them against the same compliance frameworks. Monitor for drift, including vendor-initiated model updates. The registry becomes the single system of record for your entire agent estate, regardless of where each agent was built."
---

## 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.

:::fact{title="Shadow AI is already here"}
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](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) 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](https://www.bettercloud.com/monitor/saas-industry/), only 22% of enterprises prioritized AI governance policy in 2025. The average enterprise runs over 500 SaaS applications ([CloudEagle](https://www.cloudeagle.ai/blogs/ai-saas-security-breaches-2025-prepare-2026)). 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](/research/blog/why-ai-agents-need-a-cmdb) doesn't know they exist because they were never registered. They arrived as a SaaS feature, not as an agent deployment.

:::cite{name="Hasan Imam" title="CEO, Obsidian Security" avatar="/images/experts/hasan-imam.jpg" linkedin="https://linkedin.com/in/hasanimam"}
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](https://www.obsidiansecurity.com/blog/shadow-ai-in-saas) 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](/solutions/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.

![Obsidian Security: Shadow AI in SaaS](/images/blog/obsidian-shadow-ai-saas.png)

### Gap 2: Classification

You can't classify what you can't see. Your [three-dimension risk classification](/research/blog/ai-agent-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.

<figure><div style="position:relative;padding-bottom:56.25%;height:0;overflow:hidden;border-radius:8px;border:1px solid var(--border)"><iframe src="https://www.youtube.com/embed/5fJ6u--GkSk" title="Securing Agentic AI Systems and Multi-Agent Workflows" style="position:absolute;top:0;left:0;width:100%;height:100%;border:0" allow="accelerometer;autoplay;clipboard-write;encrypted-media;gyroscope;picture-in-picture" allowfullscreen loading="lazy"></iframe></div><figcaption>Securing Agentic AI Systems and Multi-Agent Workflows | <a href="https://www.youtube.com/watch?v=5fJ6u--GkSk" target="_blank" rel="noopener">YouTube</a></figcaption></figure>

### 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](/research/blog/agent-drift-continuous-compliance) 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.

:::cite{name="Jens Eriksvik" title="CEO, Algorithma" avatar="/images/experts/jens-eriksvik.jpg" linkedin="https://linkedin.com/in/ekbergjens"}
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](https://medium.com/@jens.eriksvik/predictions-for-2026-the-post-saas-reality-of-enterprise-ai-80c3dba33ee9) 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](https://www.obsidiansecurity.com/blog/shadow-ai-in-saas) "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.

:::fact{title="The deployer problem under the EU AI Act"}
[Article 26 of the EU AI Act](https://artificialintelligenceact.eu/article/26/) 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](https://cloudsecurityalliance.org/blog/2026/01/29/why-saas-and-ai-security-will-look-v%65ry-different-in-2026) 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."

![Cloud Security Alliance report on SaaS and AI security in 2026](/images/blog/csa-saas-ai-security-2026.png)

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.

:::fact{title="200 agents you may not know about"}
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](/platform/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](/research/blog/ai-agent-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](/platform/llm-monitoring). 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](/research/blog/guardian-agents) 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.
>
> [Download the checklist (PDF) →](#)

## 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](/solutions/agent-inventory), classification, [certification](/platform/compliance), 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.

:::cta{title="See Roval in action" description="Book a 15-minute walkthrough of the agent registry, compliance certification and LLM monitoring." cta="Book a demo" href="/demo"}
:::

## Sources and further reading

| Source | URL |
|--------|-----|
| Gartner, "40% of Enterprise Apps Will Feature AI Agents by 2026" (Aug 2025) | https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025 |
| BetterCloud, "AI and the SaaS Industry in 2026" (Jan 2026) | https://www.bettercloud.com/monitor/saas-industry/ |
| CloudEagle, "AI & SaaS Security Breaches" (Feb 2026) | https://www.cloudeagle.ai/blogs/ai-saas-security-breaches-2025-prepare-2026 |
| Komprise / CIO.com, "Shadow AI: The Hidden Agents Beyond Traditional Governance" (Nov 2025) | https://www.cio.com/article/4083473/shadow-ai-the-hidden-agents-beyond-traditional-governance.html |
| Vectra AI, "Shadow AI Explained" (Feb 2026) | https://www.vectra.ai/topics/shadow-ai |
| Obsidian Security, "Shadow AI in SaaS" (Mar 2026) | https://www.obsidiansecurity.com/blog/shadow-ai-in-saas |
| Eriksvik, "Predictions for 2026: The Post-SaaS Reality of Enterprise AI" (Dec 2025) | https://medium.com/@jens.eriksvik/predictions-for-2026-the-post-saas-reality-of-enterprise-ai-80c3dba33ee9 |
| Cloud Security Alliance, "Why SaaS and AI security will look different in 2026" (Jan 2026) | https://cloudsecurityalliance.org/blog/2026/01/29/why-saas-and-ai-security-will-look-v%65ry-different-in-2026 |
| EU AI Act, Article 26 (Deployer Obligations) | https://artificialintelligenceact.eu/article/26/ |
| Deloitte, AI ROI in the Nordics (2026) | https://www.deloitte.com/no/no/issues/generative-ai/ai-roi-in-the-nordics.html |
