zilix · Security & Governance
Governed by design.
zilix lets you gate agent actions behind signed policy, require human approval before anything runs,
and keep a tamper-evident record of what happened — real building blocks for teams shipping audited
or regulated codebases.
Straight talk: zilix is not certified. There is no SOC 2, HIPAA, FedRAMP, ISO 27001, or FDA claim
today, and this page is not a compliance guarantee. It describes what's actually shipped in the code,
and states the limits plainly below.
What's real today
Signed policy enforcement
Org-wide policies can deny or require approval for a tool call based on the tool, file, command, or spend budget involved. Policies are signed — changing any rule breaks the signature fleet-wide, so a tampered policy can't silently apply.
Shipped
Human approval gates
Agent tool calls and orchestration plans can require a human to approve before they execute — including a dedicated hold in plan mode, so nothing runs unreviewed if you've configured it that way.
Shipped
Tamper-evident audit log
Every logged action is chained by hash to the one before it, with periodic Ed25519 checkpoint signatures. A verifier recomputes the chain and will detect an inserted, edited, or deleted record.
Shipped
Known limits, stated plainly
Not certified
No SOC 2, HIPAA, FedRAMP, ISO 27001, or FDA certification exists today. Nothing on this page should be read as a compliance claim — it's a description of shipped mechanisms, not an audited attestation.
Tamper-evident ≠ tamper-proof
The checkpoint-signing key lives on the same machine as the log by default. Local verification alone can't rule out someone with root access on that machine rewriting history and re-signing it. Shipping the log to an independent, off-box collector closes this gap — that path exists but is opt-in, not default.
No PHI handling
Today's redaction catches secret-shaped values — API keys, bearer tokens, credentialed URLs. It does not detect or de-identify protected health information (names, MRNs, diagnoses, addresses). zilix is not intended for processing PHI today.
No SSO yet
Sign-in today is local password and passkey based. Federated identity (Okta, Azure AD/Entra) is on the roadmap, not shipped. Role-based access is currently a flat owner/admin/member model, not a granular or clinical-role scheme.
No traceability graph
There is no built-in requirement→work-item→commit→review→evidence linkage today. The audit log records what agents did; it doesn't yet map that back to product requirements or generate signed evidence packages.
Common questions
Is zilix HIPAA, SOC 2, or FDA compliant?
Not yet, and we won't claim otherwise. What's shipped — signed policy, approval gates, a hash-chained audit log — are real building blocks toward auditable development, not a certification. If your team needs a completed control mapping or a security questionnaire answered, reach out and we'll tell you plainly what's covered and what isn't.
Can zilix sit between an LLM and clinical or patient data?
No. zilix orchestrates AI coding agents that write and review software — it does not integrate with EHRs, FHIR, or HL7 systems, and it has no PHI-aware scrubbing or clinical decision routing. It governs how code gets written, not what a clinical system does with patient data at runtime.
Where do my code, keys, and audit logs live?
Your source code and agent sessions stay on the machine running the daemon. The audit log is written locally by default; shipping it to an off-box collector for independent verification is available but opt-in. Provider API keys stay local and never route through zilix servers.
What happens if the audit log can't be written?
The daemon is designed not to crash if the audit disk is full or unwritable — a write failure is counted rather than silently ignored, and that count is exposed on a health endpoint rather than surfaced as a hard stop. We're working toward making that failure more visible by default.