Security
See how Nebula controls access, handles information and keeps evidence
Data flow
Each step names the service, purpose and safeguard. The public white paper uses the same view.
Protected path
Five steps, with a safeguard at each boundary
Access, processing, storage, AI and proof are controlled separately.
01 Customer boundary
People use authenticated sessions to reach organisation and engagement workspaces.
02 Nebula application
Server routes apply session, organisation, membership and route-specific access checks.
03 Managed data services
The managed database and object storage encrypt data at rest, on the published terms of those providers.
04 Configured AI providers
Redaction applies to configured text fields by default, not necessarily filenames or native PDFs.
05 Proof boundary
Where proof is switched on, an event produces a public record and a second record kept independently. Your documents stay inside Nebula.
Review paths
Data architecture
Source configuration specifies Sydney for Vercel Functions. Records use managed Neon Postgres; documents use Cloudflare R2.
Encryption at rest
The managed database and object storage encrypt data at rest, on the published terms of those providers. Separately, Nebula wraps each user's signing key with AES-256-GCM using a runtime key. Production sessions use signed, encrypted, httpOnly and secure cookies.
Encryption in transit
Application responses set HSTS for two years, including subdomains. Named provider endpoints use HTTPS.
Privacy posture
Nebula removes common identifiers from configured prompt and extracted-text fields before provider processing by default. This covers phone numbers, emails, TFNs, Medicare numbers and driver licence numbers. Public ABNs and ACNs remain. Filenames and native PDF files are not guaranteed to be redacted, and deployment settings can disable this control.
After a 30-day grace period, erasure anonymises the account and selected name copies, disables sign-in, revokes keys and removes notifications. Shared engagement, audit and proof records may remain. Retained canonical proof data can include identifiers and event details.
Who can see what
Signed-in areas require a session. Engagement areas also require party membership. Machine endpoints use their own authentication. Super-admin access passes a separate gate. When Nebula staff enter an organisation's work through support access, Nebula records the acting identity, stated reason, organisation, each engagement reached, and the start and end. The affected organisation can review that read-only record in its account.
Password accounts support TOTP multi-factor authentication with single-use recovery codes, and an organisation can require MFA for its members.
Account protection
Password sign-in is rate-limited. Users can enable TOTP multi-factor authentication with single-use recovery codes, and an organisation can require MFA for password accounts.
Audit trail
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. A 90-day pruning path is configured. Recorded engagement changes and selected exports have separate audit paths.
Classified material
Nebula records and displays four Australian Government classification labels: UNCLASSIFIED, OFFICIAL, OFFICIAL: SENSITIVE and PROTECTED. Labels keep handling requirements visible. Access follows assigned roles, while personnel clearances and handling authority remain part of the customer's approved process.
Before material above UNCLASSIFIED enters an environment, Nebula maps the applicable handling requirements and authority with the customer. A higher-classification deployment follows customer-specific control selection, independent assessment and formal authorisation before use.
Document reading
Each reading uses an available provider and the model selected for that session. Nebula removes common identifiers from configured prompt and extracted-text fields by default; filenames and native PDF files are not guaranteed to be redacted. Nebula's policy excludes customer content from model training.
Frameworks and posture
SOC 2 is an independent CPA examination and report on controls relevant to security, availability, processing integrity, confidentiality and privacy. Nebula maps its control design and evidence to the AICPA Trust Services Criteria used for that examination.
The Australian Government Information Security Manual is the Australian Signals Directorate's risk-based framework for protecting systems and data. Nebula uses it to organise its control and data-handling matrix. IRAP is the assessment pathway for an ASD-endorsed assessor to review an agreed system boundary against applicable ISM controls. Where procurement requires that evidence, the customer agrees the deployment scope, assessor and authorisation decision.
The white paper
The public paper covers authority, architecture, service regions, AI data flows, proof, standards and procurement review.
The white paper
The public paper covers authority, architecture, service regions, AI data flows, proof, standards and procurement review.
Receive the public paper by email
Use the form for an emailed copy. The cover opens the same paper.
Common questions
First questions, answered from these boundaries.
Source code specifies Sydney for Vercel Functions; deployment unverified. Current provider documentation states that the managed database and object-storage services encrypt data at rest. The deployed boundary, key custody and backup coverage cannot be confirmed from current account or applicable contract evidence. Reading providers may process data outside Australia; terms determine location.
No certification is claimed. Controls are mapped to the SOC 2 Trust Services Criteria and informed by the Australian Government ISM. IRAP scope, assessor and authorisation are agreed with the customer.
Nebula's product policy excludes customer documents, their contents and private derived information from model training and cross customer patterns. The signed in application carries no advertising or analytics tracking, and public pages use consent gated measurement only. Provider terms require confirmation for the customer scope.
Yes. The white paper and architecture view are public; deployment-specific evidence is agreed during Enterprise review.
Key engagement moments can be anchored by hash. An anchor attests integrity and timing, not the claim's truth; disputed records remain visibly disputed.
Email security@nebulaplatform.com.au. The draft vulnerability disclosure policy sets the proposed scope and handling process.
Security questions and vulnerability reports: security@nebulaplatform.com.au. Review the draft vulnerability disclosure policy, or review the subprocessor register.
