Agentic Action Authority

Approve one exact agent action. Reject changed bytes. Recover without replay.

A small, host-integrated Python component for applications where an AI proposes a document but an operator must approve its exact content and destination before the application writes it. No model or network call is in the approval path.

The first supported effect is a create-only UTF-8 file, through the optional Agentic Security Harness adapter. The approval core can be installed without Harness; custom effect adapters are trusted application code and require their own effect/recovery tests.

Version 0.2.0 adds the installed DocumentHost onboarding API. Check the 0.2.0 package page and release evidence for availability and exact release evidence; source or package metadata alone does not establish publication. The published 0.1.1 release does not contain DocumentHost. Installing never enrolls an operator or authorizes an action.

What it changes

Your agent proposes text. Your host fixes the action, destination, policy, dependency digests and deadline. An operator reviews the exact request and signs it outside the agent's environment. The host verifies that signature before admitting one attempt. Changed text, an old approval or a repeated submission cannot silently become a new authorized action.

This is not a content filter: approval does not prove that text is true or free of prompt injection. It is not a sandbox for arbitrary Python or a compromised host, and does not promise universal exactly-once effects. See security boundaries.

Start with one document

Requirements: Python 3.11; lock targets are Windows x64 and Linux x86_64 with glibc 2.28+. Use a local filesystem with working SQLite locks, not an unverified network/FUSE filesystem. After confirming 0.2.0 is available on the index, use a new virtual environment:

python -m venv .venv
# Use .venv/Scripts/python.exe on Windows, .venv/bin/python on Linux.
<python> -m pip install "agentic-action-authority[harness]==0.2.0"
<python> -m pip check

Omit [harness] for the standalone approval core. The file adapter deliberately pins Harness 1.14.2. Other Harness versions are not automatically a supported pairing; compatibility evidence belongs to the exact installed checks below.

DocumentHost onboarding API in 0.2.0

DocumentHost composes the installed create-only file path for a trusted host. It requires an operator fingerprint obtained through an independent trusted channel and the host application's owner/repository plus exact revision. These are bound declarations, not remote Git attestation. The host prepares the task, transfers exact request and content for separate operator signing, applies the decision, and gives the agent only a content-only callback. It never generates an operator key or signs on the agent's behalf.

Use the 0.2.0 integration guide or one-document path with a verified 0.2.0 installation. Setup now requires --expected-key-fingerprint and --host-repository on the CLI (or expected_key_fingerprint and host_repository in Python). An existing 0.1.1 task is not automatically migrated or overwritten; see the upgrade notes. The external developer exercise is proposed, not completed. The approval alternatives compare documented contracts, not benchmark or adoption results.

For an auditable checkout build and hash-locked installation of the exact source currently checked out:

python -m venv .venv
# Use .venv/Scripts/python.exe on Windows, .venv/bin/python on Linux.
<python> -m pip --isolated install --require-hashes -r requirements/build.txt
<python> -m build --no-isolation --wheel --outdir dist
<python> -m pip --isolated install --only-binary=:all: --require-hashes -r requirements/<windows-or-linux>.txt
<python> -m pip --isolated install --no-index --no-deps dist/agentic_action_authority-0.2.0-py3-none-any.whl
<python> -m pip check

For the Harness-free core, use requirements/core-windows.txt or requirements/core-linux.txt instead. The file CLI needs the optional Harness dependency; the core alone does not supply a file writer.

Follow the 0.2.0 one-document guide: prepare → review/sign → apply decision → write → read back. Operator signing is interactive. Private keys and passphrases never belong in chat, an agent prompt or command-line arguments.

The older 0.1.1 release notes remain historical evidence; do not apply 0.2.0 setup instructions to a 0.1.1 wheel.

Embed in your agent application

The routing example content_only_dispatch.py accepts only submit_approved_document({"content": "..."}), rejects paths and approval fields, and reports uncertainty without retrying. The host creates and retains an ActionGate, enrolls the operator public key and applies signed decisions separately. Give the model only the content-only callback, not the gate, signer or unrestricted filesystem/Python access.

See architecture and adapter contract for ActionCore, ActionGate, protocol domains, state transitions and adapter obligations. For 0.2.0 DocumentHost integration, use the versioned integration guide, not private host helpers. The content_only_dispatch.py example is the lower-level ActionGate compatibility route; DocumentHost is the shorter public host composition.

Verification and provenance

The verification guide separates base-only installation, optional-adapter checks, source/wheel byte identity and platform results. Tests use disposable signatures and files; they do not constitute human acceptance. The 0.2.0 release evidence records the exact tag and index receipts after publication. The immutable version scope does not itself prove that an index upload succeeded. The source provenance identifies the original Harness candidate. Historical results are not automatically results for this distribution. The release procedure binds one tag-built wheel to staging, publication and downloaded-index checks; a read-only check is not an upload.

One project owns the approval core here. Harness owns its file writer and broader security laboratory. There is no second copied writer or circular dependency. Apache-2.0; see LICENSE and NOTICE.