Zenity said it has expanded its platform into a full AI security system for autonomous agents, adding Exposure Management and Runtime Boundaries so security teams can govern agent decisions before those decisions become enterprise actions. The company positioned the July 27, 2026 release as the first platform built around that decision-layer model rather than alerts that arrive after an agent has already acted.
The core claim is that autonomous and long-horizon agents create risk across sequences of steps that can each look legitimate on their own. As agents write code, call tools, touch sensitive data, and run multi-step workflows over hours or days, Zenity argues that security has to intervene at the moment of decision, not only at the prompt, model, or output boundary.
“Every major technology shift has forced security to evolve,”"
Autonomous AI introduces the next evolution: the decision itself. The future of AI security won’t be defined by what an AI agent already did. It will be defined by what AI is allowed to do before it acts. Security starts at the decision layer and Runtime Boundaries are the engine that makes that possible.”
Tomer Teller, VP of Product at Zenity
According to the company, Runtime Boundaries continuously evaluate each agent action against context such as identity, requested action, data access, tools, execution history, and policy, then allow, block, or terminate the action before impact. Exposure Management is designed to identify the attack paths most likely to be exploited and feed that prioritization into runtime enforcement. Zenity said the combined system is available immediately and covers agents across environments including Claude Code, Cursor, Microsoft Copilot, Salesforce Agentforce, ChatGPT Enterprise, Amazon Bedrock, Azure AI Foundry, and custom-built agents.
Conditions Driving the Event
Autonomous agents are no longer limited to single prompts. They run multi-step workflows over hours or days, which means risk can build across a chain of individually legitimate decisions rather than appearing in one obvious malicious request.
Agents now write production code, call enterprise tools, touch sensitive data, and complete business workflows with less continuous human review, which expands the blast radius of a single wrong decision.
Traditional AI security controls focused on prompts, model outputs, and post-event alerts. Those controls often arrive after an agent has already taken an action that affects systems or data.
Long-horizon agents change the threat model because context, permissions, tools, and intent can shift across the workflow, so a step that looked safe early can become unsafe later in the same run.
Security teams need a control point at the moment of decision, when identity, requested action, data access, tools, prior activity, and policy can still be evaluated before the action executes.
Discovery alone is not enough. Organizations can inventory agents and still lack a way to block or terminate a specific action in real time.
Exposure paths for agents are different from classic application exposure. They include over-permissioned tool access, weak identity binding, unsafe chaining of steps, and autonomous behavior that drifts from the original task.
Enterprises are deploying agents across many surfaces at once, including coding assistants, SaaS agent platforms, cloud model services, and custom internal agents, which creates inconsistent enforcement if controls stay siloed by product.
Incident response for agent failures requires more than logs of prompts and outputs. Teams need evidence of what the agent decided, why it was allowed to proceed, and where the run should have been stopped.
Vendor and platform diversity makes one-off guardrails hard to maintain. A decision-layer control that works across Copilot, Agentforce, Bedrock, custom agents, and coding tools reduces the gap between where agents run and where security can intervene.
Boards, security leaders, and regulators are increasingly asking not only whether AI was monitored, but whether the organization could prevent high-impact autonomous actions before they landed in production systems.
What AI Security Looked Like Before
Before platforms like this, most enterprise AI security sat around the edges of the model. Teams filtered prompts, scanned outputs, restricted which models employees could use, and collected logs after something had already happened. That approach worked better for chat interfaces and single-turn assistants than for agents that plan, call tools, and keep working across many steps.
Controls were also split by layer. Identity teams managed accounts. Application security watched code and APIs. Data security watched sensitive content. AI governance teams wrote policies and approval workflows. Few of those systems met at the exact moment an autonomous agent decided to take an action. If an agent had access to a tool and the step looked locally valid, the action often went through, and review came later.
Long-horizon behavior made the gap worse. An agent could complete a sequence of ordinary steps, each one allowed on its own, and still end in a harmful outcome. Post-event alerts, prompt logs, and model evaluations did not reliably stop that path in time. Security teams could often explain what happened after the fact. They had a harder time proving they could have blocked the decision before impact.
In practice, AI security before this shift was strong on visibility and weak on pre-execution authority. Organizations could discover shadow agents, rate model risk, and write acceptable-use rules. They still lacked a consistent way to evaluate a live agent decision against identity, policy, tool scope, data access, and execution history, then allow, block, or terminate that step before it became an enterprise action.
What AI Security Looks Like Now
Zenity’s release pushes the control point forward. The company is arguing that autonomous agent security has to operate at the decision layer: the moment an agent’s context and intent meet, just before the action runs. Runtime Boundaries are the mechanism it is putting there. Each requested action is evaluated in real time against identity, requested action, tools, data access, prior activity, and policy, then allowed, blocked, or terminated before business impact.
Exposure Management is meant to feed that runtime engine. Instead of only scoring agents after deployment, it prioritizes the attack paths most likely to be exploited and uses that prioritization to shape what Runtime Boundaries enforce. Zenity describes the loop as continuous: exposure informs runtime decisions, investigations improve policy, and stronger policy improves future protection.
The practical change is the timing of intervention. Security is no longer only asking what an agent already did. It is asking what the agent is allowed to do next. That matters for long-horizon agents whose risk appears across a chain of steps rather than in one obvious malicious prompt. It also matters because agents now operate across many environments at once, from coding tools and SaaS agent platforms to cloud model services and custom internal systems.
AI security is therefore moving from observation-first programs toward enforcement-first programs for autonomous action. Discovery, posture, and forensics still matter. The difference is that those functions are being tied to a control that can stop an agent decision before it lands. For security teams, the test becomes concrete: when an agent tries to act, can you evaluate that decision in context and prevent the step that should not proceed?
Our Take
AI Security Take
Zenity is making the right claim about timing. If an agent can write code, call tools, move data, and complete multi-step work on its own, security that only reviews prompts or alerts after the fact is already late. The useful control is the one that sits at the decision itself: can this agent take this action, with this identity, against this data, under this policy, right now?
Runtime Boundaries matter only if that evaluation is real. A policy page is not enough. The system has to see the requested action in context, compare it with prior steps in the same run, and be able to allow, block, or terminate before impact. Exposure Management matters for the same reason. Finding agents is not the same as knowing which paths are exploitable and feeding that into enforcement.
This is also where many current programs are thin. Organizations have invested in discovery, acceptable-use rules, and model monitoring. Fewer can prove they stopped an autonomous action at the moment it was about to execute. That gap is the one boards and incident responders will care about after the next agent-driven failure.
For security leaders, the practical test is simple. Inventory is step one. Decision-time enforcement is the control that changes outcomes. If your stack can explain what an agent did, but cannot prevent the next step it should not take, you are still running an observation program. The platforms worth evaluating are the ones that can answer, for each high-impact agent action: who authorized it, what evidence supported it, and what stopped it when the answer was no.
