Data Isolation

Data isolation is the foundation of AgenFleet’s multi-tenant security model. The platform is built so that one tenant’s data is structurally inaccessible to any other tenant — not just by policy, but by the architecture itself.

Three-tier isolation model

AgenFleet uses a three-tier isolation architecture:

┌─────────────────────────────────┐
│  Tier 1: Internal Operations    │  Platform operations, billing, admin
├─────────────────────────────────┤
│  Tier 2: Standard Tenants       │  Your organization's agents and data
│  (isolated per tenant via RLS)  │
├─────────────────────────────────┤
│  Tier 3: Enterprise Tenants     │  Dedicated database per tenant
│  (dedicated database schemas)   │
└─────────────────────────────────┘

Standard and Enterprise tenants have no visibility into each other and no visibility into the platform’s internal operations tier.

Row-level security (Standard tier)

Standard plan tenants share a database cluster but have strict row-level security enforced at the database layer.

How it works:

Every table in the tenant database includes a tenant_id column. Row-level security policies are attached to these tables at the database engine level — they enforce tenant boundaries on every SELECT, INSERT, UPDATE, and DELETE automatically.

Why this matters:

Even if the application layer had a bug that accidentally constructed a query without a tenant filter, the database itself would still only return that tenant’s rows. The isolation is enforced at a lower level than the application code — it cannot be bypassed by application logic errors.

Container isolation (per agent)

Each agent runs in its own container with isolated filesystem, environment, network, and process space. Agents belonging to the same tenant are isolated from each other at the infrastructure level — not just at the data layer. One agent cannot read another agent’s files, credentials, or memory regardless of tenant ownership.

Memory store isolation

Each agent’s memory store is a private database scoped to that agent:

No cross-agent memory queries are possible
When an agent is deleted, its memory store is purged within 30 days
Memory contents are encrypted at rest

Even if two agents belong to the same tenant and have the same operator, one agent cannot read or query the other’s memory store. This is by design — shared intelligence must be explicitly engineered via handoffs or shared workspace files, not ambient memory access.

Credential isolation

Credentials (API keys, secrets) stored in the platform are:

Encrypted at rest using AES-256-GCM before database storage
Scoped to a single agent — a credential stored for Agent A cannot be used by Agent B
Never logged — credential values are stripped from all log pipelines before writing
Injected at runtime — credentials are mounted into the agent container as environment variables and are not written to disk

The encryption key for credential storage is stored in an external secrets vault — separate from the database — and is never co-located with the data it protects.

Enterprise: dedicated schemas

Enterprise plan tenants receive a dedicated database schema rather than sharing the multi-tenant cluster. This provides:

Physical separation — tenant data lives in a logically distinct namespace with no shared tables
Independent backup — each tenant’s data can be backed up and restored independently
Compliance documentation — we can provide architecture diagrams and attestations specific to your tenant’s isolation boundary
Custom retention policies — data retention can be configured per-tenant rather than using platform defaults

Contact sales@agenfleet.ai to discuss Enterprise plan options.

Data residency

Standard plan data is stored on infrastructure in the United States. Enterprise plans can negotiate data residency requirements including EU-only hosting for GDPR compliance purposes.