Choose whose Launcher rule applies

Terminal: Write Access
  └─ agent: Read Only
       └─ gh issue create → Approval required

Automic Vault normally uses the nearest Verified Launcher with an explicit Access Level. An intermediary without one does not displace that rule. A shell between your agent and gh therefore does not, by itself, change which rule applies.

The override option defaults off for both new and existing rules. Upgrading does not opt your terminal into overriding agents.

Suppose you use a verified harness for research. Give it Read Only at the GitHub gate and enable its override:

harness: Read Only + override
  └─ agent: Write Access
       └─ gh issue create → Approval required

The harness’s rule now takes precedence over the agent’s Write Access. That same agent can still use its own rule when you run it outside this ancestry.

You can also choose the reverse:

harness: Write Access + override
  └─ agent: Read Only
       └─ gh issue create → automically authorized

This grants broader access for that operation. Automic Vault records an override warning in Authorization History and shows it in automic notifications when a child’s explicit rule would have required Approval.

These examples assume valid live identities, accepted runtime protections, a recognized operation, and no other denial or independent authority source. If several ancestors have eligible overrides, the outermost one supplies the rule. Check the whole verified chain before enabling an override on a terminal you use for many unrelated tasks.

1. Open Authorization Gates and choose the Tool’s gate.
2. Add or select the harness’s Verified Launcher rule and choose its Access Level.
3. Enable Override descendant Launcher rules.
4. Choose Review Changes, inspect the change, and approve it.

The setting affects only that Launcher at that gate. It does not change the harness’s access to other Tools. A denial-only row cannot supply an override.

Your harness needs a verifiable identity first. An eligible vendor-signed executable can qualify on its own. For an unsigned single-file native CLI, see our Launcher Bundle quickstart. Packaging establishes an identity for the artifact; it does not make the code trustworthy.

harness: Write Access + override
  └─ agent: Deny
       └─ gh issue create → denied

An override cannot bypass a matching explicit denial. Automic Vault also keeps the runtime requirements on the explicit rules it overrides. Unknown operations still require Approval unless policy denies them.

The Mac verifies live original-parent execution links between the overriding ancestor and the nearer Launcher. A helper association for the same process, or retained attribution after a parent exits, cannot prove that relationship. If the required override evidence is missing, Automic Vault requires Approval rather than falling back to a child rule that might allow more.

This changes precedence among Launcher Access Levels. Direct Access, Blessings, and Temporary Access Grants keep their own authority rules. A restrictive override is not a universal authority ceiling, and it does not sandbox commands that never reach an Automic Vault gate.

Return to the research harness: Read Only on the parent, Write Access on the child. Disable the parent’s override and the child can write under its own rule again. That change broadens authority.

We therefore require Approval in both directions, including when you remove an enabled override rule. Launcher Bundle replacement and removal cannot silently delete these rules during cleanup. Remove the rule through the gate’s reviewed flow first.

Each SSH key now has its own Authorization Gate and policy. You can allow an agent to authenticate with a GitHub key while requiring Approval for a separate homelab key. A key’s name does not restrict destinations; register distinct keys with those services.

SSH still uses the nearest Verified Launcher for its default-denial check. If that Launcher has no explicit rule and the key’s Default Policy denies access, an upper ancestor’s override cannot bypass it. Ordinary ancestor rules do not supply SSH fallback access either.

Choose the Launcher that should supply policy, scope the choice to the gate, and inspect History to confirm the result. The manual covers setup, and ADR 0065 records the security decisions. The canonical domain definition and architecture define the policy semantics.