Verify explicitly
Identity, role, policy and context are evaluated before governed access.
Enterprise security
Trust boundaries before autonomous action.
Zurvina's security architecture connects identity, policy, human approval, bounded execution and verification—while keeping public claims tied to their actual status.
Zero Trust principles
Every request earns its path.
Architecture principles describe the intended control model. They do not replace deployment validation or customer-specific evidence.
Minimize privilege
Tools and data remain bounded to approved responsibilities and purpose.
Assume breach
Reviewability, isolation and controlled recovery shape every consequential path.
Governed path
Security follows the action.
Control is evaluated across the whole path—not added only at execution.
- 01Identity
- 02Policy
- 03Approval
- 04Execution
- 05Verification
Control areas
Broad coverage. Precise claims.
Each statement carries a status and a disclosure boundary. “Designed” and “readiness” are never presented as independent certification.
01Planned
Identity, MFA and strong authentication
Target controls include MFA, phishing-resistant authentication for privileged roles, passkeys/WebAuthn and risk-based session controls.
Current public wording describes the target security foundation. Production-wide privileged-auth evidence is validated separately.02Contract-defined
SSO / SCIM / JIT
SSO via OIDC/SAML, SCIM readiness and JIT-style enterprise access are target Enterprise controls and launch prerequisites.
These are not presented as generally available. Enterprise rollout requires implementation and evidence gates to pass.03Planned
RBAC + ABAC and least privilege
Default-deny authorization, RBAC + ABAC, separation of duties, P3–P4 re-authentication, JIT/JEA and break-glass controls define the target access model.
Role/policy structures in code do not by themselves prove the complete production access model.04Planned
Tenant isolation
Target isolation uses PostgreSQL RLS, tenant-scoped cache/search/memory/object paths, tenant-bound connector accounts and release-blocking cross-tenant tests.
The accepted forensic baseline does not claim commercial multi-tenant production isolation.05Deployment-controlled
TLS and encryption in transit
HTTPS everywhere is a target requirement, TLS 1.3 is preferred, and sensitive service-to-service paths may use mTLS where practical.
This public page does not claim a platform-wide validated TLS baseline beyond separately evidenced deployments.06Planned
Encryption at rest
Database, object storage, queues, logs, search/vector stores, analytics and backups are intended to use approved managed cryptography.
Platform-wide at-rest coverage remains an evidence gate rather than a public certification claim.07Planned
Sensitive-field encryption
OAuth refresh tokens, API secrets, financial identifiers and highly sensitive fields are designed for application-level envelope encryption.
Coverage is validated by data class and deployment; no universal implementation claim is made.08Planned
KMS / HSM-ready key hierarchy
The architecture defines platform and tenant key-encryption keys, purpose-specific data-encryption keys, rotation, revocation, recovery and crypto-erasure design.
“KMS/HSM-ready” does not mean an HSM or full hierarchy is active in every environment.09Contract-defined
Enterprise BYOK / customer-managed keys
Enterprise contracts may add customer-managed keys/BYOK, dedicated key policy, private networking or dedicated environment options.
No current general-availability BYOK claim is made.10Planned
Secrets management
The target rule is Secrets Manager/Vault only, no raw secrets in source, prompts, logs, browser storage or ordinary business columns, with short-lived workload credentials preferred.
Repository secret-scanning evidence does not prove every target secret-management control is live.11Planned
Agent identities and tool allowlists
Each agent/service is intended to have a unique workload identity, tenant scope, registered tools, explicit read/write permissions, budget and kill-switch state.
No agent receives master provider credentials; runtime completeness remains separately verified.12Preview
Approval payload binding
The governance model binds approval to the exact tenant, connector, recipient, amount/cost envelope, policy, risk, expiry and payload hash; material changes invalidate approval.
Public governed-execution pages expose this architecture without claiming every provider path is production-certified.13Planned
Network controls
WAF/API gateway, segmentation, controlled egress, private data plane where practical, rate limits, SSRF defenses and separated management plane define the target network model.
Addresses, ports, rules and topology are intentionally not disclosed.14Planned
Data protection and DLP
Classification, minimization, retention, redaction, export controls, tenant-visible support access and deletion/crypto-erasure workflows define the target data-protection model.
Coverage depends on implemented sources, data classes and approved handling policy.15Planned
Audit and SIEM readiness
Critical audit is designed to be tamper-evident with synchronized time, identity/tenant/action/correlation context, security monitoring and SIEM export readiness.
SIEM readiness is not a claim that a customer SIEM is connected or that production audit immutability has been independently certified.16Preview
Software supply chain
Protected branches, mandatory review, SAST/SCA/secret scanning, SBOM, container scanning, provenance/attestation and signed artifacts form the target release discipline.
Individual repository controls may exist; this page does not elevate them into a blanket compliance claim.17Readiness program
Backup and disaster recovery
Target controls include encrypted access-separated backups, recoverable key material, restore drills, an independent recovery path and ransomware playbooks.
No universal RPO, RTO, restore result or Enterprise DR availability is claimed without environment evidence.18Readiness program
Incident response
The target response model covers detection, containment, session revocation, agent/connector quarantine, key/secret rotation, evidence preservation, recovery, notification, review and remediation.
Operational contacts and runbooks are shared only through governed channels and validated per environment.Operational resilience
Prepare, contain, recover, learn.
Backup, disaster recovery and incident response are treated as an evidence program. Targets and test outcomes remain environment-specific until validated.
- 01Prepare
Define ownership, escalation and approved recovery boundaries.
- 02Contain
Bound impact while preserving reviewable evidence.
- 03Recover
Restore through controlled, deployment-specific procedures.
- 04Learn
Feed corrective action back into governance.
Security FAQ
Ask for evidence, not adjectives.
Public disclosure stays useful without revealing sensitive implementation detail.
Is Zurvina certified or generally compliant?
No blanket certification or compliance claim is made. SOC 2 and ISO/IEC 27001 are not presented as certified, and regulated-industry claims remain gated by legal, privacy, security and evidence review.
Are SSO, SCIM and BYOK available now?
They are Enterprise target/contract-defined capabilities. This page does not claim general availability without runtime and commercial evidence.
Does “KMS / HSM-ready” mean an HSM is active?
No. It describes a target key-management architecture. Active custody, rotation and recovery controls must be verified for the applicable environment.
How are consequential AI actions controlled?
The architecture uses scoped tools, evidence, entitlement/policy checks, P0–P4 risk, human approval, exact payload binding, idempotent governed execution, provider verification and audit.
Can I request security evidence?
Yes. Use the security contact or Trust Center evidence-request path. Availability and disclosure scope depend on authorization and the applicable agreement.
Governed disclosure
Need a security or evidence review?
Start with the public Trust Center or open an authorized conversation about deployment-specific controls. For procurement review, see the data processing addendum request process and the current subprocessor disclosure status.