How ZephMatrix keeps AI teammates governed in production
This brief summarizes the security and governance primitives that are implemented in the platform today, so you can understand exactly what is enforced in code versus what is still on the roadmap.
On this page
- How guardrails-as-code constrain what teammates can do
- How human-in-the-loop approvals work for high-risk actions
- What is logged today for auditability, and what is still on the roadmap
Guardrails-as-code
Every AI teammate is backed by a role configuration that includes explicit capabilities and guardrails. These are enforced in code by the GuardrailEnforcer service:
- • Pre-execution checks for blocked actions and required approvals
- • Cost and iteration limits with hard stops when budgets are exhausted
- • Post-execution audit to verify that responses stayed within guardrails
Human-in-the-loop for critical actions
High-risk actions can be configured to require explicit approval before they are executed. When an approval is required, the platform pauses the run and surfaces an approval card in the UI:
- • The model cannot execute side-effect tools unless the run is pre-approved within scope
- • Approve / reject decisions are persisted so execution can resume deterministically
- • The platform blocks “overclaiming” (claiming a side effect happened without a verified tool receipt)
Data isolation and encryption
ZephMatrix is built as a multi-tenant platform with strong isolation between businesses and support for encrypting sensitive data:
- • Application-level checks ensure AI teammates only access data for their own business
- • Support for encrypting sensitive fields using the platform's encryption utilities
- • Transport security (TLS) for production deployments
Auditability
Actions and key AI decisions are recorded in persistent audit logs to support investigations and reviews:
- • Structured logging across services with correlation identifiers
- • Durable audit records for security-sensitive and governance-relevant actions
- • Chained audit log integrity checks to detect tampering in storage
- • Token-usage tracking for cost visibility
Webhooks and integrations
Integrations are treated as an extension of your workspace. When webhooks are enabled, production deployments can require a signing secret so only authenticated senders can trigger events.
What is not implemented yet
Formal third-party attestations (e.g., a SOC 2 report issued by an auditor) and advanced data residency controls may be pursued on the roadmap. This page reflects what is currently enforced in code and the controls that are designed for SOC 2 readiness.