The grant comes after the explanation.

Security at Vaze: written from the software as built

Effective date: 2026-10-01

1. How operators authenticate

• Federated sign-in only: Google for customers, and Microsoft only for a single pinned directory. Vaze stores no password and offers no local credential.
• The session is an HttpOnly, Secure cookie. The user record and policies are re-read on every request, so disabling an operator takes effect on their next request, not at token expiry.
• Production refuses to start without a configured identity provider and a bootstrap administrator.

2. How access is authorised

• Every console area is gated by live role bindings. Capabilities such as approver, break-glass and manage-members grant no read or write by themselves.
• A Vaze super-administrator can read everything, including the audit trail. There is no narrower Vaze staff role at this release; today that is one person.
• Reads of person-identifying surfaces (rosters, offboarding previews, action detail, report artifacts, delivery recipients, the readiness export) are recorded with signed intent before disclosure and terminal evidence after it.

3. How privileged changes are controlled

• Vendor writes are propose → approve → execute, never direct. Only a narrowly registered kind of action can execute, and only when an operator explicitly runs it.
• Emergency execution requires a bounded written reason and durably consumes the approval.
• When the audit boundary is degraded, actions that would change a vendor are blocked until a host operator acknowledges the condition under a ticket.

4. Audit trail integrity: the clause that carries a ratification

The paragraphs below are the only description Vaze gives of its audit trail's integrity. They are carried verbatim from the engineering readiness ledger, and the site tests fail if this copy and that ledger drift apart or if any page uses stronger language.

Audit trail integrity. Every audit entry carries an HMAC-SHA256 digest computed over its own canonical content and the digest of the entry before it, anchored to a fixed genesis value. Altering, deleting, reordering or inserting any entry that has later entries after it breaks that chain, and the console reports the position of the first affected entry.

The trail is tamper-EVIDENT, not tamper-proof, and it is not a guarantee of completeness. Two limits follow from the design and we state them rather than let silence imply otherwise:

1. Removal of the most recent entries is not detectable by the chain alone. Truncating the end of the trail leaves a shorter but internally valid chain, which verifies. Detecting this requires an external record of what the trail should contain, which this release does not have.
2. A verified chain does not prove that every action was recorded. Where the system knows a write executed but its audit entry could not be appended, that is durably recorded and reported as incomplete rather than silently repaired, but a failure it cannot observe cannot be reported.

The console states both limits alongside every verification verdict, including a clean one.

Key custody. The chain is keyed by a dedicated secret held on the server; the deployment refuses to start in production without one. The secret must remain stable, because historical entries cannot be verified against a different key. The only sanctioned rewrite of an existing trail is an explicit, offline re-chain operation performed by an operator on the host.

At rest. Audit records are stored as files on the application server with owner-only permissions (0600). They are not separately encrypted at the application layer. They are included in encrypted off-box recovery snapshots stored in separate Azure UK South backup storage; those copies follow the independently documented backup, versioning and soft-deletion windows.

Access. A Vaze super-administrator can read the audit trail. There is no separate Vaze staff role with narrower access at this release.

Dated audit records older than 24 months are pruned automatically through the one sanctioned re-chain path when integrity verification passes. The source-tested completed-retirement procedure removes the full named estate trail and replaces its raw ownership identifier and descriptive incident/operator fields through a signed, resumable transition. The signed termination receipt retains its 24-month clock; minimal keyed anti-recreation markers remain permanently, not as a claimed legally anonymous record. Each audit record carries a route family and a structural summary of what was submitted, never raw paths, bodies, targets, reasons or client prose, except for narrow, disclosed exceptions.

5. Infrastructure

• One application host in Microsoft Azure's UK West region. Primary live application state is files on that host; there is no separate application database. Encrypted recovery snapshots are held in separate Azure storage in UK South, as described in section 6.
• The application listens on loopback only. The public path is Cloudflare TLS and an authenticated outbound tunnel to a local reverse proxy. Vaze authenticates console operators and applies the live role bindings described above. Cloudflare Access can additionally restrict private review surfaces; it is not required ahead of every customer console request.
• Files are written owner-only (0600). Storage relies on Azure managed-disk server-side encryption with platform-managed keys, Azure's default; Vaze applies no additional application-level encryption and no customer-managed key.
• State writes are atomic (temp file, fsync, rename). A corrupt or unreadable store refuses to write rather than overwrite. A startup lock refuses a second instance on the same data directory.
• Production runs on Node 24 with a frozen dependency install and a production-only dependency audit on every change. Each release carries a fixed build identity that the host verifies before promotion.

6. Monitoring and continuity

• An external monitor polls the authenticated readiness endpoint every three minutes and e-mails the responder on failure and recovery. Persistent host logs are kept on a bounded budget.
• The dedicated Vaze runtime has a daily encrypted off-host backup to selected-network Azure storage in UK South and an independently escrowed repository password. Its independent 28-day wall-clock retention job is enforced across all seven reviewed snapshot groups; real prune/full-read activation passed on 2026-10-01. Actual failure and recovery notifications passed through the existing external readiness monitor on 2026-09-30. The 27-hour freshness boundary has source/unit proof, not a 27-hour live observation. Exact local-payload disposition and Azure-object expiry remain distinct from activation and are not claimed as completed. An isolated restore passed byte, audit-chain, estate and IAM verification; the release receipt remains in the deployment runbook.
• Estate retirement writes a signed witness outside the snapshot data. The extended 50-check disposable stopped-service rehearsal exercised customer export, confirmed retirement, full terminal-trail minimisation and idempotent rerun. Compatible recovery passes without recreating the named trail; older snapshots are refused without rewriting signed custody. That source rehearsal did not revoke a real provider credential, erase a real recovery copy or shorten the stated recovery windows.

7. Assurance and what we do not claim

• No SOC 2, no ISO 27001, no penetration test, no cyber insurance.
• No 24/7 on-call and no uptime SLA. The monitor above is a detection control, not a service level.
• No intrusion, exfiltration or security-event detection. What the software detects is availability failure, audit-append failure and store corruption.
• Single instance by design: the lock makes a second instance a data-loss risk, not a capacity option, so there is no high-availability story.
• No external ledger or transparency log yet. When one exists, limit 1 in section 4 is removed and the clause is revised; it is not pre-written as though already in place.

8. Reporting something

To report a vulnerability or suspected incident, e-mail security@vaze.ai. Include the affected surface, what you observed and a safe way to reproduce it. Do not send credentials, customer data or destructive proof.

9. Quick answers for a security questionnaire