Introducing Veto: security for the next era of software
Agent security is the bottleneck to scale your AI workforce.
We're excited to introduce Veto today to the Ona platform in early access, our kernel-level enforcement engine.
We told Claude Code to block npx using its own denylist. The agent found another way to run it and copied the binary to a new path using /proc/self/root to bypass the deny pattern. When Anthropic's sandbox caught that, the agent disabled the sandbox. No jailbreak, no special prompting. The agent just wanted to eagerly finish the task.
Every time a new class of actor enters computing, security starts at the wrong layer.
AI agents are no exception. Existing horizontal runtime security tools identify executables for enforcement by path, not content. That worked for containers. But containers do not reason about their own restrictions, agents do. We spent the past year solving for this problem. Because we own the kernel we can enforce at the syscall level, in the environment where agents work.
The attack surface is not just the prompt. It is every tool, file, and network connection the agent can reach. Intuit's ASTRA framework found that models resisting jailbreaks still broke rules during tool use, and techniques a skilled attacker chains over hours take an agent seconds.
The industry's current approach of bolting security horizontally across runtimes, kernels, and stacks you don't own will only get you so far. In the era of agents, you won't win that cat-and-mouse game.
We believe agent security has to be built into the platform agents run on. Brakes are designed into the chassis, not added by a third party. In the same way, agent security works best when it is native to the runtime, the kernel, the network boundary, and the domain agents operate in.
Any serious agent platform running autonomous workloads in high-consequence environments has to vertically integrate with defense in depth across the full stack.
Defense-in-depth
Over the last six months, we grew daily agent interactions 24x inside the networks of Fortune 500 banks, insurers, and pharma companies. We think about security as defense in depth across the full stack we own. Each successive layer is harder to build, and is more effective than the last.
The outer boundary. Runners deploy inside the customer's cloud. Source code and credentials never leave.
Layer 1: Platform hygiene inside your network
Zero-trust architecture, strong identities, secrets rotation, network segmentation is the floor. It defends against unauthorized access but says nothing about what an authorized agent does once inside.
Where agents run matters as much as how they are secured. An agent inside your network can query your databases, hit your internal APIs, and run your full test suite against staging. At Ona, runners deploy inside the customer's VPC. Source code and credentials never leave. Each agent gets its own VM with a dedicated kernel. Native network access, no tunneling. We wrote about why this matters two weeks ago.
Layer 2: Input and output guardrails
PII filtering, regex rules, LLM-as-judge systems. Using AI to guard AI is circular. HiddenLayer broke OpenAI's Guardrails within days. Cisco found multi-turn attack success rates averaging 64% across eight open-weight LLMs. Guardrail evaluations test single turns. Agent interactions do not stop at one turn. Application-level rules see the plan. The kernel sees the execution.
On our platform, this layer includes command deny lists, SCM restrictions, and tools like CrowdStrike Falcon in every environment.
Layer 3: Kernel-level enforcement
The Claude Code experiment at the top of this post shows what happens when enforcement lives above the agent. Denylists, sandboxes, path-based rules: the agent worked around all of them because it could see and manipulate the layer enforcing the rules.
The fix is to move enforcement below the agent's reach. Every file access, network connection, and process execution is a syscall. The kernel resolves the real path behind every symlink. Its enforcement is synchronous with execution. Because we own the kernel we can enforce at the syscall level, in the environment where agents work.
Introducing Veto
The enforcement engine for Layer 3 is Veto.
The hash and the policy check use the same kernel file reference, within the same syscall. For the exec gate, there is no gap between check and enforcement. The kernel returns -EPERM before the binary executes. The dynamic linker and mmap introduce subtler gaps that Leo shares in his technical deep dive.
Veto currently enforces at the exec gate. We will extend to network, file access, and memory primitives in the next quarter (you can see these grayed out in the diagram).
Today Veto is available in early access for a set of design partners with the strictest security requirements. Request early access →
What's next
Kernel-level enforcement is a necessary building block, but static rules are only the first step.
The industry needs what autonomous vehicle safety engineering perfected: a hard outer boundary defining absolute limits, plus a dynamic inner boundary that adjusts based on real-time behavior. For agents, the absolute limits are user-defined (repositories, tools, access to other systems) and enforced without exception. The inner boundary adapts: new agents start narrow, widen as they earn trust, and contract in sensitive areas or on errors.
Whatever form these techniques take, they depend on rock-solid boundary enforcement. Veto is that foundation.
Autonomy and security link directly. Productivity, innovation, faster time to market: all depend on the security posture of the orchestration platform agents run on. CIOs and CISOs need to be in the same procurement conversation, solving the same problem from different sides.
Every time a new class of actor entered computing, security moved down the stack. Agents are no different.
The only question is whether you move before or after something goes wrong.