Security teams spent the last year putting guardrails around the AI they selected. Copilot policies. Agent catalogs. Prompt filters. You treated chosen models like a new identity class, and that feels like mature cybersecurity. The 2026 State of Agent Security Report should puncture that comfort. In the environments studied, roughly 1,280 third-party products now embed AI. About 282 of them sit behind single sign-on. The other thousand never authenticate through your identity stack at all.

You assumed a purchase order plus an IdP connector meant the product’s new assistant lived inside the same control plane as your users. Most of those assistants talk to someone else’s cloud, with a vendor-issued key, using the privileges of whatever seat already exists. Your SSO never meets them.

You Audited Copilots and Ignored the SKU List

The popular reaction to agent risk has been to catalog the bots you stood up. Shadow chat on a developer laptop. An internal retrieval service. A helpdesk copilot wired to the ticket tool. That work is real. It also maps onto last year’s identity playbook: register the app, bind a service principal, watch the logs. You can put a name on those actors. You can disable them.

The report’s ugly ratio is the gap between products that embed AI and products that present that AI to your IdP. Two hundred eighty-two behind SSO. One in five, if you like round numbers. The rest are features inside tools finance already pays for. CRM summarizers. Contract clause finders. Meeting notetakers. Code-review helpers that shipped in a minor release nobody ticketed. Procurement signed a renewal. Product added a model call. Nobody opened a risk register.

Vendors did not need to hide anything. They added inference behind an existing session cookie. Your identity team never got a change request because, from the vendor’s point of view, the user already logged in. The agent is a backend hop. It inherits the user’s data scope, then talks to a model the vendor operates. There is no SAML assertion for that hop. There is no SCIM object named Weekly Report Writer. There is a checkbox in a tenant admin page that still belongs to the business owner who wanted prettier summaries.

If your SSO catalog is the system of record for what can act, you have a fleet of acting components that will never appear there. Call it an inventory failure and you are closer to the truth than any model-safety slide deck. Chosen AI is the minority. Paid, embedded, unauthenticated-to-you AI is the default.

Cybersecurity That Stops at Login Leaves Agents Ungoverned

Identity infrastructure is honest about its job. It governs principals that show up. Users. Service accounts. OAuth apps you registered. Agents that never present a credential to you sit outside that job description. You can keep pouring budget into threat-protection for the edge and still miss a licensed feature that reads the customer table every Monday morning.

Defense in depth still earns its keep on the paths you actually instrument. A firewall that allows SaaS HTTPS is doing what you configured when the CRM’s agent fetches a record set and posts it to a model endpoint the vendor owns. The session is valid. The destination lives in a vendor ASN your proxy already trusts. Threat detection tuned for brute-force noise on VPN and RDP will not notice a feature flag. Malware signatures have nothing to bind to. The traffic looks like the product you paid for, because it is.

North-south controls still trust the path you already allow

Walk the hops. The user authenticates to the SaaS app through SSO. Fine. The app’s server then calls a model API with a vendor credential you cannot rotate, revoke, or put in your PAM vault. That second hop is where data leaves the tenancy you think you understand. Browser DLP might catch a paste into a public chatbot. It often misses a server-side extraction that never returns to the laptop. Your CASB label for “this app is sanctioned” becomes a permission slip for a new processor you did not review.

Cyber security programs that equate “in the SSO catalog” with “under control” will file the gap as accepted residual risk. The residual is most of the fleet. Security hardening on the IdP (phishing-resistant MFA, token binding, tight OAuth consent) is still worth doing. It does not constrain a vendor-side worker that never asks your IdP for a token.

Incident response gets uglier from the same blind spot. If you need to find out whether an embedded agent dumped contracts into a vendor model, your first instinct is IdP logs. Those logs will show a normal user session. The agent will not have an actor ID of its own. You reconstruct from SaaS audit exports, if the vendor kept them, if your contract lets you have them, if anyone knew to pull them on day one. Plenty of IR shops still cannot answer a simple question: which licensed feature called which model with which records, and who in the business turned it on.

Treat Every Embedded Agent as an Unmanaged Identity

Stop waiting for a vendor to wrap every new assistant in SAML. You can shrink this without buying another dashboard. Work the catalog you already own: contracts, admin consoles, SSO exports, and egress logs. The goal is a named owner, a disable switch, and an evidence trail for every AI feature that can read tenant data.

1. Reconcile SKUs against the IdP this week. Export every SaaS app in SSO. Pull the last twelve months of software renewals and marketplace installs. Mark every product that advertises assistants, writers, copilots, review bots, or auto-summaries. Anything in the product list and missing from SSO is an unmanaged identity until proven otherwise. Put a human name on each row.
2. Turn off what nobody can defend. In each admin console, disable AI features that have no business owner, no data-handling note, and no retention story. Revoke OAuth grants and inbound API keys that look like “assistant” or “workflow” connectors and that never appear as IdP apps. If the vendor offers a tenant-wide kill switch, use it until someone writes a use case that survives review.
3. Log the second hop. Where you proxy or inspect SaaS egress, watch for calls from sanctioned apps to model endpoints, inference hosts, and vendor AI subdomains. You will not block the internet on day one. You will get a baseline. Pair that with vendor audit logs: who enabled the feature, which objects it read, whether output left the region you think you occupy.
4. Make procurement the control plane. New AI features, even inside an existing contract, need the same bar as a new app: SSO, SCIM or equivalent lifecycle, admin audit, a documented disable path, and a data-flow diagram that includes the model host. If the vendor cannot put the agent behind your identity stack, treat it like unsanctioned processing. Renewals are leverage. Use them.
5. Tabletop the investigation you cannot currently run. Pick one high-data SaaS tool. Assume its assistant exfiltrated a customer export last Tuesday. Time how long it takes to identify the feature, the acting seat, the destination, and the records. That drill is your incident response gap, in hours. Fix the logging and the owner map until the drill completes in a shift, not a week.

Keep the boring identity work in motion after the first sweep. Least privilege on the human seats these agents inherit matters more than another prompt filter. A summarizer with a visor role reads less than one bound to a global admin. Review AI feature flags on the same cadence you review privileged groups. When a vendor finally offers SSO for the agent itself, onboard it like a new production principal, with alerts on consent, token grants, and sudden volume. That is security hardening for a class of actor your current runbooks still describe as a checkbox.

Frequently Asked Questions

If the SaaS app is already in our IdP, are its AI features covered?

The user login is covered. The agent hop usually is not. Unless the vendor issues a distinct principal for the assistant and sends it through SSO, your identity logs will only show the human session that unlocked the feature. Ask for a separate actor, or assume you are blind.

Should we block vendor model endpoints at the firewall?

Blocking without a catalog will break tools finance already renewed. Start by discovering which sanctioned apps call which inference hosts, then deny the ones with no owner and no approved use case. Egress policy is a follow-on control, not a substitute for knowing which SKU grew an agent.

Where does this belong in incident response?

Treat an embedded agent as a privileged data processor, not a malware pop. Your playbook needs vendor audit pulls, feature-flag history, and seat privilege at the moment of use. IdP success events are the start of the timeline, not the evidence of what the assistant did with the records.

Sources

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