Key takeaways
- third-party enterprise products embedding AI, only 282 route through single sign-on (SSO), leaving roughly 1,000 agents entirely invisible to identity management systems.
- Bypassing Procurement Gates: Traditional AI security controls assume a deliberate selection event, whereas the majority of agents are inherited via routine SaaS updates or configured on third-party runtimes without formal IT review.
- The Blast Radius Shift: Risk concentrates not in foundation model weights, but in agent scaffolding and transitive connectivity across CRMs, communication channels, code repositories, and production environments.
- Regulatory and Buyer Mandates: Global financial institutions like JPMorgan Chase and EU AI Act compliance obligations are forcing organizations to inventory all active agents, designate human owners, and enforce zero default entitlements.
Enterprise security programs operate on the premise that adopting new software requires a deliberate governance milestone: an application is vetted, procurement signs off, and authentication routes through central single sign-on (SSO). However, modern third-party AI agents bypass this mechanism entirely. In enterprise environments evaluated for the 2026 State of Agent Security Report, roughly 1,280 third-party platforms now embed autonomous AI capabilities, yet only 282 authenticate behind corporate SSO. The remaining thousand operate invisibly to identity infrastructure by default. Because identity stacks can only govern systems that authenticate through them, third-party AI agents enter through routine software updates, inheriting broad ambient privileges across CRMs, messaging platforms, code repositories, and production clouds without triggering an IT review.
The Identity Stack’s Thousand-Agent Blind Spot
For the past four years, enterprise AI security focused almost exclusively on a first-party deployment model. Under that framework, an organization selected a foundation model, deployed an API gateway, configured prompt filtering, and established acceptable-use guardrails. Every defensive control relied on the existence of an adoption decision point. That procurement moment provided security architects with a designated surface to instrument, an explicit policy to enforce, and a named human owner accountable for the workload.
Autonomous agents break that assumption by arriving without an adoption decision. They do not enter the enterprise as net-new vendor contracts that trigger architecture reviews; instead, they arrive embedded inside software-as-a-service (SaaS) applications that enterprises already run and trust. When software providers roll out agentic capabilities through ordinary version updates, security teams are bypassed by design.
A prominent case occurred in August 2026 with the release of Salesforce’s Slack Code. The capability allows any user in a chat channel to tag an AI coding agent directly into an active thread. The agent ingests conversation context, generates code, and opens pull requests on connected repositories. Vendor documentation highlighted that these agents inherit Slack’s native permissions and administrative controls without requiring additional IT overhead. From an IT engineering perspective, however, that architecture establishes an autonomous actor possessing transitive access to codebases and continuous deployment pipelines, whose operational boundary is governed merely by chat channel membership.
Traditional identity and access management (IAM) tools, Cloud Access Security Brokers (CASBs), and security information systems fail to register these interactions because no new session or authentication handshake occurs. The agent operates within the authorized session context of the host application, rendering traditional gateway defenses inert against actions taken inside established trust boundaries.
Three Proliferation Vectors: Inherited, Configured, and Built
To establish workable governance, enterprise technology leaders must categorize agents not merely as procured or developed, but across three distinct delivery vectors that define their operational characteristics.
| Delivery Vector | Operational Mechanism | Visibility to Security Stack | Primary Governance Challenge |
|---|---|---|---|
| Inherited Agents | Delivered via automated product updates within existing enterprise SaaS suites | Near-zero; operates within pre-existing application authentication boundaries | Bypasses procurement review; inherits ambient user and channel access |
| Configured Agents | Internal enterprise prompts and workflows executing on third-party runtime platforms | Partial; visible as API connectors or custom workflow configurations | OAuth scope over-permissioning; cross-platform transitive data access |
| Built Agents | Custom agents engineered on open-source frameworks hosted on internal infrastructure | High; tracked through source repositories, CI/CD pipelines, and cloud telemetry | Development velocity; runtime prompt injection and model drift |
Inherited agents represent the vast majority of active enterprise agent deployments and are multiplying at an exponential pace as SaaS vendors convert standard user interfaces into autonomous agent surfaces. Configured agents constitute the second-largest segment, where internal business units leverage low-code builders or vendor runtimes to automate business processes across disparate tools. These configured agents typically hold OAuth tokens granting read and write capabilities across platforms such as Google Drive, Jira, and enterprise databases.
Built agents represent the smallest, slowest-growing category. Crucially, they are also the only agents subject to traditional security gates, such as static application security testing (SAST), software composition analysis (SCA), and container vulnerability scanning. By focusing defensive investments solely on built agents, security teams inspect the minority of their attack surface while leaving inherited and configured agents unmanaged.
The Blast Radius Problem: Why Model Scanners Miss Transitive Reach
A persistent flaw in contemporary AI governance is the tendency to evaluate agents as standalone models rather than complex distributed systems. An autonomous agent consists of two components: the underlying reasoning engine and the surrounding software scaffolding. The scaffolding provides the agent with memory, tool calling definitions, system prompts, API connectors, and execution privileges.
The operational risk of an agent resides almost entirely within this scaffolding and its surrounding enterprise ecosystem, rather than the model weights. Evaluating an agent solely through static model scanning or vendor questionnaires provides zero insight into what the agent can actually access once connected to live infrastructure. To quantify real-world exposure, security teams must evaluate four structural dimensions:
- Identity: Determine whether the agent is cataloged in an authoritative directory. Does a specific human owner take operational responsibility for the agent, or does it run as a headless process inheriting the credentials of whatever employee invoked it?
- Permissions: Audit the explicit OAuth scopes, API tokens, and service roles assigned to the agent. Security teams must identify whether the agent possesses write access where read access suffices, and whether permissions were granted intentionally or by default.
- Connectivity: Map the full blast radius across direct and transitive connections. An agent initialized inside a customer support platform may hold valid connectors into an internal ticketing tool, which in turn queries a production database. Modern attackers exploit these transitive pathways through prompt injection, making direct visibility into breaking transitive attack chains before agents execute unauthorized actions essential.
- Activity: Continuously monitor runtime behavioral telemetry rather than relying on prompt text descriptions. Evaluating whether an agent’s execution patterns deviate from established baseline behaviors provides the only reliable defense against data exfiltration.
Static questionnaires and prompt inspection firewalls evaluate applications in isolation. In contrast, an agent’s reach is a dynamic property of the enterprise environment. An agent that appears benign during sandboxed testing becomes a critical threat vector if granted broad API connectivity to sensitive production datastores.
Regulatory Scrutiny and the Shift Toward Identity-First Governance
Enterprise buyers and regulatory bodies are adjusting their posture to address unmanaged agent sprawl. In 2025, Patrick Opet, Global Chief Information Security Officer at JPMorgan Chase, issued an open letter to the software industry warning that SaaS supply chain risks had evolved into a systemic threat to the broader financial system. The bank documented incidents requiring the active isolation of compromised vendors, prompting a structural shift in how enterprise buyers evaluate suppliers.
Under this emerging framework, enterprise buyers are mandating that third-party AI agents receive explicit non-human identities without default entitlements. Enterprise IT must actively verify which human user or business unit an agent represents before granting access outside its local container. This scrutiny is rapidly filtering into standard enterprise procurement requirements and vendor risk assessments across Fortune 500 enterprises.
Regulatory frameworks are mirroring this expectation. Obligations under the European Union’s AI Act are phasing in across 2026, including stringent transparency and oversight requirements under Article 50. The regulation assumes that deployers maintain an exhaustive, verifiable inventory of active AI systems, assign designated human owners, and prove continuous operational control. Organizations that cannot enumerate their third-party agents face immediate compliance liabilities.
Managing this exposure through periodic spreadsheet audits or quarterly vendor questionnaires inevitably breaks down once an organization surpasses fifty active agents. With standard SaaS platforms delivering dozens of embedded agents through monthly release cycles, manual inventories cannot keep pace. Forward-looking security teams are turning toward automated discovery tools and third-party app tracking and visibility mechanisms that construct live context graphs of human and non-human identities, SaaS permissions, and cross-application data flows.
Bottom line
The enterprise AI security paradigm has pivoted from governing chosen foundation models to discovering unvetted third-party agents embedded within daily business tools. Organizations that restrict their AI governance to prompt firewalls and vendor approval forms remain blind to over three-quarters of their actual agent footprint. Effective mitigation requires treating agents as non-human identities: cataloging their presence, restricting default scopes, and continuously mapping their transitive reach across the software supply chain.
Sources: The Hacker News, Reco, JPMorgan Chase, European Commission.
