Built for
regulated work.

All client data is stored and processed in Australian regions. The default deployment runs on Vercel infrastructure in the Sydney region and Supabase Postgres in the Sydney region — the database, storage buckets, and Realtime channels all hosted within Australian jurisdiction.

Each client deployment is dedicated cloud infrastructure: its own Supabase project, its own Vercel project, its own AES-256 encryption keys. There is no shared multi-tenant database. A stolen API key from one tenant cannot read another tenant's data because the boundary is enforced at infrastructure level, not by application logic.

For clients with stricter sovereignty requirements — government, IRAP-assessed deployments, certain APRA-regulated entities — an on-premise deployment path is available via Docker Compose with local LLM inference through Ollama. In that configuration, no client data leaves the building.

Bulk data is encrypted at rest with AES-256-GCM. Per-organisation encryption keys are derived via scrypt KDF from a master key held in Vercel's environment-variable store and rotated on a documented schedule.

Sensitive PII columns — participant identifiers, NDIS numbers, contact details, free-text clinical notes, BSP narratives — carry an additional column-level encryption layer using a separate key. A compromise of the bulk database key alone does not expose personal information.

Transit is TLS 1.3 with HSTS preload, modern cipher suites, and certificate pinning on mobile clients. The Content Security Policy is strict. X-Frame-Options is DENY. The Permissions-Policy explicitly disables camera, microphone, geolocation, payment, and the dozens of other browser APIs the platform does not need.

Before client data reaches an external AI model, the privacy router replaces seventeen categories of personal information with reversible tokens — full names, given names, surnames, email addresses, phone numbers, postal addresses, dates of birth, ABNs, ACNs, TFNs, Medicare numbers, NDIS participant numbers, bank accounts, BSBs, driver licences, passports, IP addresses.

The reverse-mapping table lives only inside the client's own Supabase project, encrypted with the client's per-organisation key. The AI model receives TKN_a8f2c1 instead of the raw value. The output is detokenised back to plaintext only when it is delivered to the authorised user inside the client's browser session.

The architectural consequence: even if a model provider were compromised, the data they hold is structurally meaningless. SydClaw operates on a zero-knowledge basis with respect to its model providers — they process tokens, not personal data.

Every AI action — every prompt, every tool call, every approval, every data access, every guard evaluation — is logged to an immutable audit trail. Each entry contains the inputs the system relied on (with PII handled separately), the prompt template, the model and version, the timestamp, the human who reviewed and approved the result, and the action taken.

The audit log uses a SHA-256 hash chain: every entry's hash includes the previous entry's hash, so any tampering after the fact is mathematically detectable. RESTRICTIVE row-level security policies on the audit_log table prevent UPDATE and DELETE operations even by authenticated database users with service-role privileges.

The only way to write a new row is through an append-only RPC that acquires a transaction-scoped advisory lock to serialise concurrent writers and prevent chain forks. This is the audit trail the Privacy Act 2026 ADM transparency provisions require — when a regulator or affected individual asks how a decision was made on a specific date, the export takes seconds and the chain is cryptographically defensible.

Authentication is via Supabase Auth with multi-factor authentication required for all users. TOTP-based MFA — Google Authenticator, Authy, 1Password compatible — is enforced at session start. Sessions are locked at AAL1 until MFA is completed. Backup codes are generated on enrolment and rotated on use.

Authorisation uses role-based access control with four levels — Admin, Manager, User, Viewer — combined with PostgreSQL row-level security policies that enforce organisation isolation at the database layer. Every query is scoped to the authenticated user's organisation. Department-scoped data access is configurable per role; tool-level permissions are configurable per action.

For high-risk actions — sending payments, deleting records, approving large purchase orders, lodging Commission notifications — TOTP re-verification is required even within an active session. This prevents a stolen session token from approving destructive operations. For enterprise deployments, SSO/SAML is supported with SCIM provisioning for user lifecycle management. We have integrations published for Okta, Azure AD / Entra ID, and Google Workspace.

Incidents are detected through a combination of anomaly monitoring on the audit log, error-rate alarms on Sentry, latency alarms on Vercel, and the platform's own internal heartbeat checks. Detection-to-acknowledgement target is under 15 minutes during business hours.

Containment is documented in the Incident Response SOP and includes immediate session revocation for compromised accounts, key rotation for compromised encryption material, and forensic-snapshot procedures for the Supabase project. The Notifiable Data Breaches scheme requires notification to the OAIC and affected individuals within 72 hours where the criteria are met. SydClaw's runbook is calibrated to that timeline with internal alerting set well below it.

Post-incident review produces a written root-cause analysis within 14 days. Remediation actions are logged against the operations register and tracked to closure. Every incident is added to the APRA CPS 234-style asset incident register that ships with the platform, regardless of whether the client falls under APRA jurisdiction.