The Agentic Enterprise Needs a New Security Architecture

AI agents have plenty of controls around them. What enterprises need is the intelligence to make those controls act together.

Over the last year, Cyera’s leadership team and I have met with security and technology executives at nearly every Fortune 500 company and much of the Global 2000. Almost all of them face the same problem: the business wants the productivity of AI agents, and security is being asked to make that happen without losing control.

I've also studied the companies racing to secure AI agents. The industry's response follows a familiar playbook. Put a new control at the endpoint. Add one to the network. Build an AI gateway. Intercept API calls. Hook into the agent framework or the model provider's runtime. Each is useful and adds another place to observe or stop an action.

I call these controls the muscles of security. The problem is that we are building muscles faster than we are building the brain that tells them what to do. An endpoint can see a process. A gateway can see a request. An identity system can validate a credential. A data loss prevention tool can recognize a sensitive pattern. But no single observation can answer the question the agentic enterprise faces millions of times:

That is an intelligence problem before it is an enforcement problem, and it requires a new security architecture.

Why siloed controls are not enough

Imagine a procurement agent asked to compare bids from three suppliers. To do its job, it legitimately reads confidential pricing, accesses an internal contract repository, browses public websites, and drafts a recommendation. Then it posts a detailed comparison, including negotiated prices, into an external collaboration service where anyone with the link can see it.

At each step, a point product may see something ordinary. The user authorized the agent. The credentials are valid. The endpoint process is approved. The web request is allowed. The document is readable. The risk emerges from the combination of sensitive data, the agent's delegated authority, the business purpose, the destination, and the proposed action.

That is why securing any single layer is not enough. We need to understand the entire path, from the business objective to the data and the action.

Five ways agents break the assumptions behind security

For 30 years, we have designed much of enterprise security around people using applications. That design rests on five assumptions: actions moved at human speed, granted access mostly sat unused, applications behaved predictably, a person with judgment stood behind every action, and identities and permissions changed slowly. Agents break all five.

1. Speed compresses risky actions into seconds. Security was built for a human pace, with time to notice and respond. An agent can read, reason, call tools, write code, and move information at machine speed. A sequence that would take a human hours can unfold before an analyst sees the first alert. Security cannot depend on a person reviewing every action after the fact.
2. Access becomes reach. Over-provisioned access was tolerable because people rarely touched most of it. In research spanning 2.4 million workers and 3.6 billion permissions, Cyera and Oso found that people used only about 4% of the access they had been granted. Most of that excess privilege was dormant because people have limited time and attention. An agent does not. It can systematically discover and exercise far more of its authorized reach in seconds, and can ask for additional tools or access as a task evolves.
3. Behavior can drift away from intent. Traditional software follows a relatively bounded set of instructions. Agents interpret objectives, choose steps, consume untrusted content, invoke other agents, and adapt midstream. An agent can begin with an approved task and end up doing something its owner never intended. Sometimes that is a mistake. Sometimes it is prompt injection. Sometimes it is the unexpected result of several agents interacting. The individual steps may all look legitimate.
4. Accountability does not live inside the agent. Every action used to trace back to a person who could be held responsible. People can be trained, disciplined, sued, or prosecuted. An agent has no personal consequences and no instinct for restraint. That does not remove human accountability. It makes it more important to know who created the agent, who authorized the task, which identity and credentials it used, what it did, and who can stop it. Every autonomous action needs a traceable owner and an audit trail that the agent cannot quietly rewrite.
5. The attack surface expands continuously. Identities used to persist and permissions changed slowly, so periodic reviews were sufficient. Agents generate code and data, create or invoke tools, move between systems, and increasingly delegate work to other agents. Identities, credentials, workloads, and permissions can appear and disappear throughout a workflow. I believe enterprises should plan for a future in which non-human identities outnumber people by tens to one, and eventually hundreds to one.

The conclusion is uncomfortable: a security architecture built around static access, isolated controls, and human-speed review cannot adapt to an agentic workforce.

What a new security architecture has to do

For decades, cybersecurity has spent extraordinary energy trying to know the enemy. The agentic era forces us to become much better at knowing ourselves: which data actually matters, why it matters to the business, which identities can reach it, and what legitimate behavior should look like.

We are not throwing out 30 years of security strategy. We are changing how that strategy is executed when the actor is autonomous.

What the security brain has to know

I believe that new architecture comes from the convergence of five forms of context.

1. Data intelligence. The data must be the starting point. Security needs to know not just whether a document carries a label, but what the data actually contains, how sensitive it is, where it came from, who owns it, how it relates to other information, and what business process it supports. High-efficacy discovery and classification are prerequisites.
2. Identity intelligence. Identity is the route to the data. That means security needs to monitor every human, service account, machine, and agent identity and understand the credentials, entitlements, and owner behind each one. Agents appear and disappear inside a single workflow, so this identity inventory must update in real time. When an agent is provisioned, it should have an owner, a defined purpose, managed credentials, appropriate entitlements, and an expiration. We should not wait until the agent misbehaves to discover that nobody knows who owns it. Identity tells us who or what can act. It cannot, on its own, tell us whether a particular use of data is appropriate.
3. Business context. A customer record, an M&A model, an unreleased product design, and a lunch menu should not be treated as equivalent simply because they sit in the same repository. The importance of the information, the approved workflow, regulatory obligations, and the organization's risk appetite must inform the decision.
4. Intent and purpose. Roles describe a relatively stable job. Agents can pursue different goals from one task to the next. Security has to know what the agent was created to do, what the person or business process authorized for this task, and which tools and data it actually needs. When purpose, reach, and behavior diverge, policy should narrow access, request approval, or stop the workflow. Agents should start with minimal reach, receive short-lived access that is sized to the task, and lose it when the task ends or trust breaks. Inferred intent is useful evidence, but it should never be mistaken for proof or allowed to override hard policy.
5. Behavior and action context. A successful login or an approved token is no longer a sufficient trust decision. The meaningful moment is the transaction: the exact API call, data retrieval, transfer, code execution, or privilege change the agent is proposing. Security needs to know what the agent has already done, what it is trying to do next, and which other agents, tools, destinations, and datasets are involved. If a person delegates to an agent, which calls another agent, which invokes a tool, authority should become narrower at each step to avoid intent drift.

Turning context into a decision

Put those pieces together, and a different model of trust becomes possible:

Data intelligence + identity intelligence + business context + authorized purpose + observed behavior = an informed, real-time trust decision.

Only the combination can distinguish legitimate work from a technically authorized but unacceptable action. That decision cannot be a guess made by a second LLM watching the first one. Humans should define the risk appetite and review high-impact exceptions, and we still need unbreakable rules. A developer agent should not export production cardholder data just because its model generated a persuasive explanation. A payment above a defined limit should still require human approval. A credential should expire at the end of the task. Within those red lines, context-aware analytics can identify ambiguous risk, adjust scope, and catch behavioral drift. 

Accuracy matters at scale. False positives that repeatedly interrupt legitimate work will cause teams to bypass guardrails. False negatives will allow harmful actions through. Classification accuracy alone is not the same as authorization accuracy, so we have to test the quality of the complete decision.

The brain must control the muscles

Intelligence that only produces another dashboard is not a control plane. An agent's workflow can run from a laptop to a SaaS application, across APIs and clouds, through an AI gateway, and into a production database. A unified policy has to reach the endpoint, browser, identity provider, just-in-time privileges, agent runtime, network, egress controls, APIs, AI gateways, model and agent hooks, infrastructure, and data access point. We should make existing controls work together from a shared understanding of risk, and add new controls designed for agents where they are needed.

Phil Venables has compared autonomous systems to high-frequency trading, where they need pre-execution action gates, circuit breakers, scope limits, independent kill switches, and tamper-resistant audit trails. I agree. But those mechanisms still need to know when to act. A circuit breaker requires meaningful limits. A pre-execution gate requires an understanding of the proposed transaction. That is the job of the intelligence layer.

This is what I mean by an intelligent control plane. It is a continuous decision system that decides before each action, enforces at the control point, and records an independent audit trail. It learns from approved corrections, and it can explain every decision in business terms. 

Trust is not a permanent attribute granted at login. It is a decision earned in context.

What this changes for the business

An intelligent control plane means AI can move faster. When leaders know which data agents can use, what the boundaries are, and how those boundaries will be enforced, they can authorize more valuable, powerful workflows with confidence. Security becomes an enabler of adoption instead of the last approval gate.

Risk becomes more precise. A permission that reaches an empty test environment is not equivalent to one that reaches unreleased financial results or millions of customer records. Combining identity reach with business-sensitive data context focuses attention and enforcement on the exposures that matter most. Narrower grants also reduce the impact when an agent goes wrong.

Operations become more efficient. Automating discovery, classification, access rightsizing, and policy enforcement reduces manual reviews and the work of correlating disconnected alerts. 

Governance becomes continuous. Every relevant decision can generate evidence about ownership, authorization, data use, exceptions, and enforcement. The result is ongoing control over the agentic workforce, so teams no longer rely on periodic access reviews and retrospective investigations.

Why we are building Cyera Omni

This is the conviction behind our work at Cyera. We began with a difficult problem that most security architectures treated as secondary: understanding enterprise data accurately and at scale. We expanded that foundation into data protection and behavior. With the addition of Oasis, we are bringing identity and non-human identity intelligence into the same picture. And we are extending the model to agents, their intent, their actions, and the control points where those actions become real.

Cyera Omni is our vision for an intelligent control plane that connects those dimensions. It is designed to sit above and work through existing security investments while also using Cyera's own enforcement capabilities where needed. The goal is to govern what every human, machine, and agent can see, access, and do without forcing the business to slow down to human speed.

Three elements of Omni are especially important to that vision:

• The Omni Engine is the brain. It brings together data classification, identity relationships, business context, delegated purpose, and observed behavior so that a policy decision reflects the full interaction, not an isolated alert. Data discovery and classification, identity and non-human identity security, and agent security share one foundation. None of those disciplines delivers the same intelligence when left in a silo. The Engine asks, continuously: Should this identity perform this action on this data, now, for this purpose?

• A single control plane connects intelligence to action. Cyera's platform and Cy Agents are intended to carry shared context across the lifecycle, from discovery and risk prioritization to policy, remediation, and response. A security team should not need to reconstruct a workflow from five different consoles to understand why an agent was allowed or stopped.
• Enforcement must happen wherever the action becomes real. At each control point, the system needs a way to implement the decision before damage occurs. The answer may be allow, deny, redact, reduce scope, require additional assurance, or isolate a runaway process. The intelligence should be shared even when the enforcement mechanisms belong to different vendors.

Control that keeps pace

I am not suggesting that one product can make every agent safe or that simply combining data and identity makes the problem disappear. This architecture will be judged by the accuracy of its context, the quality and explainability of its decisions, the breadth of its integrations, the reliability of its enforcement, and its ability to operate at agentic scale. Those are the standards we should hold the industry accountable to, including Cyera. 

The companies that win this market will not be the ones that claim the most places to block a request. They will be the ones that can understand what the business is trying to accomplish, determine what should be trusted at that moment, and make the right control act before damage is done.

The agentic enterprise needs strong muscles. But it will not be secure until those muscles have a brain.