The Third-Party Agent Problem: Why Your Identity Stack Can't See the AI Agents You Didn't Choose
When security teams inventory their AI footprint, they typically start with the tools they deliberately deployed: copilots, coding assistants, customer service bots. But a new analysis from the 2026 State of Agent Security Report reveals a far more uncomfortable reality. In the environments studied, roughly 1,280 third-party products now embed AI. Of those, only about 282 sit behind single sign-on (SSO). The remaining thousand are effectively invisible to identity infrastructure by default.
This isn't a story of malicious hiding. It's a structural blind spot. An identity stack can only govern what authenticates through it, and most embedded agents never do. They run inside vendor applications, use their own credentials, or operate as background services that never touch your IdP. The result is a growing class of "shadow agents" that your security controls were never designed to see.
Why SSO Coverage Collapses at Scale
Single sign-on is a powerful control for human users and for SaaS apps that support SAML or OIDC. But embedded AI agents frequently bypass it for three reasons:
- They authenticate as the application, not the user. When a third-party product calls an LLM or an AI service, it often uses a service account or API key. That traffic never hits your IdP.
- They run server-side. Many agents execute in the vendor's cloud, not on your endpoint. Your EDR and CASB tools may see the parent application, but not the agent's individual actions.
- They are enabled by default. Vendors increasingly ship AI features turned on, with opt-out buried in admin consoles. Security teams learn about them only after they appear in logs—if they appear at all.
The 282 SSO-integrated agents are the exception, not the rule. The other thousand represent a governance gap that widens as AI becomes a standard component of enterprise software.
The Risk Isn't Just Data Leakage
The immediate concern is data exposure: an embedded agent with access to your CRM, ticketing system, or code repository could send sensitive context to an external model. But the deeper risk is action execution. Agents don't just read—they write. They can create tickets, modify records, send emails, and trigger workflows. If those actions aren't tied to a governed identity, you lose accountability.
Consider a third-party HR platform with an AI assistant that can update employee records. If that assistant uses a shared service account, any audit log will show the application, not the agent or the user who triggered it. In an incident, you can't answer basic questions: Who authorized this? What data did it touch? Was it a human or an automated process?
This is the third-party agent problem: your security program was built for AI you chose, but the agents you didn't choose are already operating inside your environment.
Why Traditional Controls Miss Them
Most security stacks rely on a combination of SSO, CASB, DLP, and endpoint agents. Each has a blind spot here:
- SSO only covers apps that integrate. Embedded agents often don't.
- CASB focuses on sanctioned cloud services, not the AI features inside them.
- DLP inspects data flows, but agent actions may look like normal application traffic.
- EDR sees processes on endpoints, not server-side agents in vendor clouds.
The report's data suggests that for every governed AI agent, there are roughly 3.5 ungoverned ones. That ratio is likely to worsen as vendors add AI to every product tier.
Practical Steps Toward Visibility
Closing this gap requires more than buying another tool. It demands a shift in how you inventory and govern non-human identities.
- Extend discovery beyond SSO. Use network telemetry, API gateways, and cloud logs to identify AI-related endpoints and service accounts. Look for patterns like calls to known LLM APIs or unusual outbound data flows.
- Demand agent-level transparency from vendors. Ask for documentation on how embedded AI authenticates, what data it accesses, and whether actions are logged per user. Make this part of procurement.
- Treat agents as identities. Apply least privilege, rotation, and monitoring to service accounts and API keys used by third-party AI. If an agent can write, it needs the same scrutiny as a human admin.
- Centralize agent logs. Where possible, require vendors to stream agent activity to your SIEM. If they can't, consider that a risk factor.
- Assume default-on. Audit admin consoles for AI features that are enabled without your explicit consent. Disable what you don't need.
The Governance Gap Won't Close Itself
The 2026 report's headline number—1,280 embedded AI products, 282 behind SSO—is a snapshot of an immature market. Vendors are shipping AI faster than security teams can govern it. Identity infrastructure, built for a world of human users and a handful of SaaS apps, was never designed for a thousand autonomous agents running inside someone else's cloud.
That doesn't mean SSO is useless. It means SSO alone is insufficient. The organizations that get ahead of this problem will be those that treat third-party agents as first-class identities, demand visibility from vendors, and build detection for the agents they didn't choose. The alternative is a growing population of invisible actors with access to your systems and no one watching.
For security leaders, the question is no longer whether third-party AI agents are in your environment. They are. The question is whether you can see them before they act.
Source: The Hacker News
