Chio/Docs

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

Chio is a tool-invocation control plane. It is not itself a SOC 2-certified service, a HIPAA-covered entity, or a PCI DSS QSA report. What it does is produce the signed evidence and enforce the technical controls that a certified organization relies on at the agent boundary.

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.

CriterionRequirementChio Primitive
CC6.1Logical access controls restrict access to information and systems.Capability tokens scope access to specific tools and servers; ToolGrant.constraints narrow parameters.
CC6.2New access is authorized and documented.Capability issuance emits a signed record; grant includes issuer identity and expiry.
CC6.3Access is modified or removed when warranted.Revocation runtime enforces removal on the next call; grant expiry bounds authority in time.
CC6.6Logical controls prevent or detect unauthorized access.DPoP proof-of-possession binds every call to the capability subject keypair.
CC7.1Detection of new vulnerabilities and system changes.Policy hash in every receipt; signed manifests for every tool server.
CC7.2System components monitored to detect anomalies.Receipt store, velocity guards, guard-evidence aggregation, SIEM export.
CC7.3Security events are evaluated and responded to.Deny receipts, revocation response, step-up approval via GovernedApprovalToken.
CC7.4Security incidents are investigated.Evidence export bundles produce a signed snapshot for investigators.
CC8.1Change management authorizes, documents, and tests changes.Policy hash pins each invocation to a policy version.
A1.2Availability: environmental threats and backups.Evidence retention archives signed receipts; archived entries still verify against stored checkpoints.
PI1.4Processing integrity: inputs and outputs are validated.Request-matching guard, response-sanitization guard, data-flow guard.
C1.1Confidentiality: confidential information is protected.Secret-leak guard, response sanitization, column constraints on SQL and vector guards.
P4.1Privacy: 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

The Merkle-committed receipt log is a particularly strong fit for Type II. An auditor can verify that controls produced signed evidence continuously across the reporting window by walking the checkpoint chain, rather than relying on sampled log snapshots.

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.

ReferenceRequirementChio Primitive
§ 164.312(a)(1) Access controlAllow 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 identificationAssign 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 accessProcedures for obtaining ePHI during an emergency.Signed GovernedApprovalToken supplies a human-reviewed break-glass path.
§ 164.312(a)(2)(iii) Automatic logoffTerminate electronic session after predetermined inactivity.Capability expiry bounds the lifetime of any agent authority.
§ 164.312(b) Audit controlsRecord and examine activity in systems containing ePHI.Signed receipt per invocation; Merkle-committed batches; guard evidence per call.
§ 164.312(c)(1) IntegrityProtect 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 authenticationVerify 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 securityGuard 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 reviewRegularly 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

Chio does not itself handle ePHI and is not, on its own, a covered entity or business associate. Operators who deploy chio as part of a covered or business-associate workflow are responsible for the BAA, the ePHI inventory, and the ultimate compliance attestation.

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.

RequirementDescriptionChio Primitive
Req 6.5Changes to systems and software are managed.Policy hash in every receipt ties an invocation to a policy version.
Req 7.2Access by business need-to-know is assigned.Capability ToolGrant.scope, typed constraints, and delegation attenuation.
Req 7.2.5Application and system accounts follow least privilege.Capability-based least privilege is the default posture; there is no implicit authority.
Req 7.3Access is managed through access-control systems.Capability issuance through the trust control plane; revocation via revocation_runtime.
Req 8.2User identification and account lifecycle.CapabilityToken.subject uniquely identifies each agent; workload identity carries metadata.
Req 8.3Strong authentication is established.Ed25519 keypair per agent; DPoP binds each call to the subject with replay safety via action_hash and nonce.
Req 8.6Application and system account use is managed.Capability expiry, revocation, delegation-chain validation.
Req 10.2Audit logs are implemented.Append-only receipt store; every decision emits a signed receipt.
Req 10.3Audit logs are protected from destruction or unauthorized modification.Merkle commitments; inclusion proofs; fail-closed archival.
Req 10.5Audit-log history is retained.Retention config preserves checkpoint rows alongside archived receipts; PCI's one-year minimum must be set explicitly.
Req 10.7Failures of critical security controls are detected.Fail-closed pipeline produces deny receipts on error; SIEM exporter streams events.
Req 12.8Third-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

Chio reduces the PCI scope of the agent layer by limiting what agents can call. It does not remove PCI obligations on the tool servers that actually handle cardholder data, nor does it substitute for PAN masking, encryption at rest, or the organization's Report on Compliance. Treat chio as input to the scoping exercise, not as its conclusion.

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.

RiskChio MitigationCoverage
LLM01 Prompt InjectionInput-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 DisclosureSecret-leak guard, response sanitization, data-flow guard, column-level constraints on SQL and vector guards; capability scoping limits reachable data sources.strong
LLM03 Supply ChainSigned tool manifests with Ed25519 signatures; manifest verification before registration; patch-integrity guard for patch content; workload-identity attestation.partial
LLM04 Data and Model PoisoningData-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 HandlingResponse 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 AgencyCapability 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 LeakageWhere 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 WeaknessesVector-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 MisinformationReceipts record what was returned and who received it, supporting correction workflows; factuality evaluation itself is out of chio's scope.partial
LLM10 Unbounded ConsumptionBudget 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.

bash
# 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

The evidence bundle is framework-agnostic. An auditor running a SOC 2 examination and an auditor running a HIPAA review look at the same signed artifacts with different control checklists. There is no per-framework retooling on chio's side.

Cross-Framework Summary

Chio PrimitiveSOC 2HIPAAPCI DSS v4OWASP LLM
Capability tokens with typed constraintsCC6.1, CC6.2, CC6.3§ 164.312(a)(1), (a)(2)(i)Req 7.2, 7.3, 8.2LLM06
Signed receipt per invocationCC7.2, CC7.4§ 164.312(b)Req 10.2, 10.3LLM02 evidence
Merkle checkpoint chainCC7.1, A1.2§ 164.312(c)(1)Req 10.3, 11.5LLM02 tamper-evidence
DPoP proof of possessionCC6.6§ 164.312(d)Req 8.3LLM06 attribution
Guard pipeline (velocity, budget, egress, secret-leak)CC7.2, C1.1§ 164.312(e)(1)Req 1.3, 10.7LLM02, LLM05, LLM10
Revocation runtimeCC6.3, CC7.3§ 164.308(a)(3)(ii)(C)Req 8.6LLM06 containment
Evidence export bundleCC7.4, management letter§ 164.308(a)(1)(ii)(D)Req 12.10LLM09 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.

Compliance Frameworks · Chio Docs