WarrantKit

Authority that expires when the runtime state that created it changes.

WarrantKit binds an execution's authority to accepted policy, runtime identity, and runtime epoch. When the controller advances that epoch during containment, retained pre-containment authority no longer matches current runtime state.

WarrantKit is the authority/lifecycle layer; AgentContainment is the external runtime enforcement engine.

First proof: replay a stale Warrant

Install the package and run the stale-Warrant replay proof:

python -m pip install --upgrade warrantkit
warrantkit demo

The proof retains a serialized copy of an active Warrant, reads the current epoch from the AgentContainment controller runtime, performs containment, and verifies that the retained pre-containment Warrant is rejected against the advanced epoch. It needs no root privileges, LLM, LangChain, source clone, or submodule checkout.

To see the simulated incident-lifecycle walkthrough instead, run warrantkit demo lifecycle. That walkthrough explicitly reports that host enforcement verification is not claimed.

The default demo proves verifier rejection against runtime state in one Python process. It does not prove that the controller is isolated from the verifier or that the controller state is protected from a compromised host. Those are deployment and host-boundary assumptions; see the threat model. For kernel-enforced workload termination, use the separate privileged Linux proof.

Boundary, stated plainly

The process that runs the agent must not hold credentials that let it perform protected side effects without the enforcement boundary. Payment API keys, database credentials, cloud credentials, and equivalent secrets must be held by the trusted gateway/controller or by a downstream service that independently enforces the same authorization. If the agent can call the downstream API directly with its own unrestricted key, the gateway is advisory and WarrantKit cannot prevent that bypass. The proof runs the controller and verifier in the same Python process; controller isolation is a deployment/host-boundary requirement, not something this snippet demonstrates.

WarrantKit's Warrant is a typed authority contract, not currently a bearer credential consumed directly by AgentContainment's ActionGateway. The gateway enforces controller-owned execution leases. A serialized or unsigned Warrant is not self-authenticating; Ed25519 attestation is available when a deployment configures a trusted public-key anchor.

What epoch fencing adds

Epoch fencing is a form of fencing token, a known distributed-systems pattern: a resource checks a monotonically advancing generation so work from an earlier owner or runtime state is rejected. See Martin Kleppmann's explanation of fencing tokens.

A revocation list can also invalidate a credential immediately when every enforcement point checks it. The distinction is not “epoch is immediate, revocation is delayed.” Instead:

• Per-Warrant revocation tracks individual credentials and requires the relevant revocation state to be available and checked.
• Epoch fencing invalidates every retained Warrant from an older runtime generation by comparing against one controller-owned epoch, without tracking every copy individually.
• Expiry bounds validity by time; it is useful as a separate defense, not a substitute for either revocation or epoch checks.

In the framework proof, explicit revocation can cause the first rejection. The first proof above isolates the epoch mismatch by retaining an active serialized copy while the controller advances the runtime epoch.

Second act: framework tool, then external containment

The deterministic framework proof uses a real LangChain tool but no LLM, network call, or API key. It invokes the protected tool before containment, advances the external runtime state, then proves that the retained authority is rejected before the second side effect can run.

git clone --recurse-submodules https://github.com/Therealdk8890/WarrantKit.git
cd WarrantKit
python -m pip install ".[langchain]"
python tools/run_authority_boundary_demo.py

Expected proof properties:

• the first protected tool call executes;
• external containment advances the runtime epoch;
• the retained pre-containment Warrant is rejected;
• the second protected call does not reach the underlying side effect.

This does not prove universal host isolation, reversal of completed side effects, or that a serialized Warrant is itself an ActionGateway credential.

What WarrantKit is — and is not

A Warrant binds one execution to accepted policy identity and digest, runtime identity and epoch, validity, capabilities, constraints, and evidence requirements.

• Warrant = authority.
• Evidence = what was observed or produced.
• Verification = whether defined checks succeeded.
• Receipt = a record of evidence and its stated authentication status.

Evidence never grants authority. Verified does not mean an external claim is true.

The current egress path is not a general destination-policy engine: a deny-all egress rule can act as a kill switch, but it does not implement an allowlist of approved destinations. See the egress binding contract.

WarrantKit is not a sandbox, a universal host-isolation guarantee, a secret manager, a mechanism for reversing completed side effects, or a replacement for IAM, policy engines, cgroups, or independent provenance verification. It complements those controls by binding execution authority to runtime state and fencing stale authority after a security event.

How WarrantKit differs

Start here

• Threat model
• Real-kill demo requirements
• Implementation status: CI-tested versus planned
• Extended integrations, evidence, and proof documentation
• AgentContainment security contract

License

Apache-2.0.