Security
Automation needs control.
This page describes how Zentra is designed to keep automation accountable. Each control carries an honest status. Nothing here claims a certification.
00Controls at a glance
Seven controls, with sample fragments.
Each workspace is a boundary for data, configuration and access.
workspace: acme-ops (sample) scope: events, cases, workflows cross-workspace access: none
Roles and groups decide who can view, approve, edit or administer.
Viewer read signals Operator act on cases Approver decide approvals Admin policies, keys, team
Who did what, when, from where, and with what result.
14:22:09 j.rao policy.update approval_limit Succeeded 14:31:44 api key ops-ingest event.create Succeeded 14:40:02 run_88213 action.execute Succeeded
Integration credentials are stored as secrets and never shown again after entry.
secret: erp-api-token value: •••••••••••••••• last rotated: 12 days ago (sample)
Automation runs in auto, review or blocked mode by policy.
pol_approval_limit if amount > limit → require approval mode: review
Scoped API keys, signed webhooks and rate limits.
key scope: events:write signature: HMAC header (planned) rate limit: per key
Choose how long events, logs and outcomes are kept.
events: configurable audit log: configurable export before deletion: planned
Example fragments use sample data. Zentra does not currently claim any certification.
01Security philosophy
Automation is only useful within limits you define. Zentra is designed around least privilege, complete logging, and people setting the boundaries.
- Least privilege by default
- Every action is recorded
- Humans define policy and approval
02Data isolation
A workspace is the boundary for events, configuration, credentials and users. Cross-workspace access is not part of the design.
- Workspace-scoped data and keys
- Separate configuration per workspace
03Identity
People sign in to a workspace with individual identities. Single sign-on and multi-factor authentication are planned and are not described as available.
- Individual accounts
- SSO: plannedNot yet available
- MFA: plannedNot yet available
04Access
Roles and groups determine who can view signals, act on cases, approve, edit workflows and administer policies.
- Viewer, Operator, Approver, Admin
- Groups and invitations
- Permission checks on every action
05Encryption
Data protection in transit and at rest is a design requirement. Specific implementations will be documented here when they are built and verified.
- In transit: requirementNot yet available
- At rest: requirementNot yet available
06Secrets
Integration credentials are treated as secrets: entered once, never displayed again, referenced by name, and rotatable.
- Write-only secret fields
- Named references in workflows
- Rotation and revocation
07Audit
An audit log answers who did what, when, from where, and with what result, including configuration changes and workflow actions.
- Who, what, when, where, result
- Diff view for configuration changes
- Export: plannedNot yet available
08API security
Scoped API keys, signed webhooks, idempotency and rate limits are part of the API design.
- Scoped keys
- Webhook signatures: plannedNot yet available
- Rate limits per key
09Enterprise controls
Policy modes, approval gates, configurable retention and role management give larger teams control over how automation behaves.
- Auto, review and block modes
- Approval gates
- Configurable retention
10Compliance direction
Zentra is a new product from a newly incorporated company. It does not currently hold any certification or attestation and makes no compliance claim. The intent is to build toward independently audited controls, and this page will state each one only when it has been obtained.
- No certifications claimed todayNot yet available
- Status will be updated here
Sample data is used throughout this site.