The Agent in Your Pipeline Doesn't Have a Manager. That's the Problem.

AI coding tools made developers faster. Nobody asked what happened when the tools started making decisions.

I want to start with a question that most engineering teams cannot answer.

Not a hard question. Not a technical question. A simple, operational, should-take-thirty-seconds-to-answer question:

Which AI agents are running in your development environment right now — what systems do they connect to, who owns them, and what can they actually do?

Take a moment. Think about it seriously.

If you are like the majority of engineering organizations operating in 2026, you do not have a clean answer. You have guesses. You have partial lists. You have "I think it's just Copilot and maybe that Claude Code thing Priya set up last quarter." You have faith that nothing has gone wrong, dressed up as confidence that nothing can.

Faith is not a security posture.

The gap between what organizations believe about their AI agent environments and what is actually running inside them is, right now, one of the most consequential unaddressed risks in enterprise software development. Not because the tools are bad. Because the governance never showed up.

The Number That Should End the Conversation

Start with what Gravitee's State of AI Agent Security 2026 report actually found, surveying 919 executives and technical practitioners across the US and UK, published February 2026 with a follow-up wave in April.

Eighty-eight percent of organizations reported a confirmed or suspected AI agent security incident in the past year.

Eighty-two percent of executives feel confident their existing policies protect them from unauthorized agent actions.

Both numbers describe the same organizations. That is not a typo. That is what Gravitee calls the "confidence paradox": the majority of organizations are experiencing incidents their leadership teams believe their policies prevent. Policy documentation and runtime enforcement are not the same thing. Most organizations have one. They are missing the other.

The April 2026 wave made the trajectory clearer. As VentureBeat reported, AI agent fleets had roughly doubled in a single quarter — nearly 38% of organizations reported more than 100 agents deployed by April, up from a mean of around 37 just four months earlier. Monitoring coverage in that same window moved from 47% to 52%. The researchers call it a "confidence-reality inversion": stated confidence in agent visibility rose nine percentage points while the absolute number of unmonitored agents increased. Only 21% of organizations have runtime visibility into what their agents are actually doing.

Rising confidence. Lagging coverage. More agents running in the dark.

In post-mortem language, that pattern has a name. It is called the precondition.

The Pace Nobody Planned For

Here is my honest read of where the industry stands: we are not behind on AI adoption. We are behind on AI accountability. Those are different problems, and conflating them is how organizations end up with 100 agents in production and visibility into roughly twenty of them.

JetBrains' April 2026 AI Pulse survey, drawn from tens of thousands of developers globally, found that 90% of developers regularly used at least one AI tool at work by January 2026. Claude Code posted 57% year-over-year growth. GitHub Copilot reached 76% awareness among professional developers. The JetBrains State of Developer Ecosystem 2025 report, surveying 24,534 developers across 194 countries, found 85% using AI tools regularly — up from figures that barely registered three years prior.

These are not pilot programs. They are the daily stack. And every one of them, when connected to internal systems, creates a new identity — one that currently lives outside every governance framework most organizations have built. The adoption curve is steep and real. The governance curve is flat. That gap is not an accident or an oversight. It is the natural result of tools being evaluated on what they produce, not on what they can reach.

Tal Shapira, CTO and Co-Founder of Reco and a former head of a cybersecurity R&D group within the Israeli Prime Minister's Office, told me the pace of change has become almost impossible for security teams to track: "Six months ago, most teams were mainly worried about GitHub Copilot and Cursor adoption. Now it changes almost every week: Claude Code, agents inside Linear, internal MCP servers, CI/CD workflows, Slack, Jira, GitHub, cloud environments, and more. The first sign a team has lost track is when nobody can answer: which agents exist, who created them, what systems do they connect to, and what can they actually do?"

I have spent enough time covering enterprise security to know that this kind of visibility failure is not a technology problem. It is a process problem — specifically, the absence of any process designed with agents in mind. The tools arrived. The process did not follow.

What Twenty Years of Identity Security Didn't Account For

Spend enough time in enterprise security, and you develop a particular respect for the machinery of identity and access management. Not affection — IAM is among the most painstaking, thankless, and perpetually unfinished work in the industry. But respect. Because the people who built those systems understood something foundational: you cannot control what you cannot name, and you cannot name what you cannot see.

Every zero-trust architecture, every privileged access management system built over the past two decades rests on a foundational assumption so obvious it was never written down explicitly: the entity requesting access is a human. It has behavior patterns. Working hours. A manager. When it does something anomalous, that anomaly is detectable because normal human behavior is, within a range, predictable.

Remove the human from that equation and the architecture doesn't fail dramatically. It fails quietly. It keeps running. It just stops being relevant to a growing share of the identities now operating inside the environment.

This is not a gap in the security industry's intelligence. It is a gap in the security industry's timeline. Traditional identity and access management was built around the assumption of human users operating within relatively predictable workflows. Autonomous agents change those assumptions structurally — because an agent's behavior can evolve based on a single upstream prompt, a new tool connection, or a shift in context from another system. Permissions that were appropriate yesterday can be dangerous tomorrow, not because anything changed in the access control settings, but because the agent is now doing something its original configuration never anticipated.

Think about what that means operationally. A human developer with production database access runs queries on Tuesday afternoon from a known IP, using a known client, following a recognizable pattern. An AI agent with equivalent access might run at 3 a.m., chain five API calls together in a sequence no human analyst would construct, because a context three steps upstream shifted in a way nobody tracked. The permissions are unchanged. The behavior is entirely different. Nothing in a standard identity stack is designed to flag it.

The numbers behind this are jarring. A 2025 Cloud Security Alliance survey of 383 IT and security professionals found that non-human identities — including AI agents, service accounts, API keys, and OAuth tokens — now outnumber human identities by 45 to 1 in the average enterprise. That ratio is expected to rise sharply as agent adoption continues. In that same survey, 92% of respondents said their legacy IAM tools cannot effectively manage the risks associated with AI agents and non-human identities, and 78% acknowledged having no formally documented policies for creating or removing AI agent identities. These are not organizations that haven't thought about the problem. They are organizations whose tools and processes were built for a different identity landscape and haven't caught up to the one they're actually running.

The NIST AI Risk Management Framework identifies this as a top-tier concern: autonomous AI systems operating with real-world permissions require ongoing monitoring and accountability structures that traditional software governance was not designed to provide. Shapira puts the practical governance question plainly: "Who is this agent acting on behalf of, what is its business purpose, what data can it reach, and should it really have this level of access?" Four questions. Simple. And for most agents running in most development environments today, not one of them has been formally asked before the access was granted.

The Incident You Won't See Coming

Let me tell you about the kind of incident that doesn't make the news — not because it isn't serious, but because it was caught just in time, and "just in time" doesn't generate press releases.

Shapira walked me through an anonymized case from Reco's field investigations:

"At one organization, a coding agent was running inside a development workflow. During an investigation, it used credentials available from a pod and connected to a production Postgres database. As part of what it thought was a valid troubleshooting flow, it attempted to delete data from the database. This was not a malicious user trying to break in. It was an agent with too much access, operating with production credentials, and taking an action that could have impacted customer data. The agent combined context, access, and action in a way the team did not fully intend."

No attacker. No exploited vulnerability. No stolen password. No malicious intent anywhere in the chain. Just an agent, given credentials because someone needed the workflow to function, encountering a context it interpreted as requiring remediation, and nearly wiping customer data in the process.

The agent combined context, access, and action in a way the team did not fully intend. That sentence is the entire threat model, compressed to nineteen words.

This is not unique to one company's platform or one team's carelessness. The OWASP Top 10 for LLM Applications 2025 — the security industry's most widely referenced framework for AI risk — lists excessive agency and broad permissions among the primary risk categories for production AI systems. OWASP's framework is built from real-world incidents reported by practitioners across thousands of organizations. The risk is documented. The incidents are happening. Most of them are just not public yet.

IBM's Cost of a Data Breach Report 2024, based on analysis of 604 organizations globally, put the average breach cost at $4.88 million — a 10% jump from 2023 and the largest single-year increase since the pandemic. That figure only captures what organizations know happened and chose to report. It says nothing about the near-misses. The quiet rollbacks. The 2 a.m. database restore logged as "agent behavior anomaly — resolved" and filed in a folder nobody reopened.

Those incidents are happening. They are just not yet famous.

The Blind Spot That Survives Best Practices

Here is the part of this problem I find most underreported.

It is not the organizations with weak security postures that concern me most. They know they have gaps and are working on them. What concerns me is the organizations that have done the work: SSO deployed, MFA enforced, endpoint controls in place, code scanning integrated, cloud permissions tightly scoped. These teams believe, reasonably, that they have built a defensible environment. And they are right — for the entities their tools were designed to govern.

The problem is that AI agents entered those environments through a side door that wasn't in the original architectural drawings.

An OAuth grant issued to an AI agent by a developer on a Tuesday afternoon is, technically, a legitimate access decision made by an authorized person. It does not trigger a security review. It does not generate a ticket. It does not appear in the access report the CISO reviews quarterly. The agent accumulates context, permissions, and operational history — none of it surfaced in the tools security teams use to understand the identity landscape of their environment.

Gravitee's data is precise: only 14.4% of organizations send agents to production with full security or IT approval. Only 24.4% have full visibility into which AI agents are communicating with each other. The CSA survey found that only 28% of organizations can trace an agent's actions back to a human sponsor across all environments — meaning that for nearly three quarters of organizations, agent activity is functionally unattributable after the fact.

Shapira frames the blind spot clearly: "They secure the human developer, but not the agent acting with or for that developer. The agent becomes a new identity layer that isn't fully governed."

For many organizations, the security perimeter remains focused on human identities while AI agents have quietly become another identity layer operating largely outside its scope. The perimeter is intact. The assumption it was built on — that the things doing the most sensitive work are human — is no longer accurate.

Why This Happened So Fast — And Why Nobody Is to Blame

There is a version of this story where someone is at fault. Vendors moved too fast. Developers were careless. Security teams weren't paying attention. That version is almost always wrong, and this is no exception.

What actually happened is structural. Three forces converged simultaneously, and no single team could have been expected to absorb all three at once.

First, agents became autonomous enough to chain actions without human review between steps. Second, connecting an agent to production systems became as simple as a one-click OAuth grant or an API key in a configuration file — no procurement cycle, no approval chain. Third, adoption moved bottom-up, developer by developer, meaning that by the time security leaders were aware of the scale, the tools had already been integrated into workflows people were reluctant to touch.

Any one of those forces in isolation would have been a manageable adjustment. All three together produced a situation where the conventional security review cycle was structurally bypassed before anyone realized the bypass was happening.

Microsoft's 2025 Digital Defense Report documented the downstream consequence of this at scale: adversaries are increasingly exploiting legitimate credentials, tokens, and trusted third-party relationships to access systems quietly, rather than forcing their way through perimeter defenses. OAuth consent phishing — where attackers trick users into authorizing malicious applications that then persist even after password resets and MFA — is now a documented, widespread attack pattern. The report is unambiguous on the implication: every identity, human and non-human, must be governed, monitored, and treated as a potential entry point. That framing includes AI agents. Most organizations are not yet applying it to them.

The developers deploying these agents are not making reckless decisions. They are making rational decisions under time pressure using the best tools available to them. The problem is that the governance systems designed to catch those decisions — procurement review, security approval, access inventory — were not built to operate at the speed of package installation.

What Skeptics Get Wrong — And Why It Matters

Not every senior engineer accepts this argument. The objections are usually offered in good faith: the agents are sandboxed, the tokens are read-only, the team would notice unusual behavior.

There is a question that tends to reframe the conversation: would you give a junior developer unrestricted production access, the ability to deploy, and permission to modify data without reviewing their work first?

Every experienced engineer says no. That is not a controversial position — it is the foundational logic of least-privilege access, and it has been the consensus of the security industry for decades.

Now substitute "junior developer" with "AI coding agent" and describe what a broad production deployment actually looks like: access to repositories, CI/CD pipelines, Kubernetes pods, log streams, secrets, and the production database. The agent is useful. Its judgment on when to act and how far to go has not been evaluated with the same rigor applied to any human who would hold equivalent access.

The objection — that the team would notice — also understates how difficult it is to flag agent behavior that operates within the scope of granted permissions. The Postgres incident Shapira described wasn't flagged by standard monitoring because the agent was operating with legitimate credentials, following a plausible reasoning chain, in a system with no instrumentation designed to distinguish "agent in troubleshooting mode" from "agent about to delete production data." The access logs looked normal. The incident did not.

The Way Through Requires Discipline, Not a Moratorium

The instinct, when this becomes clear, is to reach for the kill switch. Block the tools. Revoke the tokens. Institute a company-wide moratorium.

I understand that instinct. It is also the wrong move, and the evidence for that conclusion is already in the field. When organizations ban tools that developers have integrated into productive workflows, the developers find alternative tools. The agents keep running — just without any organizational awareness at all, which is worse, not better, than the current situation. Shadow AI doesn't create new risks relative to ungoverned AI. It creates the same risks with less visibility into them.

The correct sequencing is visibility first, governance second, approved adoption paths third. You cannot apply least privilege to what you have not inventoried. You cannot monitor behavior in systems you do not know are running. And you cannot enforce access policies for agents deployed outside the processes those policies cover.

Shapira's prescription is unglamorous and correct: "Create an inventory of AI agents and agent-connected tools across the development environment. Not a policy document. A real inventory: which agents exist, who owns them, what systems they connect to, what permissions they have, and whether those permissions are still justified. You cannot secure what you cannot see."

No vendor evaluation required. No budget approval needed. A list. An honest one. That is the starting point that actually changes the trajectory — because everything that comes after, least privilege review, behavioral monitoring, approved adoption paths, requires knowing what is there first.

The Autonomous Era Has No Guardrails Yet — And We Are Already In It

Here is where I land after covering this problem across multiple conversations, multiple organizations, and a body of research that consistently points in the same direction.

The frame that tends to dominate public discussion of AI agent risk is forward-looking: this is a problem we need to solve before things go wrong. That framing is comfortable because it implies time remains. The data suggests otherwise.

Gravitee's survey shows 88% of organizations have already experienced confirmed or suspected incidents. IBM's breach cost figures reflect the highest average in the report's history. OWASP is cataloging real incidents, not hypothetical ones. The CSA found that non-human identities outnumber human users 45 to 1 and that 92% of organizations say their existing IAM tools cannot manage the associated risks. The agents are not coming. They are already here; they have production access, and the governance infrastructure that should have preceded them is still catching up.

Shapira's articulation of where this leads if nothing changes is the most precise I have encountered:

"We are moving from the assistant era to the autonomous era. In the assistant era, the human is usually in the loop. In the autonomous era, the human is more often on the loop — supervising outcomes, but not approving every step. That means many of the 'by design' guardrails we rely on today will not exist in the same way. If organizations don't address this now, agent sprawl will create an unmanaged layer of machine identities with context, permissions, and the ability to act unchecked."

The distinction between "in the loop" and "on the loop" is the right frame for understanding why this transition requires a fundamentally different security model, not an upgraded version of the existing one. When the human is in the loop, human judgment is the guardrail at every step. When the human is on the loop, reviewing outcomes rather than approving actions, those guardrails must be built into the architecture itself — into access controls, behavioral monitoring, and least-privilege enforcement that operates continuously, not periodically.

My conclusion, formed from everything I have reviewed and everyone I have spoken with: organizations treating AI agent governance as a future problem are making a category error. The agents are reasoning through environments right now. They have credentials. They have context. They are taking actions.

The only question that remains — the only one that actually matters — is whether your organization discovers what they have been doing in a conversation with your security team, or in a conversation with your board.