Enforce authority before AI agents change code.
AI proposes. Humans decide. Evidence decides trust.
IX-BlackFox is a source-available AI engineering control plane for governed software change.
It sits between AI agents and consequential tools, treating model output as untrusted input until identity, delegated authority, scope, evidence, revision state, policy, and required human approval agree.
BlackFox is designed around a simple rule:
Capability is not authority. An AI agent being able to perform an action does not mean it is authorized to perform it.
Today, BlackFox provides a live MCP/API enforcement boundary with federated workload identity, delegated least privilege, revocation, evidence-conditioned authorization, human-gated execution, revision-bound verification, and public-key signed authority receipts committed before dispatch in configured Wave 16 mode.
Normal signed receipt appends now validate one transition; signing runs outside SQLite transactions. Retained checkpoints authenticate valid append-only extensions, evaluated and pre-evaluation denials receive semantic validation, and both legacy and v1 encoding contracts have fixed byte/hash vectors. Full replay remains available for recovery, audit and export.
Local Linux validation passes 1,784 tests on Python 3.11, 3.12 and 3.13, with Ruff, strict mypy and the 17-check real API/MCP proof passing on each. The local Ed25519 append microbenchmark remains about 1.1–1.3 ms through 5,000 existing receipts for one long-lived store. External connection commits and policy changes conservatively trigger full replay; sustained multiwriter scalability, production throughput and HA are not validated. Windows and remote GitHub CI were not run in this handoff.
See validation evidence, hardening contract, claims ledger and Windows handoff. Human approval remains HMAC-authenticated evidence, not independently attributable personal public-key signatures. The 0.4.0 validation snapshots are historical.
BlackFox governs AI-produced software changes before consequential tool execution.
Its current control surface includes:
- live pre-tool enforcement for configured MCP and HTTP API actions
- cryptographically verified short-lived workload identity
- configured issuer, audience, subject, token-time, key, and replay-related checks
- trusted external identity-to-agent binding
- bounded delegated authority
- delegation that may narrow authority but cannot expand its parent authority
- tool, repository, path, and expiration constraints
- durable token and delegation revocation
- registered agent capabilities and scopes
- repository and revision-bound evidence
- evidence freshness and provenance checks
- policy-shaped human approval where required
- exact action-subject binding
- sandbox and repository-impact controls
- deterministic evidence packaging
- independent verification
- machine advisories with no human voting authority
- required signed authorization committed before governed upstream dispatch
- linked signed outcome observations and unresolved-authorization reporting
- independent pinned-key and expected-checkpoint verification
- transactionally hash-chained authority receipts
- receipt lookup and independent chain verification
- fail-closed behavior when required trust material is missing or invalid
The goal is not to make AI agents more autonomous.
The goal is to make increasingly capable agents bounded, attributable, inspectable, revocable, and governable.
flowchart TD
Request["AI action request"] --> Gates["Identity, delegation, scope, evidence and human approval"]
Gates --> Verdict{"Authorized?"}
Verdict -->|No| Deny["Deny before dispatch"]
Verdict -->|Yes| Sign["Reserve approval; sign and commit authorization"]
Sign --> Fresh{"Current authority and signing trust valid?"}
Fresh -->|No| Stop["Refuse dispatch; report unresolved authorization"]
Fresh -->|Yes| Upstream["Dispatch configured upstream"]
Upstream --> Outcome["Commit linked signed outcome observation"]
Outcome --> Audit["Export; verify with pinned keys and retained checkpoint"]
This path describes configured Wave 16 cryptographic mode. Historical configurations without [receipt_signing] retain their original unsigned receipt format.
BlackFox is intended to make the answer to these questions inspectable:
- Who is this workload?
- Which registered agent does that identity represent?
- Who delegated authority to it?
- What tool may it invoke?
- Which repository may it affect?
- Which paths may it touch?
- Which exact revision does the evidence describe?
- Is the evidence authentic and current?
- Is human approval required?
- Is that approval bound to this exact action?
- Has the identity or delegation been revoked?
- Did a denied request reach the upstream?
- What actually executed?
- Can the resulting authority record be independently checked?
The Wave 16 local proof uses real HTTP sockets, a fresh RS256 workload identity, an encrypted Ed25519 authority key and two real file writes. Before each API/MCP write, a separate database connection and public-key verifier confirm that its authorization was committed and covers the exact arguments. All temporary private state is removed before a separate process verifies the public export.
| Exercised behavior | Local proof result |
|---|---|
| Unauthenticated request | HTTP 401; zero upstream calls |
| Missing evidence | HTTP 428; zero upstream calls |
| Delegated scope escape | HTTP 403; zero upstream calls |
| Authorized API and MCP actions | Two independently witnessed file writes |
| Reused single-use approval | HTTP 409; no additional dispatch |
| Signing unavailable | Readiness false; HTTP 503 before dispatch |
| Revoked workload identity | HTTP 401; no additional dispatch |
| Modified receipt or truncated snapshot | Rejected by public verifier |
| Public verification after private state removal | Passed |
The current proof emits nine signed receipts and seventeen checks. The IdP, CI evidence and human reviewer are local synthetic fixtures. AWS KMS, physical HSM and Sigstore service use are explicitly NOT_RUN in this local proof.
From the extracted repository root in PowerShell:
py -3.13 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev,aws-kms]"
.\.venv\Scripts\python.exe scripts/run_wave16_crypto_authority_ci.py --root .
.\.venv\Scripts\python.exe -m ix_blackfox.authority_crypto.cli verify --bundle .blackfox-artifacts/wave16/authority-bundle.json --trust-policy .blackfox-artifacts/wave16/trust-policy.json --checkpoint .blackfox-artifacts/wave16/external-checkpoint.jsonFor Bash, use python3 -m venv .venv and .venv/bin/python in place of the PowerShell interpreter path. Four public JSON artifacts are written under .blackfox-artifacts/wave16.
The co-packaged demo checkpoint is a verification fixture. Actual rollback protection requires an expected checkpoint retained independently of the gateway and bundle. The trust policy also needs authenticated independent provisioning. See Wave 16 deployment and claim boundaries.
Historical Wave 15 identity proof remains available:
.\.venv\Scripts\python.exe scripts/run_wave15_enterprise_identity_ci.py --root .Authenticating an AI agent answers only part of the problem.
BlackFox separates:
| Control | Question |
|---|---|
| Identity | Who is making the request? |
| Authority | What may that identity do? |
| Delegation | Who granted the bounded authority? |
| Scope | Which tools, repositories and paths are permitted? |
| Evidence | What verified information supports this action? |
| Human approval | Does the policy require an accountable human decision? |
| Revocation | Is previously granted trust still valid? |
| Receipts | Can the endorsed decision and observed outcome be independently verified? |
A valid identity does not automatically receive tool authority.
A valid delegation cannot expand beyond its parent authority.
Valid evidence does not automatically replace required human approval.
A capable model does not approve itself.
For configured consequential actions, BlackFox is designed to deny before forwarding when required conditions are not satisfied.
Examples include:
- missing or invalid workload identity
- untrusted issuer
- wrong audience
- expired or not-yet-valid token
- unrecognized identity binding
- revoked token
- missing delegation
- revoked delegation
- expired delegation
- delegation outside permitted scope
- unregistered capability
- repository mismatch
- path-scope violation
- missing required evidence
- invalid evidence authentication
- revision mismatch
- stale evidence
- missing required human approval
- approval bound to the wrong action subject
- receipt-chain integrity failure during required startup verification
Denied configured tool actions are not supposed to become upstream side effects.
BlackFox does not treat machine confidence, model output, or machine review as human authorization.
The review-board layer supports role-separated human review while preserving machine analysis as advisory.
Machine advisories are non-authoritative and carry zero voting authority.
Human review can be bound to:
- the exact evidence subject
- review policy
- reviewer identity evidence
- role-authority evidence
- the exact review decision
- conflict and recusal rules
- required quorum and role coverage
This preserves the project's governing principle:
AI proposes. Humans decide. Evidence decides trust.
BlackFox uses content-addressed, revision-bound evidence rather than treating a passing test result as universally reusable approval.
The evidence architecture can bind assurance material to:
- repository
- revision
- policy
- action subject
- provenance
- verification result
- review state
- human authority
- chained execution receipts
Changing the governed subject can invalidate the authority derived from evidence for the previous subject.
BlackFox does not rely solely on a producer saying its own package is valid.
The project includes independent verification paths that reopen serialized evidence and recompute important integrity and semantic properties.
Depending on the evidence layer, verification includes controls such as:
- canonical representations
- content digests
- deterministic packaging
- safe archive paths
- bounded archive expansion
- nested evidence verification
- revision binding
- policy binding
- review binding
- semantic recomputation
- ledger verification
- receipt-chain verification
Self-consistent hashes alone are not treated as sufficient proof when semantic verification is required.
The gateway applies the enforcement path above to configured consequential tools. Wave 16 adds the signing providers, separately pinned public trust, signed authorization/outcome stream and public export verifier to the existing identity, evidence and human-authority controls. The system architecture and Wave 16 contract describe the implementation and deployment boundaries.
The Wave names below are retained as stable repository and documentation contract identifiers.
Configured gateways commit a public-key signed authorization before dispatch and link a signed outcome afterward. Independent verification uses pinned keys and can compare the export with an independently retained expected checkpoint. Encrypted local keys, KMS, PKCS#11 and explicit Cosign adapters are implemented with fail-closed behavior. External service use, physical custody, independent production retention and remote CI remain separately validated deployment responsibilities.
Adds cryptographically verified workload identity, trusted agent binding, bounded delegation, expiration, narrowing, and revocation.
A valid workload identity does not automatically receive tool authority. Delegated authority may narrow its parent scope but cannot expand beyond it.
See:
Wave 15 Enterprise Identity & Delegated Authority
Provides a live request-path enforcement surface for configured MCP and HTTP API tool calls.
It evaluates authority before forwarding to the configured upstream. Configured requests that fail the authority boundary are denied before upstream execution.
See:
Wave 14 Live Authority Gateway
Keeps machine analysis visible while reserving binding approval authority for configured human review roles.
Machine advisories remain non-authoritative and carry zero voting authority. Human decisions can be bound to the exact evidence subject, policy, reviewer authority, and review content.
See:
Wave 13 Human-Machine Review Board
Provides the revision-bound, content-addressed evidence foundation used by later BlackFox authority layers.
It produces deterministic evidence packages and supports independent verification rather than relying only on producer-generated claims.
Here, certification-ready describes the structure and verification posture of the evidence package. It does not mean BlackFox or a consuming organization is certified.
See:
Wave 12 Certification-Ready Evidence
The primary CI matrix covers:
- Python 3.11
- Python 3.12
- Python 3.13
- Ruff
- mypy
- pytest
- dedicated evidence and authority workflows for major BlackFox control layers
Wave 16 adds a dedicated Ubuntu/Windows matrix across Python 3.11–3.13, with lint, strict typing, the complete suite and real local signed-authority proof. The workflow is configured; remote GitHub execution was not performed in this handoff. Wave 15 proofing remains available.
Treat current GitHub Actions results and VALIDATION_REPORT.md as the source of truth for current validation status rather than relying on a static test-count claim in this README.
Install development dependencies:
python -m pip install -e ".[dev,aws-kms]"Run Ruff:
python -m ruff check .Run mypy:
python -m mypy srcRun the complete test suite:
python -m pytest -qBlackFox was built incrementally, but the README describes the current system, not a chronological feature dump.
Major recent milestones:
| Generation | Capability |
|---|---|
| Wave 16 | Cryptographic Authority Receipts & Externally Anchored Trust |
| Wave 15 | Enterprise Identity & Delegated Authority |
| Wave 14 | Live Authority Gateway |
| Wave 13 | Human-Machine Review Board |
| Wave 12 | Certification-Ready Evidence Packaging |
The individual architecture and validation documents retain the detailed contracts and boundaries for each layer.
IX-BlackFox is not:
- a replacement for accountable human review
- an external assessor
- an enterprise identity provider
- a general OIDC/OAuth/IAM federation service
- a human identity-proofing service
- a qualified digital-signature service
- a production high-availability reverse proxy for every MCP method or transport
- a production authorization or deployment authority
- a certified compliance product
- FedRAMP authorized
- an ATO or cATO issuer
- DoD approved or endorsed
- AWS approved or endorsed
- an external transparency log
- a claim of formal verification
- a guarantee of software correctness
- an autonomous human-equivalent approval system
BlackFox is a platform-neutral, evidence-bound control plane and research implementation for making AI-assisted engineering actions more attributable, constrained, inspectable, reviewable, revocable, and governable.
Its evidence packages and authority receipts can be consumed by CI, artifact storage, assessment, cloud, and other integration layers without implying that those external systems have approved or certified BlackFox.
BlackFox evidence work includes bounded conceptual mappings to frameworks including:
- NIST SP 800-218 SSDF 1.1
- NIST AI RMF 1.0
- NIST OSCAL Assessment Results
- SLSA 1.2
- in-toto Statement v1
These are mappings only.
They do not constitute certification, accreditation, conformity, an ATO, a cATO, a SLSA level claim, government approval, or external endorsement.
IX-BlackFox is source-available for technical evaluation under the repository license.
Unless a separate written commercial license says otherwise, public visibility does not grant permission for commercial use, production use, hosted-service use, contractor use, funded operational use, derivative operational use, procurement use, or resale.
See LICENSE for the controlling terms.
See COMMERCIAL.md for commercial-use information.
Key documents:
IX-BlackFox was originated and created by Bryce Lovell.
AI proposes. Humans decide. Evidence decides trust.