Security
Clear answers about access, document handling and the services behind Nebula
Data flow
Protected path
Five steps, with a safeguard at each one
The access, storage, reading and proof controls below are applied separately.
01 Customer boundary
You reach organisation and engagement workspaces through an authenticated session.
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
Common identifiers are removed from configured text fields before a provider reads them.
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
Ten controls in four areas, each with the configuration you can check behind it.
Where your information goes and how it is protected.
Data architecture
The containerised application runs on Railway infrastructure. Records use managed Neon Postgres; documents use Cloudflare R2. Hosting configuration names the deployment target, not the region that served a request, and no region is claimed until the deployed region is verified.
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.
Sign-in, membership, elevated access and account controls.
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 your work through support access, the entry is recorded: who entered, the reason they stated, every engagement they reached, and when the session started and ended. Your account keeps that read-only record.
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. Enable TOTP multi-factor authentication with single-use recovery codes, and your organisation can require MFA for password accounts.
Activity records and visible handling requirements.
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.
Model safeguards and the standards shaping Nebula's controls.
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 full architecture and its controls, in a paper you can hand to procurement.
The white paper
The full architecture and its controls, in a paper you can hand to procurement.
Receive the public paper by email
Application hosting is Railway; the deployed region is 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.
We do not use your documents, or private information from them, to train models or build cross-customer patterns. Corrections help later readings in your organisation only. A model provider may process information to run the service; where that happens and how long it is kept depend on provider terms and the customer's confirmed settings. The signed-in application carries no advertising or analytics tracking, and public pages measure visits only with consent.
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 security page sets out how to report a vulnerability and what to include.
Security questions and vulnerability reports: security@nebulaplatform.com.au. Read how to report a vulnerability, or review the subprocessor register.
