Shadow AI Inside Approved SaaS: How Agents Inherit Access

Updated October 8, 2026: added a corrections log and a note on how to read the sources. October 5: repositioned around vendor-embedded agents, corrected incident and EU AI Act details, and added a sources section.

What Is Shadow AI? How It Differs From Shadow IT

Security teams are still hunting for shadow AI the way we hunted shadow IT a decade ago: unapproved SaaS signups, personal ChatGPT accounts, some unfamiliar domain lighting up the CASB logs like it's 2015 again. That model was incomplete back then. In 2026 it's actively misleading.

The highest-privilege AI agents running in your environment right now didn't get smuggled in by some rogue engineer with a personal API key. Nobody smuggled anything. They shipped as a feature toggle inside a platform your security team approved years ago, and inherited that platform's access without a single person re-reviewing what it means to hand OAuth scope to something that now acts, instead of just storing data.

Call it BYOA. Bring-your-own-agent. Not an employee downloading a rogue tool, but a vendor quietly flipping on agentic behavior somewhere deep in a stack you already trust and already signed off on three procurement cycles ago.

Gartner forecasts that the average Fortune 500 company will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. That figure counts all agents, not only vendor-embedded ones, so it does not prove this thesis on its own. An earlier Gartner forecast comes closer: 40% of enterprise applications will include task-specific agents by the end of 2026, up from under 5% in 2025. My inference is that much of that growth will arrive as capability bundled with a changelog nobody read.

BYOA vs Vendor-Embedded Agents: Same Acronym, Different Risk

BYOA gets used for two opposite things. In some security writing it means employees building or deploying their own agents outside central review. In enterprise software it can mean the sanctioned version: a platform that lets you plug in an agent you chose.

This article is about a third case that gets less attention: the vendor brings the agent. It arrives as a feature inside a platform you already approved and inherits access you already granted. No employee installs anything, so neither definition describes it. I use BYOA as shorthand for the risk and "vendor-embedded agent" for the thing itself.

How Embedded AI Agents Inherit Access: The Five-Link Chain

Here's how an agent actually does anything, per Clutch Security's "Agent Lineage" model: a person stands up or invokes the agent, the agent picks a tool, the tool authenticates with some identity, and that identity touches a resource. That's five links, and Clutch's argument is that no single tool in a typical security stack sees more than one of them. Clutch sells identity security, so read that as a vendor's framing.

Vendor updateA vendor turns on an AI feature inside a platform you already approved.
Credential inheritanceThe agent acts under the existing OAuth grant or service account.
Data exposureIt can read whatever that grant reaches: documents, records, mail.
Injection vectorUntrusted content such as an email, ticket, or shared doc carries instructions.
Autonomous actionThe agent exports data or calls APIs without a human in the loop.
Detection blind spotEDR and CASB see a legitimate session, so nothing alerts.
ImpactData exfiltration or a compliance breach.

Risk progression for a vendor-embedded agent: from a feature update to data exfiltration Original diagram by Ashutosh Mahapatra, based on the incidents and sources cited in this article.

Your EDR sees the process. Your CASB sees the session. The actual reasoning step (the part where the agent decides what "helpful" means in response to input it was never supposed to trust) happens in the gap between tools you already own. None of them are pointed at that gap.

Which means the failure mode isn't "attacker breaks in." It's "authorized system does something nobody authorized." An agent with valid credentials, wandering outside its intended scope, doesn't trip a single wire built to catch intruders, because it isn't one.

A Cloud Security Alliance study published in April 2026 (commissioned by Zenity; 445 IT and security professionals surveyed in late 2025) found that 53% of organizations had seen AI agents exceed their intended permissions at least occasionally, and only 8% said it had never happened. It is a sponsored survey, not a measurement, but the direction is hard to dismiss. If you have no log that would show it happening, you can't tell which group you're in.

An Illustrative Scenario

Composite scenario built from patterns documented across the CVEs and reports cited in this piece, not a specific client engagement.

Late last year, a mid-sized healthcare logistics company brought in a security team to figure out why their SIEM was flagging an unusual pattern of API calls against their scheduling platform: nothing that looked like an intrusion, just a steady, low-volume trickle of write operations against a customer records table that historically only saw reads. The source turned out to be a route-optimization vendor the company had used for three years, one that had quietly shipped an "AI dispatch assistant" update six months earlier. The assistant had been given permission, by default, to reschedule deliveries autonomously when it detected conflicts, which meant it now had write access to a table containing patient delivery windows and partial addresses, under an OAuth grant the company's team had approved back when the integration only needed read access to a routing API. Nobody on the company's side had re-reviewed the scope. Nobody on the vendor's side had flagged that the update changed the trust boundary. The token was still valid, still narrowly named something like "logistics-sync-prod," and still sailing straight through every access review because it predated the capability it was now being used for.

What actually resolved it wasn't a security control catching the behavior. It was a sharp-eyed analyst noticing that write volume against that table had roughly tripled month over month with no corresponding change request on file, and pulling the thread from there. The team ended up building a short-lived credential rotation into the integration, splitting the scheduling read/write paths into separate service accounts, and pushing the vendor to expose an audit endpoint for agent-initiated changes, which took two contract cycles to land. The part worth remembering is how ordinary the whole thing looked in the logs the entire time. There was no alert threshold that would have caught it on day one, because nothing about the traffic was anomalous in the way the tooling was built to detect anomalies. It just quietly became a different kind of system than the one the company had signed off on.

"EDR/XDR tools assume the threat is an unauthorized entity. AI agents are authorized insiders. The detection model breaks on contact." Manifold Security blog, "Why Your EDR Can't See What AI Agents Do" (2026)

EchoLeak: What a Real Prompt Injection Case Proves

CVE-2025-32711, better known as EchoLeak per the Aim Security researchers who found it, carries a CVSS score of 9.3, and Aim Security describes it as the first known zero-click attack on a major AI application. The mechanism is the part worth understanding, not the score. You can read the full technical record in the CVE-2025-32711 entry.

A single crafted email did it, with no click required. Aim Security's researchers showed that Microsoft 365 Copilot could be made to pull data from its own context (mail, files, chats) and send it out through trusted Microsoft URLs. Microsoft fixed it server-side before disclosure, and there is no public evidence of exploitation in the wild. The payload slipped past Microsoft's prompt-injection classifier by avoiding the language that classifier was trained to catch, then rode in through Copilot's own retrieval pipeline: the exact mechanism the assistant uses to be useful in the first place.

Worth getting right before you brief anyone on this: Microsoft patched it server-side before public disclosure, and there's no confirmed case of it hitting a real target. EchoLeak proves the attack class works: indirect prompt injection can beat a purpose-built classifier with zero user interaction. It isn't evidence anyone got breached.

The operational lesson survives that correction anyway. Any RAG-based assistant ingesting content a user didn't choose to trust (an inbound email, a shared file, a support ticket) has to treat that content as untrusted input, not instructions. Scoping what the agent can reach before it starts reasoning is the actual defense.

OAuth Privilege Escalation in AI Agents: Drift, Vercel, and MCP

Salesloft Drift is the clearest OAuth privilege-escalation story from the past year. In August 2025, a threat actor tracked as UNC6395 used stolen OAuth and refresh tokens issued to Drift's Salesforce integration and pulled data from Salesforce instances; Google's Threat Intelligence Group counted more than 700 potentially affected organizations, including Cloudflare, Palo Alto Networks, Zscaler, and Proofpoint. Mandiant's investigation into UNC6395, published jointly with Google's Threat Intelligence Group, traced it back to Salesloft's own GitHub environment getting breached months earlier.

To be clear about what this wasn't: no autonomous agent decided on its own to misbehave. A human threat actor abused stolen credentials, full stop. But those credentials existed at that scope specifically because Drift's chat integration needed broad standing access to Salesforce objects to support its automated features. Take away "AI chatbot needs to read and write Salesforce data" as a use case, and there's no reason that scope exists at all. The blast radius was inherited, not created. That's the pattern showing up in the incidents covered here.

One layer down, inside a widely used client-side proxy, CVE-2025-6514 (CVSS 9.6) is a command injection vulnerability in mcp-remote, the proxy that lets clients like Claude Desktop, Cursor, and Windsurf talk to remote MCP servers. A malicious server responds to the connection handshake with a crafted authorization_endpoint URL, the client tries to open it, and arbitrary OS command execution follows. No stolen password required. It does need the user to connect to an untrusted MCP server, so it is a tool-trust failure rather than inherited OAuth scope. Versions 0.0.5 through 0.1.15 were affected. The vulnerability sits inside the trust-establishment step itself, which is a nastier place for a bug to live than almost anywhere else in the stack.

Vercel–Context.ai, from April 2026, is worth including with a caveat. Context.ai said it detected unauthorized access to its AWS environment in March 2026 and later learned that OAuth tokens belonging to some of its users had been compromised. One of those tokens was used to reach a Vercel employee's Google Workspace account. According to Context.ai, that employee had signed up with a corporate account and enabled "Allow All" on the requested permissions. Vercel was not a Context.ai customer, so this was an employee-adopted tool, not a vendor-embedded one. Per Vercel's bulletin, the attacker took over that account and reached some environments and environment variables not marked "sensitive". Strip the AI framing off this one and what's left is an infostealer plus an over-permissioned OAuth grant, the same failure mode security teams have been fighting since consent screens existed.

Platform defaults are tightening, but only for new consent requests. Microsoft's managed default consent policy now requires admin approval for more Graph permissions (message center item MC1304287), yet it doesn't revoke grants that already exist. A vendor's inherited scope from years ago stays exactly as it was.

Shadow AI Compliance: GDPR, SOC 2, ISO 27001, and the EU AI Act

When an embedded agent inside an approved platform processes personal data, which framework governs it, and who actually signed off on the legal basis? Worth putting to your compliance lead directly, because one unregistered agent can implicate several frameworks at once, and I don't think most orgs have mapped that out yet.

SOC 2 is the more straightforward one from where I sit. The criteria don't name agents, but an agent that touches in-scope systems should fall under the same logical access (CC6), system operations (CC7), and change management (CC8) controls as any other component. An agent with no owner and no access review is the kind of gap that can surface as an exception; whether it does depends on how your controls are worded and on your auditor's judgment. ISO 27001:2022 Annex A.5.9 expects an inventory of information and other associated assets with named owners, so an unregistered agent that handles in-scope information is an inventory gap even in a certified ISMS.

GDPR is where I'll admit I'm out of my depth a little. I'm not a lawyer, but reading Article 28 against how these platforms actually work, it requires a data processing agreement with any processor handling personal data. Most enterprise contracts with SaaS vendors were signed before those vendors' products could act autonomously. Your existing DPAs almost certainly don't contemplate an embedded agent as its own distinct processing operation. The legal basis regulators expect to find may not exist anywhere in your vendor stack, not because anyone was careless, but because the contract predates the capability by years. Get real counsel on this rather than a security engineer's read of it.

Regulators don't need AI-specific case law to come after you for this, either. Ireland's DPC fined TikTok roughly €530 million in May 2025 over unlawful international data transfers. That case has nothing to do with agents, but it shows how large ordinary GDPR enforcement already runs before AI even enters the picture. A narrower problem is my own observation, not a regulator's finding: agent memory is where compliance drift can hide, because it's often unclear what an agent retained, where, or for how long.

On the AI Act timeline, it's worth getting this right before you repeat it in a boardroom, because the date moved. August 2, 2026 was originally when high-risk obligations under Annex III would become enforceable, with penalties up to €15 million or 3% of global turnover. The EU's Digital Omnibus (Regulation (EU) 2026/1744, published July 24, 2026) pushed that deadline to December 2, 2027 for stand-alone Annex III systems, and to August 2, 2028 for high-risk AI embedded in regulated products. What didn't move: the Article 4 AI literacy duty, already in force since February 2025 (the Omnibus softened it into a duty to support AI literacy), and most Article 50 transparency obligations, which stayed on the original August 2026 track, with a grace period to December 2, 2026 for machine-readable marking on systems already on the market. GDPR and the AI Act sit under separate authorities with separate maximums, and nothing stops both applying to the same incident. There's no combined ceiling to hide behind.

Dimension	Traditional Shadow IT (2019)	Shadow AI / BYOA (2026)	Risk Delta
Discovery method	Expense reports, CASB domain scans, browser proxy logs	No new domain, no new vendor, no expense line: the capability ships inside a platform already approved	Discovery mechanism no longer exists
Access model	New account, isolated from core systems	Inherits existing OAuth scope from an already-approved integration	Blast radius inherited, not created
Remediation	Block the domain, revoke the account	Requires renegotiating a vendor contract or disabling a core business feature	Remediation cost and friction both increase sharply
Human involvement	A person clicks, uploads, or logs in each time	Agent acts across multiple steps without a human trigger	Action volume outpaces human review capacity
Regulatory trigger	Typically requires a confirmed breach	Transparency and transfer duties can be breached with no incident at all (the DPC's TikTok decision is an example)	Liability exists before any breach occurs
Compliance timeline	Governed by static, well-understood rules	Governed by a moving target: Annex III now lands Dec 2027, Article 50 stayed on Aug 2026	Two live deadlines to track, not one

How to Secure AI Agents: A Governance Framework

You can't ban what already lives inside a contract you already signed. Governance has to shift from blocking tools to instrumenting behavior.

Discover

Inventory all API connections
Detect unauthorized OAuth grants
Map agent permissions to data sources

Suggested target: 100% of AI agents and OAuth grants inventoried

Control

Apply least-privilege scoping
Revoke over-permissioned tokens
Implement agent identity management

Suggested target: high-risk access revoked within 24 hours

Monitor

Continuous behavioral audit logging
Anomaly detection on agent API calls
Automated compliance reporting

Suggested target: over 95% of anomalous calls triaged within 15 minutes

Governance control loop: discover every connection, control every permission, monitor every behavior Original framework by Ashutosh Mahapatra. The targets are suggested starting points, not industry benchmarks.

Inventory and Discovery

Stop treating the inventory as finished. A point-in-time audit is stale within weeks at the rate vendors ship agentic features now.

Require any business unit activating a new agentic feature to self-declare it within five business days, routed through the change-management process you already run. Correlate OAuth token and API activity through your SIEM to catch agents calling systems they were never explicitly provisioned to reach. And give every entry, at minimum, an owner, a stated purpose, the data and tools it can touch, and a risk tier.

Least-Privilege Access for AI

Treat every agent as its own identity, not a shared credential. The anti-pattern behind both OAuth incidents above is standing access granted once and never revisited.

Drop "prompt-based" guardrails as a control layer entirely. A prompt is advice, not an access control. If your architecture treats it like one, what you have is a suggestion, not a boundary.

Issue short-lived, narrowly scoped credentials pulled from a secrets manager on demand, and separate read from write by default. Require step-up human approval before any agent takes an action that's destructive or externally visible: before it can issue a refund, not just look up an order.

"The fastest way to create long-term risk is granting broad Owner/Admin roles to unblock a pilot, then never coming back to refactor permissions once the workflow 'works.'" Microsoft Security Blog, "Least privilege for AI agents" (July 16, 2026)

Continuous Behavioral Audit Logging

Log at the decision layer, not just the API layer: agent identity, human operator, millisecond timestamp, action and target, outcome, and which policy version authorized it.

Make it append-only and tamper-evident. A compromised or misaligned agent shouldn't be able to edit its own history.

Article 26 of the EU AI Act requires deployers of high-risk systems to keep logs for at least six months, which for Annex III systems now starts in December 2027. SOC 2 sets no fixed retention period, so size retention to your audit period and investigation needs; twelve months is a common design choice, not a requirement. Budget for the volume now, too. A few thousand agent sessions a day already generates audit data that outpaces what most SIEM pipelines were sized for, and that's not something you want to discover mid-incident.

All three of these exist for one reason. When someone asks "which agent touched this record, and why," that needs to be a five-minute lookup, not a forensic project that eats your week and ends with "we think."

Key Takeaways for Security Leaders

None of this means agentic features are a mistake. They're not going away. Gartner's 150,000-agent number for 2028 is as much a demand signal as it is a warning, and pretending otherwise is a good way to end up irrelevant to the roadmap conversations that actually matter.

But the agents worth losing sleep over right now aren't the ones some employee snuck past you. They're sitting inside contracts you already signed, waiting for a vendor to ship the next update, and nobody's going to email you before that happens. The teams getting ahead of this aren't trying to ban agentic tools. That fight was lost before it started. They're the ones instrumenting behavior now, while they're running dozens of agents, so that running thousands doesn't land as a surprise at 2 AM.

Need security or AI-governance articles that rank, get cited, and hold up to a practitioner’s read? read? Get a free Article Check.

Sources and Verification

How to read these sources

Three kinds of source sit side by side: primary records (the NVD entry, the GitHub advisory, Vercel’s bulletin, EUR-Lex, Microsoft documentation), vendor and analyst material (Gartner, the Zenity-commissioned Cloud Security Alliance survey, Clutch, Manifold, JFrog), and news coverage (The Hacker News, Dark Reading, Tom’s Hardware). Vendor claims are labelled as such, and forecasts are forecasts.

Incident descriptions stay within what the sources state. There is no public evidence that EchoLeak was exploited in the wild, and the Vercel incident involved an employee-adopted tool, not a vendor-embedded one.

Also relied on: the Irish DPC's May 2025 TikTok decision. Last checked October 5, 2026.

Corrections and updates

October 8, 2026: Added this corrections log, a note on how to read the sources, a how-this-was-made line and a dedicated share image. Updated the author and organization markup.
October 5, 2026: Repositioned the piece around vendor-embedded agents. Corrected the EchoLeak description (server-side fix, no known exploitation), attributed the 700+ Drift figure to Google’s Threat Intelligence Group, and rewrote the Vercel account to match Vercel’s bulletin and Context.ai’s statement. Corrected Clutch’s model from four links to five, clarified that Gartner’s 150,000-agent figure counts all agents, and noted the Zenity sponsorship of the Cloud Security Alliance survey. Softened the SOC 2 and ISO 27001 wording, dated the TikTok decision to May 2025, and updated the EU AI Act dates for the Digital Omnibus.
August 19, 2026: Published.

Shadow AI & BYOA: FAQ

What is shadow AI?

Shadow AI is the use of AI tools, models, or autonomous agents within an organization without formal review, approval, or oversight from security or IT teams. In 2026, the more consequential form isn't a personal ChatGPT account: it's an agentic feature a SaaS vendor enables inside a platform already approved, inheriting existing access without a new review.

What is BYOA, and is it the same as shadow AI?

BYOA (bring your own agent) is used two ways: employees deploying their own agents outside central review, or a sanctioned setup where a platform accepts an agent you choose. Neither describes the case this article covers, where the vendor ships the agent inside a platform you already approved. That case is shadow AI without a new app: no new vendor, no new login, and access inherited from an existing grant.

What are the biggest AI agent security risks?

The two highest-impact AI agent security risks are indirect prompt injection through untrusted data sources and OAuth-based privilege escalation from inherited integration access. Neither typically triggers signature-based detection, because the agent is acting with legitimate, already-granted credentials, which is what your EDR is built to trust.

How do you detect shadow AI inside approved SaaS apps?

Monitor vendor release notes and admin consoles for new AI features, review OAuth grants and the scopes behind them on a schedule, and correlate token and API activity in your SIEM. SaaS security posture and AI-SPM tools aim to cover this, because embedded agents usually don't create a new domain or login for discovery tools to find.

How do you secure an AI agent?

Securing an AI agent means treating it as its own identity with short-lived, narrowly scoped credentials, mandatory human approval for high-risk actions, and tamper-evident logging at the decision layer. A prompt telling the model to behave is not an access control: it's a suggestion an architecture shouldn't rely on.

Was EchoLeak exploited in the wild?

There is no public evidence that it was. Aim Security reported CVE-2025-32711 (CVSS 9.3) to Microsoft, and Microsoft fixed it server-side before disclosure, so customers did not need to patch.

When do the EU AI Act high-risk obligations apply now?

Under the Digital Omnibus (Regulation (EU) 2026/1744), obligations for stand-alone Annex III high-risk systems now apply from December 2, 2027, and for high-risk AI embedded in regulated products from August 2, 2028. Most Article 50 transparency obligations stayed on the August 2026 track.

Ashutosh Mahapatra

Founder, Ashutosh Writes · SEO, GEO & AEO articles for fintech & AI security

Ashutosh Mahapatra is the Bhubaneswar-based founder of Ashutosh Writes, which writes source-verified articles for fintech and AI-security teams, including security and AI-governance topics where claims have to survive a practitioner’s scrutiny. His research draws directly from primary sources (CVE databases, vendor security disclosures, and regulatory filings), and every claim ships with its limits stated.

Author page · Our services · ashutosh@ashutoshwrites.in

Need security or AI-governance articles that rank, get cited, and hold up to a practitioner’s scrutiny, not just a search engine’s? This piece is a self-initiated sample of how we write: primary-source research, answer-first structure and schema that mirrors the visible article. Send us one article. We check every claim in it and test whether AI engines cite it.

Get a free Article Check · ashutosh@ashutoshwrites.in