Skip to main content
Available on the Enterprise plan. Contact sales to learn more.
Veto Exec audits or blocks selected executables in organization environments. Start with audit rules, review matches, then promote confirmed rules to block. The public Veto Exec contract uses only SecurityPolicy.spec.executables. Ports, files, block devices, and data are not part of this contract.

​
Configure Veto in the dashboard

Open Settings → Security → Veto. Add an executable path or bare name, choose Audit or Block for each rule, and save. An empty rule list has no executable effect. Saving changes only the executable rules on the organization’s default SecurityPolicy; other policy sections are preserved. Restart a test environment to apply the changed default. Preview supports policies whose rules all use the same effect. Save mixed Audit and Block rules, then restart a test environment to verify them together.

​
Create an audit-first policy

Save this policy as veto-exec-policy.yaml:
defaultEffect controls executables that do not match a rule. Omit it or set it to EFFECT_ALLOW. Each rule must use EFFECT_AUDIT or EFFECT_BLOCK. An executable rule cannot use EFFECT_ALLOW. Each rule path must be one of these selector forms:
  • An absolute path, such as /usr/bin/curl
  • A bare executable name, such as npx
Bare names are expanded to concrete executable paths through runtime discovery. Surrounding whitespace is ignored. Empty or whitespace-only selectors, ., .., ./npx, and relative paths such as tools/npx are invalid after trimming. Validate the file:
Create the policy in the active organization:
Creation stores an inactive policy definition. The CLI validates file input before sending it, but the management plane’s authoritative materializability check runs on default assignment. An unassigned policy can later be rejected when assigned. Copy the returned policy ID and assign it as the organization default:
If assignment rejects the stored definition, correct its executable default, rule effects, or selectors, update it, and retry. Successful creation alone does not prove that the policy can activate. New environments receive the assigned policy. Restart an existing environment to apply the current organization default. An already-running environment keeps the policy from its last start.

​
Review audit and block matches

During the interim rollout, organizations with the Veto Exec Audit Logs preview enabled can review matching audit and block events in organization Audit Logs. Filter by the test environment while you evaluate an audit rule:
The action starts with Veto Exec audited or Veto Exec blocked and includes the reported filename and full executable digest when available. Audit rules allow execution. Block rules deny execution.

​
Promote an audit rule to block

Change the confirmed rule in veto-exec-policy.yaml:
Update the policy:
Restart a test environment, run the executable, and confirm that execution is denied. If the organization has the Veto Exec Audit Logs preview enabled, also confirm that a Veto Exec blocked entry appears in Audit Logs.

​
Understand Veto protection and content identity

Block rules do more than deny execution. Veto’s built-in untouchable protection also blocks direct reads and copies, writes, opens that could modify the file, and writable shared-memory mappings of enrolled executable content. Veto watches supported content and lifecycle changes, then refreshes the enrolled content identity while preserving the rule’s audit or block effect. An executable path or bare name is a persistent selector that represents policy intent, not a one-time hash input. Veto resolves matching executables and uses their SHA-256 content identity for runtime decisions. While a content hash remains enrolled, unchanged bytes retain the same decision when they are:
  • Moved or renamed. Changing the file’s path does not change its content identity.
  • Reached through a hard link. The link resolves to the same unchanged content.
  • Copied byte for byte. An identical copy has the same content hash.
  • Invoked through a symlink. A symlink to the same target reaches the same unchanged content.
A later complete refresh of an exact-path selector may remove the old hash if the selector no longer resolves. A bare-name selector may instead rediscover matching basenames at new concrete paths. Changing the executable’s bytes creates a different content identity. Audit rules allow and record activity. Veto’s continuity handling is best effort: a supported change is refreshed when Veto observes it, but filesystem changes outside that observation flow are not guaranteed to preserve coverage without a later complete refresh. Different paths can resolve to identical executable content. If one resolved hash has both audit and block rules, block wins for every path with that hash. Choose hash-distinct executables when testing mixed audit and block rules. Veto safelists Ona runtime binaries by content hash and cannot block them. If Veto cannot resolve and hash a selector, the rule cannot enforce that content. If the kernel cannot compute an executable hash for a launch because of an internal failure, execution is allowed.
Blocking a shell interpreter such as /bin/bash also blocks scripts that use that interpreter and can make an environment unusable. Test interpreter rules in audit mode first.

​
Roll back the organization default

Clear the default assignment:
Restart affected environments to remove the cleared default policy. Clearing the default does not change an already-running environment. The command deny list applies pattern rules to Ona Agent commands in userspace. Veto Exec applies content-hash decisions in the kernel to executable launches from any process in the environment.