Multi-Tenant Agent Platform Architecture: How Mentiko Isolates Workloads

When multiple organizations run agent chains on the same platform, the worst thing that can happen isn't downtime. It's data leaking between tenants. Org A's secrets showing up in Org B's agent output. Org B's chain reading Org A's event files. One noisy tenant's runaway chain starving everyone else's resources.

Multi-tenancy in agent platforms is harder than in typical SaaS because agents execute arbitrary work. They read files, write files, call APIs, spawn processes. Every one of those operations is a potential isolation boundary violation. Here's how Mentiko handles it.

Why multi-tenancy matters for agent platforms

Single-tenant deployments are simple but don't scale economically. Every new customer needs their own infrastructure. Costs grow linearly with customer count.

Multi-tenancy lets you serve many organizations from shared infrastructure while guaranteeing each org's data and execution is invisible to every other org. If you can't prove isolation, you can't close deals with companies that have compliance requirements. And every company that matters has compliance requirements.

The challenge specific to agent platforms is that agents are programs, not just data. A typical SaaS concern is "can Org B read Org A's database rows?" For agent platforms, the concern is "can Org B's agent execute in Org A's filesystem?" or "can Org A's agent prompt injection read Org B's secrets?" The attack surface is wider because the workload is dynamic.

Namespace-based isolation

Every organization in Mentiko gets a namespace. A namespace is the fundamental isolation unit. All resources -- chains, agents, runs, events, secrets, schedules -- are scoped to a namespace. There is no global scope for tenant resources.

The namespace appears in every resource path:

/orgs/{namespace}/chains/
/orgs/{namespace}/agents/
/orgs/{namespace}/runs/
/orgs/{namespace}/secrets/
/orgs/{namespace}/events/

API requests are scoped to the authenticated user's namespace. You can't construct a URL that reaches into another namespace. The API layer rejects any request where the namespace in the path doesn't match the namespace on the authenticated session. This isn't authorization logic buried deep in the application -- it's a middleware check that runs before any handler code executes.

This sounds basic, and it is. That's the point. The simplest isolation mechanism is the one least likely to have gaps. Every fancy isolation technique is built on top of this: if the namespace check fails, nothing else matters.

Org-level resource scoping

The namespace boundary is absolute. Chains in one namespace cannot reference agents in another namespace. Events emitted by one namespace's chains are invisible to another namespace's chains. Run logs are scoped to the namespace that created them.

There's no concept of "shared chains" across organizations. If two orgs want the same chain template, they each fork it into their own namespace. The copies are independent. Sharing mutable resources across trust boundaries creates coupling that eventually becomes a security hole.

The one exception is the marketplace -- a read-only catalog. Forking creates a copy in the forking org's namespace. The marketplace never gives one org write access to another org's resources.

Filesystem separation

Agent execution in Mentiko is filesystem-based. Agents read input from event files, write output to event files, and can interact with workspace files during execution. This is one of the platform's core design decisions -- file-based events are transparent, debuggable, and auditable. But it means filesystem isolation is critical.

Each namespace gets its own directory tree:

/data/{namespace}/chains/
/data/{namespace}/runs/{run-id}/events/
/data/{namespace}/workspace/

Agent execution is sandboxed to the namespace's directory tree. The execution environment (whether local, Docker, or SSH) is configured with the namespace's root as the working boundary. Agents cannot traverse above their namespace root. Path traversal attempts (../../other-namespace/) are caught and rejected before reaching the filesystem.

For Docker-based execution, each namespace's workspace is mounted as a volume scoped to that namespace. The container has no visibility into other namespaces' volumes. For SSH-based execution, the remote workspace path is namespace-prefixed, and the SSH user has permissions only within that prefix.

This is defense in depth. The API layer prevents cross-namespace requests. The filesystem prevents cross-namespace access even if the API layer fails. The execution environment prevents cross-namespace access even if the filesystem permissions fail. Any single layer can fail without exposing data.

RBAC enforcement at the API layer

Within a namespace, Mentiko enforces role-based access control. Roles define what a user can do within their org's namespace:

Owner -- full access to all resources, can manage team members and billing.

Admin -- can create and modify chains, agents, and schedules. Can view secrets (not raw values). Can view all runs and logs.

Operator -- can trigger chains and view run results. Cannot modify chain definitions or agent configurations. Cannot access secrets.

Viewer -- read-only access to run logs and chain definitions. Cannot trigger chains or view secrets.

RBAC is enforced at the API layer, not in the UI. Every API endpoint checks the caller's role before executing. This means the same access controls apply whether you're using the web UI, the CLI, or hitting the API directly. A viewer can't trigger a chain by crafting a raw API request -- the middleware rejects it before the handler runs.

Role assignments are per-namespace. A user can be an admin in one org and a viewer in another. The roles don't bleed across namespace boundaries.

Secrets vault isolation

Secrets are the highest-sensitivity resource in any agent platform. API keys, database credentials, service tokens -- these cause real damage when they leak. Mentiko's secrets vault is namespace-scoped with additional protections.

Secrets are encrypted at rest with per-namespace encryption keys. Decrypting one namespace's secrets doesn't help with another's. Secrets are injected into agent execution environments as environment variables at runtime -- never written to event files or run logs.

The API never returns raw secret values after creation. You can see that a secret named OPENAI_API_KEY exists, but you can't read its value back. You can update or delete it, not retrieve it. This prevents a compromised admin session from exfiltrating secrets.

Agents reference secrets by name. The platform resolves names to values at execution time within the namespace's vault. An agent in namespace A that references DB_PASSWORD gets namespace A's value, even if namespace B has a secret with the same name. Resolution is always namespace-scoped.

Audit logging per org

Every action in a namespace is logged: chain modifications, run triggers, secret access, role changes, member additions. Org admins review their own activity but not other orgs'.

The log captures who, what, when, and from where (IP, user agent, API key vs. session). Logs are immutable -- namespace users can't modify or delete entries. This covers SOC 2 and similar compliance frameworks.

For agent execution, the audit log records which secrets were accessed (by name, not value), which APIs were called, and what files were touched. Unexpected chain behavior gets a full execution trace without exposing secret values.

Scaling considerations

One org running 50 chains simultaneously shouldn't degrade performance for other orgs. Mentiko handles this with per-namespace resource quotas.

Each namespace has configurable limits on concurrent runs, chain count, agent count, and execution time per run. The execution scheduler won't start a new run for a namespace at its concurrency limit, even if the underlying infrastructure has capacity. This prevents the noisy neighbor problem.

Docker-based workspaces use per-namespace resource constraints (CPU and memory limits per container). A runaway agent in one namespace can't starve others.

Queue isolation matters equally. Each namespace's triggers go into a namespace-scoped queue. The scheduler pulls from all queues using weighted round-robin based on plan tier. A namespace that floods its queue doesn't push other namespaces' triggers to the back of a shared line.

The tradeoffs

Multi-tenancy adds complexity. Namespace scoping touches every layer -- API, storage, execution, secrets, logging. Every new feature answers "how does this work across namespaces?" before shipping.

Mentiko supports single-tenant deployment too. Self-hosted installations run as a single namespace with no multi-tenancy overhead. The same codebase handles both modes.

But for the hosted platform and multi-team self-hosted installations, namespace isolation is non-negotiable. A data leak between tenants isn't a bug report. It's a lost customer and a legal event. The architecture reflects that.

Want to see the isolation model in practice? Deploy a self-hosted instance or join the waitlist for the hosted platform.