Enterprise adoption of agentic AI has moved from pilot projects to production infrastructure faster than almost any technology shift security teams have had to contend with in the last decade. A new industry survey — compiled from responses gathered between February and May 2026 across more than 500 security, platform, and engineering leaders in North America and Europe — puts hard numbers behind what many practitioners already sense from the inside: agentic systems are being wired into build pipelines, customer support, and internal tooling at a pace that is outrunning the policies, inventories, and controls meant to govern them.
The headline figure is stark. According to the report, 78% of organizations now have at least one agentic AI system in production — up from an estimated 24% just eighteen months earlier — while only 31% report having a formal inventory of which agents exist, what they can access, and who owns them. That gap between deployment velocity and governance maturity is the central story of this report, and it is the reason "the state of agentic AI adoption" has become one of the most searched phrases among CISOs and AppSec leads in 2026.
Key Findings at a Glance
- 78% of enterprises run at least one agentic AI workload in production; 46% run five or more.
- 31% maintain a current inventory of agent identities, permissions, and tool access.
- 64% of respondents said an AI agent had been granted broader repository, cloud, or API permissions than it needed "to avoid slowing down the rollout."
- 41% reported at least one incident in the past twelve months involving an agent taking an unintended or unauthorized action — ranging from unexpected code commits to unapproved production deployments.
- 57% of agentic deployments rely on third-party tool integrations or MCP (Model Context Protocol) servers pulled from public registries, and only 22% of those integrations had undergone any formal security review before being connected.
- Median time from "agent proposed" to "agent in production" dropped from roughly 90 days in 2024 to 17 days in early 2026.
Taken together, these numbers describe an adoption curve that looks a lot like the early days of cloud and, before that, open source: enormous productivity upside, adopted enthusiastically by engineering teams, with security functionally playing catch-up.
From Copilot to Autonomous Agents
The shift the report documents isn't simply "more AI usage." It's a qualitative change in what AI systems are permitted to do. Through 2023 and 2024, most enterprise AI deployments were assistive — a developer asking a chat interface for a code suggestion, a support rep drafting a reply with a model's help. A human reviewed and approved every consequential action.
Agentic AI removes that checkpoint by design. The systems described in this report read tickets, open pull requests, query internal APIs, provision cloud resources, and merge code with progressively less human-in-the-loop review — because reducing that friction is precisely the value proposition vendors are selling. The report found that 52% of organizations have at least one agent with write access to a production code repository, and 29% have an agent with some form of standing cloud infrastructure permissions (the ability to create, modify, or delete cloud resources without a human approval step).
This is the part of the trend that should concern security teams most: agentic AI adoption is not just a new class of software to secure, it is a new class of actor inside the environment — one that can chain together access across code, cloud, and SaaS in ways no single human role typically holds.
The New Identity Problem
Every agent needs credentials — API keys, service tokens, OAuth scopes — to do its job, and the report's identity data is one of its more actionable sections. Respondents reported a median of 14 non-human identities created per agentic workflow, many provisioned ad hoc during a proof-of-concept and never revisited. Fifty-nine percent of respondents said they did not have a reliable way to answer, on demand, "which agents have access to this secret or this repository."
This mirrors a pattern security teams have seen before with service accounts and CI/CD tokens, except the blast radius is larger and the decision-making is less predictable. A misconfigured service account behaves in a fixed way; an autonomous agent with the same credentials can be manipulated through prompt injection, a poisoned tool description, or a compromised upstream dependency into using those credentials in ways no one anticipated. The report notes that of the 41% who experienced an unintended agent action, roughly a third traced the root cause to an over-permissioned identity rather than a model reasoning failure — meaning the fix, in most of these cases, was an access control problem, not an AI alignment problem.
Supply Chain Blast Radius: MCP Servers and Tool Sprawl
Perhaps the most striking data point for a supply-chain-focused audience: 57% of agentic deployments pull in third-party tools or MCP servers to extend what an agent can do, and fewer than a quarter of those integrations receive any security review before being wired in. This is functionally identical to the open-source dependency problem the industry has spent the last five years trying to solve — an unvetted package pulled into a build — except the "package" here can execute actions and access data with the agent's full permission set at runtime, not just at build time.
The report catalogs a rising category of incidents tied to this exact pattern: a plugin or MCP server with a benign-looking name that requests broad filesystem or network access, gets approved because it unblocks a sprint, and is never revisited once installed. Twenty-two percent of respondents said they had discovered an agent tool or plugin in production that no one on the current team remembered approving — a striking echo of "zombie dependency" findings from traditional SBOM audits, now showing up in the agent tooling layer.
The Governance Gap
Underneath all of this sits a simple mismatch: engineering velocity around agentic AI has outpaced the policy and tooling layer meant to constrain it. Only 34% of organizations in the report have a written policy specifically governing what agentic systems are allowed to access or do autonomously, and just 19% have automated enforcement of that policy rather than relying on manual review. Meanwhile, 88% of security leaders surveyed said they expect agentic AI usage to at least double again within the next twelve months.
That combination — accelerating adoption, thin governance, and an attack surface that spans code, cloud, and third-party tooling simultaneously — is why the report's authors frame 2026 as an inflection point rather than a steady state. The organizations that get ahead of it now, by treating agents as first-class identities subject to the same least-privilege and provenance scrutiny as any other production system, will be in a materially different position than those that keep treating agentic rollouts as a productivity experiment.
What Security Teams Should Do Now
The report's recommendations converge on a few concrete, achievable steps:
- Inventory every agent — what it can access, what credentials it holds, and who owns it — with the same rigor applied to human identity and access reviews.
- Enforce least privilege on agent identities, scoping tokens and service accounts to the narrowest set of repositories, APIs, and cloud resources an agent's task actually requires.
- Vet third-party tools and MCP servers before connecting them to an agent, and re-review them on a cadence, not just at initial approval.
- Map agent access to real exploitability, not just theoretical permission scope, so remediation effort goes toward paths an attacker (or a manipulated agent) could actually traverse.
- Build a feedback loop from incidents to policy, since the report shows a third of unintended-action incidents trace back to fixable access misconfigurations rather than model behavior.
How Safeguard Helps
Safeguard was built for exactly this moment. Reachability analysis lets security teams cut through the noise of theoretical agent permissions and third-party tool access to see which paths are actually exploitable in a given codebase and runtime, so remediation is prioritized by real risk rather than raw finding count. Griffin AI continuously reasons over code, dependencies, and configuration to surface agentic AI risk — over-permissioned identities, unvetted MCP servers, unreviewed plugins — the same way a senior security engineer would triage them, at a scale manual review can't match. Safeguard's SBOM generation and ingest capabilities extend that same supply chain discipline to the agent tooling layer, giving teams a living inventory of every dependency and integration an agent can reach. And when a fix is identified, Safeguard's auto-fix PRs close the loop by proposing the exact scoped remediation — tightened permissions, pinned or patched dependencies, removed unused access — directly in the developer's existing workflow, turning governance from a policy document into a shipped change.