> ## Documentation Index
> Fetch the complete documentation index at: https://ona.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Veto Exec executable policy

> Audit or block specific executables in organization environments with kernel-level enforcement.

<Note>Available on the Enterprise plan. [Contact sales](https://ona.com/contact/sales) to learn more.</Note>

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`:

```yaml theme={null}
metadata:
  name: Veto Exec audit-first
spec:
  executables:
    defaultEffect: EFFECT_ALLOW
    rules:
      - path: npx
        effect: EFFECT_AUDIT
      - path: /usr/bin/curl
        effect: EFFECT_BLOCK
```

`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:

```bash theme={null}
ona organization security-policy init veto-exec-policy.yaml --validate-only
```

Create the policy in the active organization:

```bash theme={null}
ona organization security-policy create veto-exec-policy.yaml -o yaml
```

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:

```bash theme={null}
ona organization security-policy set-default <security-policy-id>
```

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](/docs/ona/audit-logs/overview). Filter by the test environment while
you evaluate an audit rule:

```bash theme={null}
ona audit-logs --subject-id <environment-id> --subject-type environment
```

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`:

```yaml theme={null}
- path: npx
  effect: EFFECT_BLOCK
```

Update the policy:

```bash theme={null}
ona organization security-policy update <security-policy-id> veto-exec-policy.yaml
```

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.

<Warning>
  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.
</Warning>

## Roll back the organization default

Clear the default assignment:

```bash theme={null}
ona organization security-policy set-default --clear
```

Restart affected environments to remove the cleared default policy. Clearing
the default does not change an already-running environment.

## Related controls

The [command deny list](/docs/ona/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.