Agent Security in 2026: Why the Bottleneck Is Control, Not Intelligence

Written by By Helen Wu (Kellogg MBA '26), JJ Li

‍

Why the bottleneck is control, not adoption

2026 has been a pivotal year for AI agents. Enterprises are moving from copilots and LLM wrappers toward autonomous workflows that can retrieve data, call tools, write code, approve actions, and coordinate across systems. Adoption is no longer the bottleneck. According to Gravitee’s State of AI Agent Security 2026, 80.9% of technical teams are already testing or running agents in live environments, and Gartner expects up to 40% of enterprise applications to include task-specific agents by the end of 2026.

The harder problem is trust. Cloud Security Alliance reported in March 2026 that 68% of organizations cannot clearly distinguish AI-agent actions from human actions in their existing logs, while Gravitee found that only 22% of organizations treat agents as independent identities and only 14.4% have full IT and security approval for their entire agent fleet. The question is no longer whether enterprises will deploy agents. It is whether they can trust agents enough to let them act.

That trust gap exists because agents break the assumptions behind traditional enterprise security. Traditional security assumes identities are known, permissions are relatively stable, and workflows are deterministic. Agents break all three. An agent can be spun up for a single task, delegate to another agent, call a SaaS API, pull context from a data warehouse, and then write back to a system of record. The same agent can also behave differently across runs because its plan is probabilistic, its context changes, and its tool calls depend on intermediate reasoning.

That makes agent security less like logging into a SaaS app and more like controlling a live, non-human operator. Security teams do not just need visibility into what happened. They need active control over what an agent is allowed to do next.

‍

Four layers of agent security

In this review, we think enterprise agent security will consolidate around four layers. The table below is a simple way to visualize how the stack separates into distinct control points.

These layers are related, but they are not equal.

Authorization is the most urgent deployment need because it governs live actions.

Runtime monitoring is where visibility becomes enforcement.

Data governance may be the hardest layer to replace because it accumulates connectors, lineage, and policy depth.

Red teaming is essential, but it is less likely to remain a durable standalone budget line unless it improves the rest of the control plane.

‍

Authorization is the first control point

The first security primitive for agents is identity.In the cloud era, security teams learned to manage human users, service accounts, and machine identities. Agents introduce a more dynamic category: non-human identities that can be created, delegated, scoped, revoked, and audited at execution time.

This is why authorization sits at the top of the urgency stack. The core question is not only “is this agent real?” It is “is this agent allowed to take this specific action, against this specific data, in this specific workflow, right now?” Mutual TLS can help prove that two systems are legitimate members of a trusted network. But it does not answer whether an agent should be allowed to call a payment API, export a customer file, or write to production.

In practice, an authorization layer for agents needs more than static credentials. It needs short-lived permissions, fine-grained scopes, just-in-time approval, clear workflow boundaries, agent-to-agent authentication, revocation, and auditability. The implementation burden is one reason why this layer is emerging as the first true control point rather than just another observability problem.

This is also where many of the most interesting startup wedges are forming.

Incumbents such as Okta and CyberArk are extending identity, machine identity, and privileged-access stacks into agent workflows, while newer vendors such as Aembit, Permit.io, AuthZed, P0 Security, and Opal are building more programmable policy layers for non-human actors. The implementation styles differ, but the functional goal is similar: issue short-lived credentials, enforce fine-grained scopes, and make agent actions revocable and auditable in real time. Customer diligence also suggests that this layer can support both platform-style vendors and sharper modules. Some buyers want authorization bundled into a broader control plane, while others will pay for a focused access layer if it sits directly in the path of action. Either way, whoever controls authorization sits closest to production readiness.

‍

Runtime, data, and red teaming do different jobs

Runtime monitoring turns mirrors into brakes. Most security tooling has historically been built around detection: dashboards, alerts, posture scores, and audit logs. Agents require something closer to brakes. If an agent is about to send sensitive data to an unapproved destination, call an unexpected tool, or chain together actions that violate policy, the system needs to intervene before the action completes. This is where vendors such as HiddenLayer and Lakera have focused on model and runtime protection, while Zenity, WitnessAI, and Noma are pushing further into agent behavior, workflow visibility, and policy-aware intervention. Broader security platforms such as CrowdStrike, Palo Alto Networks, and Zscaler are approaching the same layer from adjacent control points such as endpoint, network, and egress. Customer diligence suggests that buyers split here between broad platforms that combine posture, runtime control, and governance, and sharper modules that solve a high-severity runtime or model-protection problem. Both can create value, but they are likely to compound differently.

Data governance is the deepest moat. Agents are only as useful as the enterprise data they can access. But enterprise data is messy: permission models vary by system, sensitive data is duplicated across tools, and context windows can turn private data into operational memory. A secure agent stack must decide not only whether an agent can access a source, but whether that data can be summarized, copied, retained, or reused in a future task. This is why the implementation burden often sits closest to the real enterprise data estate. Incumbents such as Varonis, AvePoint, Cloudflare, and Zscaler bring policy, DLP, and data-path control, while newer vendors such as Dymium, Vorlon, Lema, Zenity, Protect AI, and Credo are trying to manage context-window exposure, memory, lineage, and governance more directly. In practice, this layer may support both broader platforms and focused wedges, but the more connectors, policies, lineage, and memory controls a product accumulates, the harder it becomes to replace.

Red teaming matters most when it feeds back into controls. Enterprises need to know whether their agents can be tricked by prompt injection, manipulated into tool misuse, or pushed into leaking data. But as a standalone category, red teaming may behave more like an assessment market than a durable control plane. The stronger products will be the ones that feed their findings back into runtime guardrails, authorization policy, and data controls. That is why representative products such as Patronus AI, Armadin, Lakera, and Mindgard matter less as one-off testing tools than as continuous feedback systems, while larger platforms such as Microsoft and CrowdStrike can increasingly bundle testing into broader AI security workflows. In other words, red teaming is essential, but it becomes strategically stronger when it improves the rest of the stack rather than living alone.

‍

Build vs. buy: the plumbing is broader than it looks

A common objection is that enterprises can build agent security internally. Some will try. But the plumbing is broader than it looks. A production-ready stack needs agent identity, token issuance, fine-grained scopes, agent-to-agent authentication, credential handling, logging, revocation, workflow boundaries, and auditability. It also needs to work across heterogeneous clouds, SaaS tools, internal APIs, and model providers.

The right place for internal teams to create differentiated value is usually policy, ownership, approvals, exception handling, and operational discipline. Rebuilding generic security plumbing is rarely the best use of scarce engineering time. This is why external platforms can often clear the payback hurdle faster: they shorten deployment time, package ongoing updates, and reduce the hidden maintenance load that comes with a homegrown stack.

‍

What we look for—and what could go wrong

These dynamics translate into five investment filters.

1. Control-point depth: Does the product sit in the path of action, or does it only report on risk after the fact?
2. Authorization urgency: Does the buyer need this before production deployment, or can it wait until after scale?
3. Data proximity: Can the product operate close to where sensitive enterprise data lives, without forcing data into a new silo?
4. Switching-cost formation: Does usage accumulate policy logic, audit history, connector depth, or memory controls that make replacement painful?
5. Platform-bundling risk: Can a large security or cloud platform replicate this quickly, or does the startup have depth that a bundled module cannot match?

The most attractive companies will combine urgent deployment need with long-term switching costs. But there are real risks. Incumbents may bundle agent security into broader IAM, endpoint, SASE, cloud, or SIEM platforms faster than expected. Regulation may shape buying cycles unevenly across sectors. A single technical failure involving data leakage, autonomous action, or production-system misuse could damage trust in a young vendor. And the category may fragment as model providers, cloud platforms, and security vendors define overlapping standards. These risks do not invalidate the opportunity, but they do make product depth and deployment discipline more important.

‍

From visibility to control

Taken together, these trends point to a clear thesis: agent security is becoming a core layer of enterprise software infrastructure.

As agents move from recommendation to action, enterprises will not be able to rely on static permissions, after-the-fact logs, or manual approval processes. They will need a control plane that understands non-human identity, runtime intent, sensitive data, and adversarial behavior.

The question is no longer whether agents will enter the enterprise. They already are. The question is which agents enterprises will trust enough to let them act.

The winners will be the companies that turn agent security from a dashboard into a brake system—one that is policy-aware, data-aware, and embedded directly in the path of action.