The question this page answers
“If I’m an Apollo Space customer and another company is too, what guarantee do I have that a bug or bad actor won’t expose my data to them?”Short answer: isolation enforced at the database level (not just at the application layer), in a mandatory and auditable way.
Why database-level isolation, not just application-level
The naive multi-tenant approach is to filter data by organization in every application-layer query. That works as long as nobody forgets the filter — code review catches 99% of cases, but 1% is enough for a serious incident. Apollo Space enforces the check inside the database itself, through a policy embedded in every table that holds customer data. If the application forgets the filter, the database refuses access — no query that’s “too broad” can succeed.How it works in practice
Session is opened with a clear identity
When processing a request, the backend identifies which
organization is active (via URL + authentication) and marks the
database session with that identifier.
Each query is evaluated against the policy
Before returning any row from a tenant table, the database
checks: does this row belong to the organization active in this
session? Yes → returns it. No → omits it, as if it didn’t exist.
Writes follow the same rule
An INSERT/UPDATE attempting to create a record for a different
org? Rejected by the database with a permission error. There is
no “shortcut” at the application layer.
Defense in depth — two layers
Even though the database does the heavy lifting, Apollo Space also applies the filter at the application layer (belt and suspenders):| Layer | Function |
|---|---|
| Application | Explicitly filters by organization on all queries — enforced via code review + lint |
| Database | Enforces the isolation policy via row-level security — if the application fails, the database blocks |
How your security team audits
External auditors from your organization can verify the model in two ways:Database configuration inspection
Under NDA, Apollo Space provides evidence of the isolation
configuration (policies, roles, grants) for inspection. No
production database access required — the configuration alone is
sufficient.
Automated probe
Apollo Space continuously runs an automated test that attempts
to leak data between synthetic orgs — two test tenants, one
trying to read/write from the other. Any success breaks the
deployment. Evidence of execution is shareable.
Apollo Space internal operations
Apollo Space operators (engineering, support) do not see customer data through casual inspection. The practices:- Production database access is gated — requires escalation + justification + audit trail
- Even with database access, the default session honors the isolation policy — simply logging in is not enough; the org must be identified
- Any privileged access for critical debugging is restricted, logged, and tied to an open ticket — never routine
Known limitations
Honestly:- Multi-tenant backups: database backups contain data from all orgs. Selective restoration (a single org) is manual operational work. In a serious incident, this becomes a project.
- Application logs: log lines may contain organization IDs or small data fragments (in error cases). Logs are retained for 30 days and accessed only by the operations team. They are not shared externally.
- Operational telemetry: aggregate metrics (latency by endpoint,
error rate) include
org_idas an aggregation dimension. Customer content is not included.
Next steps
Security (general)
Auth, encryption, audit, incident response.
Organizations
The role model within an org.