Tenancy
Tenants do not share a graph database. The connection is the isolation, not a filter. There is no cross-tenant query to get wrong.
Most multi-tenant systems isolate tenants with a predicate. Every query carries
WHERE tenant_id = ?, and safety depends on nobody ever forgetting it. One
missed filter is a cross-tenant leak.
Gibson's knowledge graph does not work that way.
One database per tenant
Each tenant gets its own graph database instance, in its own namespace. The connection is resolved per call from the tenant on the request.
Graph nodes carry no tenant identifier property at all, because there is nothing to disambiguate. Every node in the database you are connected to belongs to that tenant by construction.
What that gets you: there is no cross-tenant query to get wrong. A query cannot leak across tenants when it omits a filter, because the filter was never the mechanism. Isolation is which database you are pointed at.
If you write graph queries, know the corollary. A WHERE n.tenant_id = ... predicate matches zero rows and silently returns an empty
result. It is not a safety net here. It is a bug.
What else is per tenant
| Resource | Isolation |
|---|---|
| Knowledge graph | A dedicated database instance per tenant, in its own namespace |
| Secrets | Per-tenant storage, reached only through the daemon |
| Component registry | Per tenant — a component published to the platform is not automatically available in your tenant |
| Relational data | Per-tenant databases |
The component registry point connects to Authorization. Reachability requires your tenant to have enabled the component. The platform publishes a component. Your tenant enables it. These are two separate acts.
What is shared inside one tenant
The graph is shared between agents in a tenant, and that is the point of it. What one agent discovers, the next one starts from. A recon agent's findings are available to the agent that triages them, without an export step or a second copy.
Inside the tenant, what a caller may read follows the authorization model's read path. That path includes cross-team data-sharing relations, where a team has a grant to see another team's data. So "shared" does not mean "flat". It means one graph, with grants on top.
What to check
- Each tenant has a dedicated graph database instance in its own namespace.
- Nodes carry no tenant identifier, so a missing predicate cannot bypass isolation.
- A component reaches secrets only through the daemon, never directly.
- A platform-published component is not automatically enabled in a tenant.
Isolation
One gate decides how a component runs. It denies the component, puts it in a Firecracker microVM, or runs it in process. It reads the component's declared content trust and the deployment shape, and it fails closed.
Runtime
How an always-on agent runs. A persistent event-sourced loop, goal missions that never finish on their own, mission constraints as the stop button, and no human approval mid-run.