> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apollospace.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-tenant model

> How Apollo Space isolates data between organizations at the database level — for security teams that need evidence.

Two companies run on Apollo Space on the same afternoon. In one, a Digital Twin drafts a proposal from last quarter's deals; in the other, a Chief of Staff pulls every overdue invoice for a board update. Both have agents reading across their tools at once. The only acceptable number of rows that cross between the two companies is zero — and that number can't depend on anyone remembering to add a filter.

This page is the evidence behind that zero. It's written for the security team that has to sign off before the rest of your company starts using it.

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="The application connection cannot bypass this">
    The database role used by the application **does not have
    permission to disable the policy**. Even if the application tried
    to "execute without a filter," the database holds the rule.
  </Step>
</Steps>

## 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 |

For an incident to occur, **both layers would need to fail
simultaneously** — highly unlikely.

## How your security team audits

External auditors from your organization can verify the model in two
ways:

<CardGroup cols={2}>
  <Card title="Database configuration inspection" icon="database">
    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.
  </Card>

  <Card title="Automated probe" icon="vial">
    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.
  </Card>
</CardGroup>

## 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

For incidents that require reading customer data (specific bug
debugging, support response), the customer is **notified in a
postmortem** with what was accessed and why.

## 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_id` as an aggregation dimension. Customer
  content is not included.

## Next steps

<CardGroup cols={2}>
  <Card title="Security (general)" icon="lock" href="/en/trust/security">
    Auth, encryption, audit, incident response.
  </Card>

  <Card title="Organizations" icon="building" href="/en/concepts/organizations">
    The role model within an org.
  </Card>
</CardGroup>