The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn't

A Thousand Invisible Agents: The SaaS Identity Blind Spot

Enterprise security teams built an entire discipline around governing the AI they chose to adopt — model scanning, prompt-injection gateways, acceptable-use policies. None of it accounts for the AI that arrived anyway. According to The Hacker News, citing the 2026 State of Agent Security Report, roughly 1,280 third-party products in the environments studied now embed AI capabilities. Only about 282 of them sit behind single sign-on (SSO). The remaining ~1,000 are invisible to identity infrastructure by default — not because anyone hid them, but because an identity stack can only govern what authenticates through it, and most embedded agents never do.

Key Findings

Why Third-Party AI Agents Slip Through

The report's framing distinguishes three ways AI shows up inside an enterprise. Built agents are the smallest category — open frameworks running on infrastructure the organization owns, where traditional controls like code scanning and model review actually apply. Configured agents are enterprise prompts layered onto a third-party vendor's runtime. The largest group by far, though, is inherited agents: AI capability that ships inside a product update to software the company already runs, with no decision point at all.

That last category is the structural problem. Every control in the first-party AI security toolkit assumes a moment existed where someone chose the AI — a model was selected, a gateway was deployed, an adoption was accepted into policy. Inherited agents skip that moment entirely. A vendor flips on an AI feature inside a SaaS product the company has used for years, and the agent inherits whatever access the parent application already holds. It doesn't initiate its own authentication flow with the corporate identity provider, so SSO logs never see it, and neither does anything built on top of them.

The article illustrates this with Salesforce's Slack Code, launched in August 2026: a user tags a coding agent into any conversation, the agent reads the shared context, writes code, and opens a pull request — all without a separate procurement decision, license, or security review triggering anywhere in the process. This is distinct from classic shadow IT, where an employee signs up for an unsanctioned tool and at least generates a discoverable account or OAuth grant. An inherited agent generates neither; it rides in on a product the organization already approved, years before the AI feature existed.

The scale backs this up. Reco's underlying telemetry, drawn in part from analysis of 500 published Model Context Protocol (MCP) servers, found that 62% combine local file-read access with outbound network connectivity, and that half can execute shell commands on the host. Two in five hold the full combination — command execution, file access, and network egress — together. No single application owner approved that combination; each power was approved individually, if at all, and the agent assembled them on its own.

What the Report Recommends

Rather than proposing another SSO-style control point, the report argues the unit of analysis has to change. It lays out a four-part evaluation framework for any agent operating in the environment, inherited or otherwise:

• Identity — is the agent registered anywhere, and does it have a clear, named owner?
• Permissions — what access has it actually been granted, versus what it needs to do its stated job?
• Connectivity — what can it reach, directly and transitively, across connected systems?
• Activity — what does it actually do, measured against what it was supposed to do?

The report's central argument is that connectivity, not configuration, is the unit that matters — an agent's risk isn't fixed by what one application owner approved for it in isolation, but by what it can reach once combined with everything else already authorized in the environment. Evaluating that requires visibility that spans systems, which is exactly what SSO-centric identity tooling was never built to provide. The report also ties this to the EU AI Act, whose obligations are phasing in through 2026 and presume an organization can inventory its AI systems, name owners, and evidence oversight — a presumption that collapses for any enterprise that cannot first enumerate the agents it is running.

Why This Matters

1. "AI governance" and "SaaS AI governance" are not the same problem. Most enterprise AI policy was written for AI the organization deliberately adopted; the larger exposure now comes from AI quietly bundled into tools already in daily use.
2. SSO logs are not an AI inventory. With roughly four out of five AI-embedding products sitting outside SSO visibility in the studied environments, relying on identity provider logs to find "all our AI" will systematically undercount — badly.
3. Discovery has to move past identity infrastructure. CASB-style and API-based SaaS discovery, vendor changelog monitoring, and direct connectivity mapping are needed to surface agents that never generate an authentication event.
4. Permission combinations matter more than individual grants. File access, shell execution, and network egress are each routinely approved in isolation; the risk is in the agent that quietly holds all three.
5. Compliance deadlines assume an inventory that may not exist. EU AI Act obligations phasing in through 2026 require naming AI system owners and evidencing oversight — work that cannot start until the inherited-agent blind spot is closed.
6. This is a governance gap, not a vendor-trust failure. Reco's finding that ~79% of third-party apps are properly authorized shows many organizations already run mature SaaS review programs; the gap is specific to AI features bolted onto already-approved software.

Sources

• The Hacker News — The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn't
• Reco — The State of Agent Security 2026