Compliance Frameworks
Beyond AI-specific frameworks, chio's primitives also supply evidence that aligns with classic security and privacy frameworks. This page collects the mappings for SOC 2 Type II, HIPAA, PCI DSS v4.0, and the OWASP LLM Top 10 (2025 edition). For each, the framing is the same: chio's shipped controls map onto named control requirements, producing signed evidence that a compliance program can reference.
Mapping, not certification
SOC 2 Type II
SOC 2 evaluates a service organization against Trust Services Criteria covering security, availability, processing integrity, confidentiality, and privacy. Type II specifically tests operating effectiveness over a period, so the evidence story matters as much as the control story.
| Criterion | Requirement | Chio Primitive |
|---|---|---|
| CC6.1 | Logical access controls restrict access to information and systems. | Capability tokens scope access to specific tools and servers; ToolGrant.constraints narrow parameters. |
| CC6.2 | New access is authorized and documented. | Capability issuance emits a signed record; grant includes issuer identity and expiry. |
| CC6.3 | Access is modified or removed when warranted. | Revocation runtime enforces removal on the next call; grant expiry bounds authority in time. |
| CC6.6 | Logical controls prevent or detect unauthorized access. | DPoP proof-of-possession binds every call to the capability subject keypair. |
| CC7.1 | Detection of new vulnerabilities and system changes. | Policy hash in every receipt; signed manifests for every tool server. |
| CC7.2 | System components monitored to detect anomalies. | Receipt store, velocity guards, guard-evidence aggregation, SIEM export. |
| CC7.3 | Security events are evaluated and responded to. | Deny receipts, revocation response, step-up approval via GovernedApprovalToken. |
| CC7.4 | Security incidents are investigated. | Evidence export bundles produce a signed snapshot for investigators. |
| CC8.1 | Change management authorizes, documents, and tests changes. | Policy hash pins each invocation to a policy version. |
| A1.2 | Availability: environmental threats and backups. | Evidence retention archives signed receipts; archived entries still verify against stored checkpoints. |
| PI1.4 | Processing integrity: inputs and outputs are validated. | Request-matching guard, response-sanitization guard, data-flow guard. |
| C1.1 | Confidentiality: confidential information is protected. | Secret-leak guard, response sanitization, column constraints on SQL and vector guards. |
| P4.1 | Privacy: use, retention, and disposal of personal information. | Retention config governs receipt lifetime; response sanitization scrubs PII before egress. |
Type II is about operating effectiveness over time
HIPAA Security Rule
The HIPAA Security Rule imposes administrative, physical, and technical safeguards on electronic protected health information (ePHI). Chio's tool-governance layer aligns with the technical safeguards under 45 CFR Part 164, Subpart C.
| Reference | Requirement | Chio Primitive |
|---|---|---|
| § 164.312(a)(1) Access control | Allow only authorized persons or software programs to access ePHI. | Capability tokens deliver least-privilege by default; grant constraints narrow reachable tools and parameters. |
| § 164.312(a)(2)(i) Unique identification | Assign a unique name or number for tracking user identity. | CapabilityToken.subject is a unique did:chio identifier per agent. |
| § 164.312(a)(2)(ii) Emergency access | Procedures for obtaining ePHI during an emergency. | Signed GovernedApprovalToken supplies a human-reviewed break-glass path. |
| § 164.312(a)(2)(iii) Automatic logoff | Terminate electronic session after predetermined inactivity. | Capability expiry bounds the lifetime of any agent authority. |
| § 164.312(b) Audit controls | Record and examine activity in systems containing ePHI. | Signed receipt per invocation; Merkle-committed batches; guard evidence per call. |
| § 164.312(c)(1) Integrity | Protect ePHI from improper alteration or destruction. | Checkpoint chain plus inclusion proofs detect tampering; fail-closed kernel never omits evidence. |
| § 164.312(d) Person or entity authentication | Verify that a person or entity seeking access is the one claimed. | DPoP proof-of-possession binds every call to the capability keypair; replay prevention via action_hash plus nonce. |
| § 164.312(e)(1) Transmission security | Guard against unauthorized access to ePHI during transmission. | TLS on HTTP endpoints; mTLS for tool-server transport. |
| § 164.308(a)(1)(ii)(D) Information system activity review | Regularly review records of information system activity. | Receipt query API surfaces activity by subject, tool, and time; dashboard review surface. |
Covered-entity status is operator-owned
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.
| Requirement | Description | Chio Primitive |
|---|---|---|
| Req 6.5 | Changes to systems and software are managed. | Policy hash in every receipt ties an invocation to a policy version. |
| Req 7.2 | Access by business need-to-know is assigned. | Capability ToolGrant.scope, typed constraints, and delegation attenuation. |
| Req 7.2.5 | Application and system accounts follow least privilege. | Capability-based least privilege is the default posture; there is no implicit authority. |
| Req 7.3 | Access is managed through access-control systems. | Capability issuance through the trust control plane; revocation via revocation_runtime. |
| Req 8.2 | User identification and account lifecycle. | CapabilityToken.subject uniquely identifies each agent; workload identity carries metadata. |
| Req 8.3 | Strong authentication is established. | Ed25519 keypair per agent; DPoP binds each call to the subject with replay safety via action_hash and nonce. |
| Req 8.6 | Application and system account use is managed. | Capability expiry, revocation, delegation-chain validation. |
| Req 10.2 | Audit logs are implemented. | Append-only receipt store; every decision emits a signed receipt. |
| Req 10.3 | Audit logs are protected from destruction or unauthorized modification. | Merkle commitments; inclusion proofs; fail-closed archival. |
| Req 10.5 | Audit-log history is retained. | Retention config preserves checkpoint rows alongside archived receipts; PCI's one-year minimum must be set explicitly. |
| Req 10.7 | Failures of critical security controls are detected. | Fail-closed pipeline produces deny receipts on error; SIEM exporter streams events. |
| Req 12.8 | Third-party service providers are managed. | Capability scoping restricts which third-party tool servers an agent reaches; manifest verification confirms binding. |
Scope reduction is not scope elimination
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.
| Risk | Chio Mitigation | Coverage |
|---|---|---|
| LLM01 Prompt Injection | Input-validation guards on tool-call arguments; prompt-injection and jailbreak detectors as application-layer guards; every trigger recorded in ChioReceipt.guard_evidence. | partial |
| LLM02 Sensitive Information Disclosure | Secret-leak guard, response sanitization, data-flow guard, column-level constraints on SQL and vector guards; capability scoping limits reachable data sources. | strong |
| LLM03 Supply Chain | Signed tool manifests with Ed25519 signatures; manifest verification before registration; patch-integrity guard for patch content; workload-identity attestation. | partial |
| LLM04 Data and Model Poisoning | Data-layer guards restrict what a deployed agent can write back into tool-accessible stores; training-data poisoning is out of chio's scope. | out-of-scope |
| LLM05 Improper Output Handling | Response sanitization, post-invocation query-result guard, structured output schemas enforced by request-matching; block verdicts stop unsafe output from reaching downstream tools. | strong |
| LLM06 Excessive Agency | Capability tokens bound tool reach; typed constraints bound arguments; delegation chains attenuate monotonically; velocity and budget caps bound rate and spend; GovernedAutonomyTier requires step-up approval for sensitive tiers. | strong |
| LLM07 System Prompt Leakage | Where system prompts flow through governed tools, response sanitization and secret-leak can match on known prompt content; capability scoping prevents introspection tools that would expose prompts. | partial |
| LLM08 Vector and Embedding Weaknesses | Vector-store data-layer guard restricts embeddings an agent may read or write; egress allowlist limits retrieval endpoints; column constraints can deny sensitive fields pre-vectorization. | partial |
| LLM09 Misinformation | Receipts record what was returned and who received it, supporting correction workflows; factuality evaluation itself is out of chio's scope. | partial |
| LLM10 Unbounded Consumption | Budget enforcement caps monetary spend atomically per invocation and per grant; velocity guard caps invocation rate and spend rate; revocation is immediate; grant expiry bounds time. | strong |
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.
Exporting Evidence Bundles
Every framework above benefits from the same evidence pipeline: chio evidence export. The command assembles a signed bundle that an auditor can verify offline.
# Assemble an evidence bundle covering the quarter.
$ chio evidence export \
--policy ./policy.yaml \
--receipt-db ./receipts.sqlite3 \
--since 2026-01-01T00:00:00Z \
--until 2026-03-31T23:59:59Z \
--output ./q1-evidence-bundle
# Bundle contents:
# policy.yaml (signed policy artifact)
# policy-hash.txt (the hash embedded in every receipt)
# receipts/ (receipts for the window, by day)
# checkpoints/ (Merkle checkpoints covering the batch ranges)
# manifests/ (every ToolManifest referenced by the receipts)
# session-certificate.json (signed summary of the operational posture)
# integrity.json (Ed25519 signature over the bundle manifest)
# Verify a bundle offline.
$ chio evidence verify \
--bundle ./q1-evidence-bundle \
--kernel-pubkey ed25519:80f2b577... \
--issuer-pubkey ed25519:ac34d1e9...What the bundle proves to an auditor:
- The receipts were produced by the named kernel keypair (Ed25519 signature on each receipt).
- The checkpoint chain is intact (signed Merkle roots cover the included batches, and inclusion proofs are reproducible).
- The policy hash embedded in every receipt matches the policy artifact shipped inside the bundle.
- Every referenced tool manifest is signed by its issuer.
One pipeline, many frameworks
Cross-Framework Summary
| Chio Primitive | SOC 2 | HIPAA | PCI DSS v4 | OWASP LLM |
|---|---|---|---|---|
| Capability tokens with typed constraints | CC6.1, CC6.2, CC6.3 | § 164.312(a)(1), (a)(2)(i) | Req 7.2, 7.3, 8.2 | LLM06 |
| Signed receipt per invocation | CC7.2, CC7.4 | § 164.312(b) | Req 10.2, 10.3 | LLM02 evidence |
| Merkle checkpoint chain | CC7.1, A1.2 | § 164.312(c)(1) | Req 10.3, 11.5 | LLM02 tamper-evidence |
| DPoP proof of possession | CC6.6 | § 164.312(d) | Req 8.3 | LLM06 attribution |
| Guard pipeline (velocity, budget, egress, secret-leak) | CC7.2, C1.1 | § 164.312(e)(1) | Req 1.3, 10.7 | LLM02, LLM05, LLM10 |
| Revocation runtime | CC6.3, CC7.3 | § 164.308(a)(3)(ii)(C) | Req 8.6 | LLM06 containment |
| Evidence export bundle | CC7.4, management letter | § 164.308(a)(1)(ii)(D) | Req 12.10 | LLM09 correction workflows |
Non-Goals
- No claim that chio is SOC 2 certified, HIPAA attested, or 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.
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.