Automic Vault

Automic Vault 4.18.0 · macOS

Blessed Scripts

Review exact script contents, declare capability ceilings, and choose which Launchers may use the Blessing.

Blessed Scripts

A Blessing binds a reviewed script to its canonical path, SHA-256 digest, interpreter, Script Declaration, Secret Names, declared Capabilities, and optional Launcher Endorsements. The app shows the exact enrolled state and can revoke or replace it.

Blessed deployment script with digest, Secret Names, capabilities, and calling-app policy

Verified execution

Scripts are mutable text and usually run through a powerful interpreter. Automic Vault therefore approves a verified snapshot rather than trusting the filename. Execution normally uses a checked /dev/fd/N snapshot. If the interpreter cannot execute that snapshot, you may accept canonical-path execution during Blessing review. That exception warns on every run because same-user code can edit the file between verification and execution. Existing Blessings need a new review to acquire it. AV_SCRIPT_PATH and AV_SCRIPT_DIR identify the canonical source.

Create and review

Put the absolute av inject shebang first, place the optional Script Declaration immediately after it, review requested Secret Names and capability ceilings, then run av bless PATH. Use --endorse-launcher only when the exact Verified Launcher should receive automic authorization for the script.

Use the installed absolute path to av in the shebang. For a script that calls hardened GitHub commands, request the Tool-specific capability without injecting a raw token into the shell:

#!/usr/local/bin/av inject -- /bin/sh
# --- automic-vault
# capabilities:
#   gh: read-only
# ---
set -eu
gh repo view automic-vault/automic-vault --json name,url

Save it as repo-info.sh, review every command and dependency, then run:

chmod +x ./repo-info.sh
av bless ./repo-info.sh
./repo-info.sh

To let the current Verified Launcher use the reviewed Blessing's automic authority, review av bless --endorse-launcher ./repo-info.sh. Without a Launcher Endorsement, the Blessing itself grants that Launcher no automic authority. Existing inherited authority still follows the declaration.

Changes and revocation

Editing, replacing, or moving the script invalidates the Blessing. Re-blessing is a new security decision; review the displayed diff. Revocation removes policy but does not undo external actions from earlier runs.

Capability ceilings

A capability is a ceiling, not a grant. A blessed script can still misuse every operation inside its approved ceiling, and an interpreter remains a large Target. Keep scripts short, deterministic, and narrow.

Without a capabilities manifest, a script inherits its execution context's automic authority. capabilities: { inherit: true } makes this explicit. capabilities: {} instead blocks inherited automic authority, including Launcher policy, Direct Access Rules, outer Blessings, and Temporary Access Grants, for later gated operations attributable to that live execution. The script's own requested Secrets still need separate authorization. This ceiling does not sandbox ungated commands or survive loss of observable script ancestry.

Agent workflows

For a workflow that pauses for agent judgment and resumes deterministic work, see Reentrant Blessed Scripts. Keep agent output as validated data and keep Secret Values out of handoff prompts and state files.

See also the CLI reference, app controls, and the canonical reviewed automation definitions.