Sworn
Deterministic, fail-closed AI code governance. Every commit is sworn.
Sworn is a Python CLI that installs Git pre-commit hooks in the repository's effective hooks path, runs a configurable gate pipeline on local commit checks and CI diff checks, and produces tamper-evident evidence logs.
Cross-tool enforcement for any AI coding tool that commits through git.
How it enforces: the enforceable gate is sworn ci-check — a CI diff check
that cannot be bypassed by a local flag. The Git pre-commit hook runs the same
gate pipeline as fast developer feedback; git commit --no-verify skips it
(see docs/KNOWN_BOUNDARIES.md B-1). For team-wide fail-closed posture, make
the CI gate a required status check.
Security policy and reporting: SECURITY.md · Documented limits of enforcement: docs/KNOWN_BOUNDARIES.md
Governance Summary
Sworn gives teams a deterministic gate before commit that blocks risky changes and produces auditable evidence for compliance programs.
- It solves ambiguous AI-code governance by enforcing explicit, deterministic rules.
- It guarantees fail-closed behavior on signature, hashing, and CI enforcement failures.
- It provides compliance-support reporting (CMMC-focused in 0.4.1).
- It does not certify compliance, replace a C3PAO, or provide a PKI/identity trust service.
- Engineering value: predictable commit outcomes, stronger evidence retention, and simpler policy enforcement.
- Security value: tamper-evident logs, strict fail-closed semantics, and scoped threat assumptions.
- Compliance value: explicit control mapping and explicit “support-only” interpretation.
For full threat model and scope boundaries:
SECURITY.mddocs/KNOWN_BOUNDARIES.mdCOMPLIANCE_SCOPE.mdGOVERNANCE_OVERVIEW.mdRELEASE_PROCESS.mddocs/config.mddocs/DEPLOYMENT.md
Governance Architecture
Sworn is organized across four layers:
- Runtime Enforcement → pipeline, resolver, and kernels.
- Evidence Integrity → canonical JSON, hash-chain, and signatures.
- Compliance Interpretation → CMMC kernels and report mapping.
- Release Governance → version discipline and evidence retention.
See GOVERNANCE_OVERVIEW.md for the full model and cross-layer bindings.
Install
pip install sworncode
Quick Start
# Initialize in any git repo
cd your-repo
sworn init
# That's it. Local commits in this repo now run through Sworn.
# For team-wide fail-closed posture, require the CI gate in docs/DEPLOYMENT.md.
# Try committing a file in a sensitive path:
mkdir -p crypto
echo "secret = 'key'" > crypto/vault.py
git add crypto/vault.py
git commit -m "test"
# → SWORN BLOCKED — Security surface: crypto/vault.py
What It Does
Sworn runs a 5-stage gate pipeline during local commit checks and CI diff checks:
- Identity — Records actor (gated repo
git config user.name) and AI tool from environment. This stage never blocks. Unresolved actor is blocked only when the opt-in CMMC AC kernel is enabled. - Security — Blocks commits touching sensitive paths (configurable)
- Allowlist — Enforces file access control when configured (still evaluated after a prior block so evidence is complete)
- Signing — Fail-closed when signing is enabled (missing/legacy key, missing PyNaCl, or sign failure blocks)
- Kernels — Runs constraint kernels (built-in + custom) even when a structural gate already blocked
- Evidence — Appends a JSONL entry to
.sworn/evidence.jsonl. A log write failure blocks.
Every stage is deterministic. No AI in the governance loop. No network calls. No probabilistic analysis. Identity records and never blocks; other enabled stages either pass or block.
For team-wide fail-closed posture, treat local hooks as developer fast-fail and make the CI gate a required status check. See docs/DEPLOYMENT.md.
Commands
sworn init # Initialize sworn in a git repo
sworn check # Run gate pipeline (called by pre-commit hook)
sworn report # Show evidence summary
sworn report --json # Machine-readable output
sworn report --cmmc # CMMC evidence-support report
sworn status # Show initialization and config state
sworn verify # Verify evidence chain (EMPTY/VALID/BROKEN)
python -m sworn # Run command through module entrypoint
sworn --version # Print version
sworn keygen # Generate Ed25519 signing keypair (needs PyNaCl)
sworn ci-check # Run pipeline on a PR/CI diff
Configuration
After sworn init, edit .sworn/config.toml:
[security]
# Regex patterns for sensitive paths (case-insensitive)
patterns = [
'(^|/)(crypto|auth|gates|licensing|keys)/',
'(^|/)secrets?/',
'\.env$',
'(^|/)private/',
]
[allowlist]
# Only these glob patterns allowed (empty = all allowed)
files = []
[kernels]
# Built-in kernels
security = true
allowlist = true
audit = true
# Custom kernels
custom_dir = ".sworn/kernels"
# CMMC kernel pack is off by default. Enable explicitly:
# cmmc = true
[evidence]
log_path = ".sworn/evidence.jsonl"
hash_chain = true
# [signing]
# enabled = false
# key_path = ".sworn/keys/active.key"
# pub_path = ".sworn/keys/"
Custom Kernels
Write a Python file in .sworn/kernels/ with an evaluate() function:
from sworn.kernels.sdk import KernelInput, KernelResult
def evaluate(kernel_input: KernelInput) -> KernelResult:
# Your logic here
if some_condition:
return KernelResult(
decision="BLOCKED",
triggered_rules=["my_rule"],
evidence_summary=["Blocked because..."],
)
return KernelResult(decision="PASS")
Evidence
Every gate run produces a JSONL entry with SHA256 hash chain:
sworn report
# SWORN EVIDENCE REPORT
# ========================================
# Total commits gated: 47
# Passed: 43
# Blocked: 4
# Pass rate: 91.5%
# Chain integrity: VALID
sworn verify
# Chain: VALID
# Chain valid: 47 entries
# Empty log (after init, before any gated commit):
# Chain: EMPTY
# EMPTY: no evidence log found
# Exit code is 1 — nothing was attested.
Security Posture & Rule-2 Scope
Sworn’s evidence signing and verification layer is Security-Critical.
Rule-2 scoped behavior includes:
src/sworn/evidence/signing.pysrc/sworn/evidence/log.py- CLI commands in
src/sworn/cli.pythat verify evidence - CI diff-base resolution in CI mode
This behavior is fail-closed:
- If signing is enabled and signing fails, the pipeline blocks.
- If verification fails,
sworn verifyreportsBROKEN. - Missing signature in signed mode is a violation.
- If base resolution fails in CI compliance mode, the check exits fail-closed.
Deterministic Resolution Contract
Sworn resolution semantics are intentional and fixed:
- Structural gates execute first.
- Kernels execute after structural gates.
- If any kernel returns
BLOCKED, final result isBLOCKED. - Primary reason is deterministic by lexical sort of blocked kernel names.
- All blockers are preserved in
resolution_trace. - No precedence overrides exist.
This design favors clarity and auditability over configurability.
Kernel Contract (Mandatory for Contributors)
Sworn executes kernels even when structural gates already block.
All kernels MUST:
- Be pure (no file writes, network calls, or subprocesses)
- Be side-effect free
- Tolerate partial or failed gate states
- Not depend on a prior structural
PASS
Violation is a contract breach and a security defect.
Evidence Signing Model
Canonicalization
Sworn signs a deterministic canonical JSON form:
- UTF-8 encoding
json.dumps(obj, sort_keys=True, separators=(",", ":"), ensure_ascii=False)signature=""placeholder during canonicalization- No trailing newline
- Stable, deterministic field ordering
Canonicalization rules are versioned. Any change increments the internal signing/evidence schema and requires compatibility handling.
Integrity vs Trust
Repo-Local Integrity (Default)
This mode detects tampering after an entry is written, chain discontinuity, and key mismatch relative to repo-local keys.
It does not prove:
- Organizational authority or approval
- Identity beyond Git metadata
- Secure private-key custody
- Truncation of the evidence log tail is not detected: deleting the last N lines of .sworn/evidence.jsonl still verifies VALID because the chain head is not pinned out-of-band (see docs/KNOWN_BOUNDARIES.md B-4/B-5)
It proves repository-local tamper-evidence.
Org-Trust Mode (Recommended for compliance)
To elevate signing into attestation quality:
- Pin public keys via protected branches / CODEOWNERS / policy repo
- Restrict key updates with branch protections and owner controls
- Keep private keys outside the repo working tree (
KMS, Vault, keychain, or secret manager) - Run explicit rotation/retirement procedures
Sworn verifies signatures; it does not manage organizational assurance by itself.
Key Layout & Migration
Current layout:
.sworn/
keys/
active.key # private key
<key_id>.pub # committed public key
Legacy layout:
.sworn/signing.key
Behavior:
- If
.sworn/signing.keyexists and.sworn/keys/active.keydoes not, Sworn blocks when signing is enabled and emits actionable migration instructions. - Sworn does not silently continue.
- Sworn does not auto-migrate without explicit user action.
- Upgrades from legacy layout require explicit migration guidance before signing is used.
CI Enforcement (Fail-Closed)
Sworn CI mode uses github.event.pull_request.base.sha and fail-closes if resolution is not possible.
- If base SHA resolves, diff is computed deterministically against HEAD.
- If base SHA cannot be resolved in compliance mode, check fails with remediation guidance.
- Silent fallback is not permitted.
Workflow requirement:
actions/checkout@v4
with:
fetch-depth: 0
CMMC Evidence Scope
Sworn’s CMMC pack provides evidence-support mappings to selected NIST SP 800-171 controls and explicitly documented determination statements.
It does not certify compliance, replace a C3PAO, or guarantee assessment outcome.
Release Readiness Checklist
Before tagging any release:
- Clean reproducible install (
python -m pip install .[dev,signing]in a clean environment on Python 3.10-3.13) - Full pytest suite green
- Signing-enabled tamper detection validated
- CI base-resolution failure path validated
- Legacy key migration path validated
- Version bump consistent across package metadata and documentation
- Release evidence generated and reviewed before signed tag capture
- Working tree clean during final tag capture
Known Residual Risks
- Repo-local signing is not equivalent to organizational attestation.
- Kernel purity is contract-enforced; runtime sandboxing is out of scope today.
- CI enforcement depends on correct workflow configuration and checkout depth.
- Migration from legacy key layouts still requires explicit user action.
Requirements
- Python 3.10+
- Git
- Zero runtime dependencies (tomli included in stdlib from 3.11)
License
Apache 2.0 — Centennial Defense Systems
Metadata
Release files for sworncode 0.4.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| sworncode-0.4.1.tar.gz | 46.8 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| sworncode-0.4.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 90.2 kB
Release files / sworncode-0.4.1.tar.gz
| Download URL | sworncode-0.4.1.tar.gz |
|---|---|
| Size | 46.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
2d1b8d309d3d8f7c77ec648ad57e9f8fa56278f0532b5d08e4f24f6ed5ba82c4
|
|
BLAKE2b-256 checksum How to use checksums |
34f57281705baefc35fd80d561bf139b50b5d44d2338d994e361904e7c921056
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.13
|
Release files / sworncode-0.4.1-py3-none-any.whl
| Download URL | sworncode-0.4.1-py3-none-any.whl |
|---|---|
| Size | 43.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5a0a5de8075fe25e75249f74e63adb79246f125d57e070c14762fab6a6c8b443
|
|
BLAKE2b-256 checksum How to use checksums |
b3d4344a639d948df355f2fe553fa248ea24b2d4cefd88fb04a2e4bfb713d200
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.13
|
Security for sworncode 0.4.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.