This guide describes controls and boundaries shown in Nebula today. For more architecture and control detail, read the Security and data handling page.
Access and account protection
Signed-in areas require a session. Engagement areas also check party membership. Public and machine routes use their own access rules.
After an API request passes or fails the shared authentication gate, Nebula attempts to record the caller, route, method, decision, user agent and salted IP hash. Routes outside that gate are not covered by this access record.
Password accounts support TOTP multi-factor authentication with single-use recovery codes. An organisation can require multi-factor authentication for its password accounts.
Transport, storage and keys
Application responses configure HSTS for two years, including subdomains. Named provider endpoints use HTTPS.
Operational records use managed Neon Postgres and documents use Cloudflare R2. Current provider documentation states that the managed database and object-storage services encrypt data at rest.
Nebula wraps each user signing key with AES-256-GCM using a separate key supplied to the running service.
Processing location and providers
Source configuration specifies Sydney for Vercel Functions. Database, object-storage and model-processing locations follow the deployed services.
Model reading runs only through Nebula's approved AI providers: a closed registry that records each provider's credentials, capability and activation state before a model can be offered for a session.
The maintained subprocessor evidence register separates provider-published information from Nebula account evidence and identifies unresolved supplier paths.
Text redaction and native documents
Configured prompt and extracted-text fields pass pattern-based redaction by default. This covers common phone, email, tax and identity number patterns. ABN and ACN values remain, and mapped values are restored in model output.
A deployment setting can disable text redaction. Filenames and native PDF files are not guaranteed to be redacted. A native PDF can be sent as a complete document when the selected model supports it.
Nebula's policy excludes customer content from model training.
Account erasure and retained records
A signed-in user can schedule personal account erasure and cancel during the 30-day grace period. A daily caller is configured to process due requests.
Processing anonymises the account and selected identity copies, blocks access, revokes signing keys and connected-provider credentials, and removes the user's notifications. Shared engagement, audit and proof records can remain.
This self-service path covers a user's account. It does not establish organisation-wide deletion or removal from every provider copy and backup.
Proof records
Supported item transitions can attempt separate Polygon and Nebulad proof records. Nebulad requires its gateway, actor and signing key. Some other proof events use Polygon only.
The public verifier reports each available network result. When saved event data exists, Nebula recalculates its hash first. Older records without that data receive a network-only check.
Verification checks record integrity. It does not establish the truth, fairness or authority of the business statement. Read Proof you can check for the visible result boundaries.
Control references
SOC 2 Trust Services Criteria and the Australian Government Information Security Manual inform Nebula's control-design material. A mapping is not an examination, certificate, assessment or authority to operate.
IRAP is a pathway for an ASD-endorsed assessor to review an agreed system boundary against applicable ISM controls. The enterprise readiness page separates current product controls from evidence that requires deployment-specific verification.
Audit and integrity paths
Successful item status transitions write activity records. Selected export paths attempt to write export records. The shared authentication access record is a separate, best-effort path.
A daily caller is configured to check up to the oldest 1,000 confirmed proof records against available network data. A hash mismatch can create an integrity alert.