The AI doomsday debate within the cybersecurity and cloud leadership community focuses less on existential apocalypse scenarios and more on immediate operational chaos.
“You don’t have to believe that an army of rogue AI agents is gonna take down the internet to recognize that we already have a very real problem,” Jen Easterly, CEO of RSAC, wrote over the weekend.
[Related: Who Gets to Control the AI Agent? Identity vendors, hyperscalers, gateways and security companies are all planting flags. The fight is over who holds the leash when autonomous software acts.]
The present-day challenge is integrating AI into existing governance, risk, and compliance frameworks. Without the ability to audit autonomous agents accessing corporate networks and strict “secure by design” principles, government regulations and voluntary AI slowdowns by AI labs do little to protect against day-to-day data exposure and supply chain vulnerabilities.
Today’s CISO debate is more agent pragmatic versus AI doomsday. Ask eight security companies to outline how autonomous AI agents need to be controlled safely and you will get eight different answers.
Identity companies see an identity problem. Privileged-access companies see authorization. Network defenders see blast radius. Browser companies see the point where agents touch data and applications. Researchers see vulnerable frameworks and infrastructure beneath all of them.
That tension is driving a race to deliver the definitive agent control plane. That is a layer outside the AI model that decides who an agent is, what it may access, which actions it may take and when somebody – or something – needs to tell it no.
Security Point Break asked companies working at those layers where they believe control belongs. Their answers do not produce one box. They sketch the beginnings of an agent control stack that might someday stave off doomsday.
Identity: One Agent, Many Leashes
Nearly every vendor starts with the same question: Who, exactly, is this agent and how much authority should it get?
Tal Marom, Oak‘s co-founder and chief product officer, argues agents should begin with almost none. “You should start bare minimum,” he said, then expand permissions only as needed.
Oak builds an identity graph from evidence scattered across applications, OAuth relationships, tokens, service accounts and other identities, then uses actual access patterns rather than accumulated entitlements to help define what an agent needs.
Oak does not position itself as a universal AI agent control plane. It calls its platform an AI-native identity operating system, bringing human, machine and agent identities into one continuously updated identity and access layer. Its argument is that identity should provide the foundation on which broader agent governance is built.
That does not stop an agent from going rogue. It limits how far rogue can go. A bad prompt, stolen credential or wayward decision becomes less dangerous when the agent never had broad authority in the first place.
Identity answers who is acting. It does not settle whether the next action should happen.
“Agents are mission-driven. They will do everything to satisfy you. Don’t trust them.” – Tal Marom, Oak’s co-founder and chief product officer.
Market Differentiation: Oak treats identity as a live graph of actual access across humans, machines and agents, using observed need rather than accumulated permissions to define what an agent can do.
Cryptography: Trust Has to Survive the Handoff
A person may instruct an agent to perform a task. That agent may delegate part of the job to another agent, call a tool and ultimately change a distant system. At every hop, authority can blur.
Keyfactor‘s Ellen Boehm argues cryptography can keep that chain of authority intact as instructions move from person to agent to agent. A signed instruction can show who issued it, whether it was altered and whether it is still valid.
“The Keyfactor trust layer ends at provenance,” Boehm said. It can establish an instruction’s authenticity, integrity and freshness – essentially, who sent it, whether it changed and whether somebody is trying to replay an old command.
Keyfactor is not trying to make cryptographic trust the entire agent control plane. Its role is more foundational: issue identities, sign and verify instructions and agent skills, authenticate agent-to-agent and agent-to-service connections, and track the cryptographic assets agents use. Business policy, orchestration, behavioral monitoring and human approval sit above that trust layer.
A perfectly authentic instruction can still be a terrible one. A valid order to delete a customer database is still an order to delete a customer database.
So Keyfactor separates proof from permission. “Trust shouldn’t be inherited by proximity,” Boehm said. Each hop should carry its own verifiable link back to an authorized source rather than be trusted simply because the previous agent was. Identity establishes the actor. Provenance establishes the order. Neither grants permission to carry it out.
“The cryptographic trust infrastructure is the foundation that everything else stands on.” — Ellen Boehm, SVP, Strategy & AI Innovation, Keyfactor.
Market differentiator: Keyfactor focuses on cryptographic proof of authenticity, integrity and freshness so every agent instruction and delegation hop can be independently verified.
Frank Vukovits, chief security scientist at Delinea, calls authentication “table stakes.” Authorization is where things get harder.
Delinea comes at the control-plane problem from privileged access and identity security. It describes its platform as an identity security control plane, but its argument here is narrower than owning the entire agent stack: once an agent has been identified and authenticated, something still has to decide whether each action it attempts should be allowed.
Vukovits offered a simple example. An agent authorized to query a customer database might retrieve the requested statistics – then decide exporting the entire terabyte of underlying records would produce a better answer.
Same agent. Same session. Very different action.
Delinea’s answer is runtime authorization: check actions as the agent attempts them rather than treating authentication as a pass for the entire session.
“Every action that agent takes, every single one,” Vukovits said, can be checked against policy. It proceeds, stops or gets kicked to a human for approval.
The same logic extends to credentials. An agent may need a privilege without ever needing to possess the credential that unlocks it. Delinea can inject a short-lived credential only after an action is approved, then let it expire when the action is complete.
Do not give the agent the master key. Open the one door it needs, for the few seconds it needs it.
“Authentication is becoming table stakes. Authorization is the harder agent problem.” – Frank Vukovits, chief security scientist at Delinea.
Market differentiator: Delinea applies runtime, per-action authorization and short-lived credentials rather than treating authentication as permission for an entire session.
Enforcement: But There Isn’t One Door
Where Delinea focuses on the action, Island‘s bet is that control has to follow the agent across multiple enforcement points rather than depend on one gateway.
Island Field CTO Michael Leland offered Salesforce as an example. An agent can request access without ever receiving the real Salesforce credential. Island’s gateway can broker it instead – and if the agent asks for read-write access when policy allows only reading, substitute a read-only credential.
Island is more explicit than several companies in this story about wanting to own the control-plane layer. It markets what it calls the Enterprise Agentic Control Plane, extending policy and audit across the browser, endpoint, network and agent tool calls. Its thesis is that agent governance has to sit close to where work actually happens because no single gateway sees every path an agent may take.
Leland said prompts, responses, tool calls and returned data can all become enforcement points.
That exposes the problem with declaring any single gateway the control plane: agents do not necessarily use the doorway security architects expected them to use.
Delinea’s Vukovits noted that agents may connect directly to databases, cloud consoles, infrastructure or other services. Guarding one doorway does little good when the agent knows five.
“AI’s intent can really only be measured as close to the user as possible.” – Michael Leland, Field CTO, Island.
Market differentiator: Island spreads policy and enforcement across browser, endpoint, network and agent tool calls rather than relying on a single gateway.
Application Containment: Keep the Agent in Its Lane
Even if policy follows an agent to the endpoint, another problem appears: agents can chain legitimate applications together in ways security teams never intended.
ThreatLocker approaches that problem through application containment, or what it calls ringfencing. The idea is to give an agent access only to the files, applications and network resources required for its job – and block everything outside that lane.
Danny Jenkins CEO and Co-founder of ThreatLocker offered a simple example. An accounting agent may legitimately need access to billing software and certain file locations. It should not also be able to reach unrelated files, invoke PowerShell or use another approved application as a bridge to something prohibited.
ThreatLocker is not positioning itself as a universal AI agent control plane. Its argument is more practical: whatever the broader control plane looks like, some of its rules eventually have to become enforceable on the endpoint.
A restriction on PowerShell does little good if an agent can launch Word, then use Word to reach PowerShell indirectly. ThreatLocker argues those permissions have to cascade through the entire sequence rather than disappear after the first allowed application.
“The most important thing is not what the Agent Control Plane looks like, but what it can enforce,”- Danny Jenkins, CEO and Co-founder of ThreatLocker.
Market differentiator: ThreatLocker brings the control plane down to the endpoint, using application containment and ringfencing to prevent agents from chaining approved tools into prohibited actions.
Network: Behavior Is the Tell
Even an agent that passes every preceding test can still do something nobody anticipated.
Cyntros approaches that problem from the network rather than identity or authorization. Its network detection and response platform uses adaptive machine learning to establish what normal communication looks like inside an environment, then flags activity that departs from that baseline. It does not need to know whether the actor behind that traffic is a person, attacker or AI agent.
“We’re not differentiating: this was AI, this was a human,” Grant Yoder, a Cyntros executive said. The question is whether the activity matches normal patterns of information moving through the network.
Cyntros is not selling an AI agent control plane. Its role in the stack is closer to a sensor: detect behavior that identity, authentication and policy controls did not predict, then pass that signal to a system capable of responding.
A rogue agent does not necessarily announce itself as rogue. It may be properly authenticated, carry legitimate permissions and use familiar systems while quietly doing something entirely new. A database query that normally returns one customer record, for example, suddenly retrieving thousands can change the volume, duration and pattern of network traffic enough to raise an alarm.
Detection cannot decide what an agent should be allowed to do. It can tell the control plane when an agent with perfectly good papers has started acting badly.
“The network doesn’t lie,” – Grant Yoder, Cyntros.
Market differentiator: Cyntros watches what an agent actually causes on the network, using learned behavioral baselines to catch activity that may look legitimate to identity and authorization controls.
Microsegmentation: How Far Can It Go?
That is where Xage draws the next boundary.
“Identity tells you who or what is acting,” Xage CEO Duncan Greatwood said. “It does not contain the blast radius of that identity.”
An authenticated agent can still be dangerous if it can reach systems unrelated to its job. Xage argues microsegmentation should shrink that world: an inventory agent should reach the inventory database, not an entire network simply because both happen to live behind the same firewall.
That distinction gets sharper with autonomous agents. They can act at machine speed, invoke multiple tools and move across systems in seconds. Xage argues they also should not automatically inherit every permission of the human they represent. Delegated authority may need to be narrower than the user’s own entitlement set.
Xage does not market a universal Agent Control Plane. Its Zero Trust for AI platform instead focuses on the enforcement layer: identity-based access controls, microsegmentation and policy that sit outside the agent and constrain what it can reach and do. Those controls are meant to remain deterministic even when the agent is not — blocking lateral movement, prohibited APIs, privilege escalation or access to protected data regardless of what prompted the behavior.
That “outside the agent” part is central to Xage’s argument. In-model guardrails may influence behavior, but an agent should not be able to reason around, override or jailbreak the controls defining its boundaries.
“We should not have to predict every bad decision an AI might make… We should make sure a bad decision cannot become an unconstrained action.” – Duncan Greatwood, Xage CEO.
Market Differentiation: Xage treats microsegmentation as a hard enforcement boundary outside the agent, limiting both what an authenticated agent can reach and how far a mistake, compromise or manipulated decision can spread.
Orchestration: Who Gets the Final Say?
The larger lesson is that no one control solves the problem.
An agent can have the right identity, carry a legitimate instruction and still make a terrible decision. It can stay inside its permissions and act on bad context. Ten individually authorized actions can combine into one damaging outcome. Each layer closes one gap and exposes the next.
Rilian comes at the problem from the orchestration layer. Christian Schnedler, CEO of Rilian Technologies, argues that consequential agent decisions must first be re-constructable. Its Caspian agentic harness records prompts, retrieved context, tool calls and other interactions as causally linked events so operators can determine not just what happened, but what information and rules shaped the decision.
The second requirement is an external enforcement path. Tool calls, API requests, code execution and other actions route through what Rilian calls an invocation plane outside the agent itself.
“Enforcement must occur at the point of action, outside of the agent, and on a path it cannot route around,” Schnedler said.
Caspian also keeps credentials away from the model. An agent identifies the tool it wants to use; the invocation plane evaluates the request and attaches the credential only after authorization. As Schnedler puts it, the model “cannot leak what it was never given.”
But authorization alone cannot answer whether an otherwise permitted action makes sense in context. Schnedler uses critical infrastructure as an example: an agent may be authorized to take a vulnerable controller offline while remaining blind to the possibility that doing so during a heat wave could create a larger public-safety problem.
That shifts the question from: “Can this agent do this?” to “Should this happen now?” Schnedler said.
Rilian’s answer is consequence-aware governance: evaluate the action, its broader dependencies and potential impact, then automate low-risk decisions while escalating higher-consequence ones to people.
Scale makes that harder. “At ten agents, human operators are likely to read the outputs and observe suspicious behavior,” Schnedler said. “At a thousand agents no organization will be able to detect this phenomenon.” Too many escalations, he warned, and humans begin rubber-stamping recommendations, hollowing out the control.
Rilian is not arguing that every enterprise needs one monolithic control-plane product. Its position is narrower: agents may reason and recommend, but consequential actions ultimately need an enforcement point outside the model, backed by enough context to know when permission alone is not enough.
“You cannot rely on the agent that may have been confused, manipulated or compromised to impose the final control on itself.” – Christian Schnedler, CEO of Rilian Technologies.
Market Differentiation: Rilian separates agent reasoning from execution, routing consequential actions through an un-bypassable orchestration layer that preserves decision context, applies consequence-aware policy and escalates the decisions that still require human judgment.
