Compliance Frameworks

PCI DSS v4.0

PCI DSS v4.0 protects cardholder data and sensitive authentication data across people, processes, and technology. Chio does not itself process, store, or transmit cardholder data, but agent systems governed by Chio routinely call payment gateways or CRMs that hold card data. Chio's role is to reduce PCI scope of the agent layer by enforcing which tools an agent may touch, under which conditions.

The coverage column carries the grade the repository's own mapping gives each requirement (docs/compliance/pci-dss-v4.md): strong means Chio's shipped controls directly satisfy the requirement at the agent tool-governance layer, and partial means Chio supplies part of the control and something else is required alongside it.

OWASP LLM Top 10 (2025)

The OWASP Top 10 for LLM Applications (2025 edition) names the most critical security risks for LLM-based software. Chio governs the tool-invocation boundary, which is where most "LLM does something in the real world" risks concentrate.

Four of the ten risks have strong coverage at Chio's boundary (LLM02, LLM05, LLM06, LLM10). Five are partially covered because the root cause sits inside the model; Chio complements rather than replaces model-layer defenses. One (LLM04) is out of scope at the tool-governance layer. The guards named above live in crates/guards/chio-guards/src/ and crates/guards/chio-data-guards/src/.

Colorado SB 24-205

Colorado Senate Bill 24-205, the "Consumer Protections for Artificial Intelligence" act, takes effect February 1, 2026. It imposes record-keeping, transparency, and accountability obligations on developers and deployers of high-risk AI systems. Chio operates at the runtime-kernel layer and supplies the record-keeping, audit, tamper-evidence, and proof-of-possession material those obligations draw on.

The full clause-by-clause mapping against § 6-1-1703, subsections (1) through (7), is its own page: see Colorado SB 24-205 for the per-clause requirement table, the named test backing each claim, and the disclosure, retention, tamper-evidence, and budget-accountability mechanics in full.

Frameworks Without a Control Mapping

Two frameworks operators ask about most often, SOC 2 and the HIPAA Security Rule, have no control mapping in the Chio repository. The only place either appears is docs/protocols/SESSION-COMPLIANCE-CERTIFICATE.md section 7, which lines four Trust Services criteria and three § 164.312 provisions up against fields of a session compliance certificate. Those fields are not the ones the shipped certificate carries: SessionComplianceCertificateBody in crates/kernel/chio-kernel/src/compliance_certificate.rs holds session_id, policy_hash, receipt_count, all_signatures_valid, crypto_floor, and issued_at. So this page carries no SOC 2 or HIPAA table, because there is nothing in the source to carry one from.

The mechanisms an operator would reach for in either exercise are documented on their own terms rather than against a criterion number: Capabilities for scoped access and revocation, Receipts for the per-invocation record, and Guards for the named controls. The frameworks the repository does map are PCI DSS v4.0 and the OWASP LLM Top 10 above, plus the EU AI Act, NIST AI RMF, ISO/IEC 42001, Colorado SB 24-205, and HITRUST i1.

Exporting Evidence Bundles

Every framework above benefits from the same evidence pipeline: chio evidence export. The command assembles a bundle an auditor can verify offline. It reads the local receipt database through the global --receipt-db flag, and a local export with neither --tenant nor --admin-all refuses rather than defaulting to every tenant. Pass --since and --until, both Unix seconds, to narrow the window; --require-proofs to fail the export if any selected receipt lacks checkpoint coverage; and --federation-policy to constrain the export scope by a signed bilateral federation policy.

$ chio --receipt-db ./receipts.db evidence export \
    --policy-file ./policy.yaml --admin-all --output ./evidence-package
$ find ./evidence-package -type f | sort

./evidence-package/README.txt
./evidence-package/capability-lineage.ndjson
./evidence-package/checkpoint-consistency-proofs.ndjson
./evidence-package/checkpoint-equivocations.ndjson
./evidence-package/checkpoint-publications.ndjson
./evidence-package/checkpoint-witnesses.ndjson
./evidence-package/checkpoints.ndjson
./evidence-package/child-receipts.ndjson
./evidence-package/inclusion-proofs.ndjson
./evidence-package/manifest.json
./evidence-package/policy/metadata.json
./evidence-package/policy/source.yaml
./evidence-package/query.json
./evidence-package/receipts.ndjson
./evidence-package/retention.json

The four checkpoint- files carry the transparency record for the checkpoints in the window: publications, witness signatures, consistency proofs, and any recorded equivocation. The policy/ directory appears when --policy-file is supplied, and a federation-policy.json joins them when --federation-policy is.

The manifest records a SHA-256 and a byte count for every file the export wrote, so verification is a re-derivation rather than a signature check on the manifest alone. Appending one byte to receipts.ndjson in a copied package and re-running the verifier:

$ cp -R ./evidence-package ./evidence-tampered
$ printf '\n' >> ./evidence-tampered/receipts.ndjson
$ chio evidence verify --input ./evidence-tampered

error [urn:chio:error:attest:provenance-missing]: evidence package file hash mismatch for receipts.ndjson
context: {"domain":"attest","severity":"error","stability":"unstable","string_code":"CHIO-ATTEST-PROVENANCE-MISSING"}
suggested fix: Regenerate the evidence bundle and include provenance before submitting the operation.

The verifier names the file rather than reporting a bare failure, so an auditor holding a package that does not verify knows which artifact to request again. The export refuses to write into a directory that already holds files, for the same reason:

$ chio --receipt-db ./receipts.db evidence export \
    --policy-file ./policy.yaml --admin-all --output ./evidence-package

error [urn:chio:error:cli:other]: evidence export output directory must be empty: ./evidence-package
context: {"domain":"cli","severity":"error","stability":"deprecated","string_code":"CHIO-CLI-OTHER"}
suggested fix: Preserve the original message and migrate the call site to a specific registry code when touched.

What the package proves to an auditor:

• Each receipt was produced by the kernel keypair it names, because the signature over its canonical body verifies against kernel_key, and its action.parameter_hash is recomputed from the parameters the receipt carries.
• The checkpoint chain is intact: signed Merkle roots cover the included batches, and the inclusion proofs reproduce.
• Every file listed in the manifest still hashes to the digest recorded for it, and the counts in the manifest agree with the exported data.
• When a policy was attached, the policy/metadata.json block matches the manifest and the source file it names is present. Verification does not re-hash the policy source or compare it against any receipt's policy_hash, so that comparison is the reader's to make.

Cross-Framework Summary

Non-Goals

• No claim that Chio is PCI DSS assessed as a service. These frameworks apply to organizations; Chio is infrastructure.
• No substitute for network-layer controls, physical security, workforce training, or legal review. Chio complements those controls at the agent boundary; it does not replace them.
• No universal risk score across frameworks. Chio emits the evidence; the compliance program translates it into each framework's language.
• No mapping for a framework the repository does not map. A criterion number in a table on this page is one the source document names.

For the operator-facing command surface that produces these bundles, continue with the CLI reference. For the data model of receipts themselves, see Receipt Format.