Skip to main content
Requires Enterprise plan. Currently in early access behind a feature flag.
Prevent specific binaries from executing inside environments. Useful when:
  • Blocking known-risky or unauthorized tools (e.g., npx) across all environments in your organization
  • Enforcing software supply chain policies by preventing dropped binaries from executing
The OWASP Top 10 for Agentic Applications identifies Unexpected Code Execution (ASI05) and Supply Chain Vulnerabilities (ASI04) as top risks for agentic systems. The executable deny list addresses the binary execution aspect of these risks: when an agent, prompt injection, or supply-chain payload attempts to run a known-bad executable, the kernel blocks it regardless of how the execution was triggered.

​
How it works

Veto identifies executables by their SHA-256 content hash, not by filename. Enforcement happens entirely in-kernel at the point of execution. This means:
  • Rename-resistant. Renaming or copying a blocked binary does not bypass the policy.
  • Symlink-resistant. Invoking a blocked binary through a chain of symlinks does not bypass the policy.
  • TOCTOU-free. The hash check and the enforcement decision happen on the same kernel file reference in the same execve call.
This is different from the command deny list, which operates at the agent level in userspace and matches commands by pattern. The executable deny list enforces at the kernel level and matches binaries by content.

​
Enforcement modes

Each deny list operates in one of two modes:
ModeBehavior
BlockExecution is denied (EPERM). An event is emitted.
AuditExecution is allowed. An event is emitted.
Use audit mode to understand what would be blocked before switching to block mode. The mode applies to the entire deny list. Per-executable mode selection is not supported in this version.

​
Safelist

Ona runtime binaries (supervisor, CLI, SSH) are safelisted by content hash at build time. The safelist always overrides the deny list, so these binaries cannot be blocked. The safelist is read-only and managed by Ona. It cannot be modified.
Blocking a shell interpreter (e.g., /bin/bash) blocks all scripts that use it and can render the environment unusable. Shell safelisting is planned but not yet implemented. Take care when adding interpreters to the deny list.

​
Event reporting

Every execution that matches the deny list produces a structured event, regardless of whether the mode is block or audit. Events include:
  • SHA-256 digest of the binary
  • Kernel-resolved file path
  • Enforcement action taken (block or audit)
  • Process metadata (PID, command line, parent PID, session ID)
  • Timestamp
Events are written to environment logs and reported to the management plane.

​
Fail-open behavior

If the kernel cannot compute the content hash for an execution (e.g., due to an internal error), the execution is allowed. The system does not block environments due to its own failures.

​
Configuration

  1. Go to Settings → Organization → Policies
  2. Toggle Enable Executable Deny List
  3. Choose the enforcement mode (Block or Audit)
  4. Enter executable paths, one per line (maximum 20 entries)
  5. Click Save Changes
Paths should be absolute (e.g., /usr/bin/wget). When the policy is applied to an environment, the system resolves each path (following symlinks, translating container paths to host paths) and hashes the binary found there. The system identifies each binary by the SHA-256 hash of its content, not by its path.

​
Preview before saving

Test your deny list against a running environment before committing the policy org-wide:
  1. Enter executables in the textarea (saving is not required)
  2. Click the Preview in… dropdown and select a running environment
  3. The config is applied immediately to that environment only
  4. Open the environment to verify the expected binaries are blocked
  5. Modify the list and re-apply as needed. A warning indicator appears when the textarea changes after a preview
Preview applies the deny list to a single environment only. It does not affect the saved organization policy or other environments.

​
Effect on environments

  • New environments receive the deny list on creation
  • Restarted environments receive the latest deny list on start
  • Already-running environments are not affected by org policy changes. They keep the deny list they received at start time