SOC 2 Compliance
Documentation in progress. Hoziron has not completed a SOC 2 Type I or Type II audit and has not engaged a third-party auditor. This page maps existing technical controls to the SOC 2 Trust Service Criteria for a carrier's own evaluation — it is not evidence of a completed audit and should not be represented as one.
Current capabilities
The platform provides technical controls that map to SOC 2 Trust Service Criteria:
- Security — Authentication via API keys (Argon2id-hashed, per-IP exponential brute-force backoff) or OIDC (JWT validated against an external IdP's JWKS); RBAC (five roles); optional native TLS termination; IP/CIDR allowlisting; audit logging of denied requests.
- Availability —
/healthendpoint (rolling p95 latency, liveness), per-provider circuit breakers with automatic half-open recovery on the routing gateway, and graceful shutdown on SIGTERM (agents suspended, memory flushed, DB connections closed before exit). - Processing integrity — Merkle-hash-chained audit trail with an independently re-verifiable chain (
GET /security/verify); PII tokenization/hydration boundary enforced at the pipeline layer, not left to individual agent prompts. - Confidentiality — Structural per-agent memory isolation (
BoundMemoryHandlehas no API surface for addressing another agent's data); credential vault (AES-256-GCM, per-entry salt/nonce) for provider keys and other secrets; provider API keys are referenced by env-var name in config, never stored in plaintext. - Privacy — Deny-by-default PII tokenization pipeline; hydration to real values requires an explicit, operator-owned policy rule (no agent-level override, no runtime mutation API); data sovereignty via air-gapped/local-model deployment.
Coming soon
- Control mapping document (TSC → Hoziron features, with owners and evidence sources)
- Evidence collection automation guidance
- Monitoring and alerting recommendations for an eventual SOC 2 audit
- Change management process documentation
Related: