Trust boundaries and secret classes
Personal and Community vaults stay fully operational offline. Enterprise adds centrally controlled secret classes: for each new delivery of the required key material, the authorized client must pass server-side identity, device and policy checks. Decryption can remain client-side; the coordinator need not see plaintext.
Server-side revocation cannot erase key material already cached or disclosed by a compromised client. Confidential storage and central access control are distinct properties, not an unrestricted guarantee of both full zero knowledge and immediate revocation.
Identity, policy and reauthorization
Principals include employees and machine identities, with organizational membership, device/workload context, groups, roles and per-secret policies. Reading, releasing, editing, rotating and administering are distinct permissions. Fresh key material for strictly controlled secrets is gated on a new server-side decision.
Each decision binds principal, secret ID and version, policy revision, expiry, requested operation and correlation ID. When authorization cannot be verified, new releases for gated secrets fail closed; material already disclosed remains outside that guarantee.
Central audit trail: fields and evidence
Events capture UTC timestamp, event ID, principal or workload, secret ID and version, device/workload context, operation, policy reference, decision and correlation ID. Granted, denied and administrative events are tracked. Never record secret values, tokens, plaintext keys or complete payloads.
A protected central store can use append-only/WORM retention, integrity chains and signed records to detect post-ingestion tampering. An endpoint under attacker control may still hide a local decryption or unobserved copy: audit proves authorized key release, not every subsequent use.
For high-sensitivity policies, acknowledgment of audit ingestion can be coupled to release. If the authorization or audit path is down, the corresponding new key delivery fails closed, trading availability for a strong central decision trail.
Offboarding, exposure inventory and rotation
Revoke identity memberships, roles, devices and workload grants. Correlate releases and recorded access to enumerate potentially reachable secret IDs and versions, including known offline copies or prior key envelopes. Absence of client telemetry is not proof that a secret was never copied.
Rotate or revoke the credential at the external target system, update dependent applications, issue new key generations where needed and track completion. Rewrapping a vault key does not invalidate an API token or password previously copied from the vault.
Machine identities, OIDC and CI/CD
Workloads receive independent principals, narrow scopes, time limits and audit attribution. CI/CD runners authenticate using a trusted OIDC issuer; verify token signature, audience, subject, expiration and context-specific workflow claims before issuing access.
Short-lived leases and least-privilege claims reduce blast radius. Credentials and tokens must not appear in pipeline logs or central audit events. Each granted release records workload, secret version and request correlation. An already copied credential remains valid until expiry or rotation in its target system.
Optional integrations
The policy and release layer remains independent of the storage backend. OpenBao and similar existing enterprise secret managers can be supported later through optional integrations without imposing any server requirement on Personal or Community.
Audit records prove decisions and releases; revocation prevents new authorized releases, not prior copies. Authorization, audit logging, credential rotation and workload identity therefore form one coherent control plane.