Facio's Workspace Boundaries: How AI Agents Keep Each Customer's Data Strictly Separated

An AI agent that serves multiple customers needs hard boundaries between them. Customer A's memory must never bleed into Customer B's session. Customer B's credentials must never authorize operations on Customer A's systems. Customer C's context must never appear in Customer A's outputs.

A naive multi-tenant agent has no concept of boundaries. The agent's memory is shared across customers. The agent's credentials are global. The agent's context is a single stream. The first time two customers work with the agent concurrently, they may see each other's data, accidentally trigger each other's actions, or step on each other's workflows. The result is a data breach, a credential leak, or an operational mess — depending on which boundary was violated.

Facio's workspace boundaries are the structural discipline that enforces tenant isolation at the runtime level. Every file path, every credential, every memory, every tool call is scoped to a workspace the agent cannot cross. The boundaries are enforced by the runtime, not by the agent's carefulness. The agent cannot accidentally violate a boundary because the boundary is in the architecture.

Here's how the boundaries work, what they cover, and why tenant isolation is what makes multi-tenant agent platforms viable.

The Multi-Tenant Boundary Reality

Multi-tenant AI agent platforms serve many customers from shared infrastructure. The customers may be on different teams, in different organizations, or in different industries. Their data, their workflows, their credentials, and their compliance requirements are different.

The boundaries that need to be enforced are extensive:

Data boundaries. Customer A's memory, files, conversation history, and audit logs must not be accessible to Customer B. The data may be on the same disk, in the same database, or processed by the same model. The boundary is logical, not physical.

Credential boundaries. Customer A's API tokens, database passwords, and OAuth grants must not authorize Customer B's operations. The credentials may be in the same vault. The boundary is logical, not physical.

Context boundaries. Customer A's session context must not contaminate Customer B's session. The context may pass through the same LLM. The boundary is logical, not physical.

Operational boundaries. Customer A's scheduled tasks, cron jobs, and heartbeat operations must not affect Customer B's resources. The operations may run on the same scheduler. The boundary is logical, not physical.

Audit boundaries. Customer A's audit trail must not contain Customer B's activities. The audit log may be in the same store. The boundary is logical, not physical.

A platform that doesn't enforce these boundaries has cross-tenant data leaks. The leaks may be rare (only triggered by specific edge cases) or frequent (any time two customers share context), but they exist. The platform's security model is "the agent is careful," and "careful" isn't a security model.

The Workspace Primitive

Facio's isolation primitive is the workspace. Every agent operation is scoped to a workspace. The workspace is identified by a unique ID; the workspace has its own filesystem root, its own credential vault, its own memory namespace, its own tool scope, and its own audit log.

# Workspace structure
workspace = {
    "id": "ws_acme_corp",
    "owner": "customer_id_acme",
    "filesystem_root": "/data/workspaces/ws_acme_corp/",
    "memory_namespace": "acme_corp",
    "credential_vault": "vault://ws_acme_corp/credentials",
    "tool_scope": ["slack-mcp", "github-mcp", "postgres-prod-mcp"],
    "audit_log": "/data/audit/ws_acme_corp/audit.jsonl",
    "scheduled_tasks": ["cron:ws_acme_corp:*"],
    "rate_limits": {"tokens_per_minute": 50000, "sessions_per_day": 1000},
    "created_at": "2026-01-15T08:00:00Z"
}

The workspace is the unit of isolation. The agent operates within one workspace at a time. The agent's tools, memory, files, credentials, and audit log are all scoped to that workspace.

When the agent runs for Customer B, the agent operates in a different workspace. The runtime ensures the workspaces don't cross.

The Boundary Enforcement Layers

Facio enforces workspace boundaries at multiple layers, each catching a different class of violation.

Layer 1: Filesystem Isolation

The agent's file tools (read_file, write_file, edit_file) operate within the workspace's filesystem root. Any path that resolves outside the root is rejected:

# Inside workspace: OK
read_file(path="MEMORY.md")
# Resolves to /data/workspaces/ws_acme_corp/MEMORY.md
# Permission check: OK

# Path traversal attempt: BLOCKED
read_file(path="../../workspaces/ws_other_customer/MEMORY.md")
# Resolves to /data/workspaces/ws_other_customer/MEMORY.md
# Permission check: BLOCKED
# Error: "Path traversal not allowed: path escapes workspace root"

The filesystem isolation uses the OS-level chroot or namespace where available, providing defense in depth. Even if the agent reasons about paths, the OS prevents access to other workspaces.

Layer 2: Credential Vault Scoping

The agent's credentials are scoped to the workspace. The agent sees only the credentials assigned to the workspace; the runtime prevents credential use outside the workspace's scope:

# Inside workspace: credential resolved
exec(command="psql -h prod-db.acme.com -c 'SELECT 1'")
# Runtime looks up: ws_acme_corp has credential for prod-db.acme.com
# Credential injected: yes
# Result: success

# Cross-workspace credential attempt: BLOCKED
exec(command="psql -h prod-db.other-customer.com -c 'SELECT 1'")
# Runtime looks up: ws_acme_corp does NOT have credential for prod-db.other-customer.com
# Permission check: BLOCKED
# Error: "No credential authorized for prod-db.other-customer.com in this workspace"

The credential vault scoping prevents credential misuse across workspaces. Even if the agent somehow knows another customer's credential ID, the credential isn't accessible.

Layer 3: Memory Namespace Isolation

The agent's memory operations (recall, edit_file on MEMORY.md) are scoped to the workspace's memory namespace. Queries for memories only return memories from the workspace:

# Inside workspace: memories retrieved
recall(query="user preferences")
# Searches in: ws_acme_corp's memory namespace
# Results: 5 memories, all about Acme Corp's preferences

# Cross-workspace memory access: BLOCKED
# (The agent has no way to even specify another workspace's memory)
recall(query="user preferences", namespace="ws_other_customer")
# Error: "Namespace ws_other_customer is not authorized in this workspace"

The memory namespace isolation is automatic. The agent's recall queries only return memories from the current workspace.

Layer 4: Tool Scope Limitation

The agent's tools are scoped to the workspace. A workspace may have access to certain MCP servers, certain shell commands, certain APIs. The agent cannot invoke tools outside the workspace's scope:

# Inside workspace: tool available
mcp_slack.send_message(channel="#acme-alerts", text="...")
# Workspace ws_acme_corp has Slack MCP in tool scope
# Result: message sent

# Tool not in scope: BLOCKED
mcp_finance.query_database(query="...")
# Workspace ws_acme_corp does NOT have Finance MCP in tool scope
# Error: "Tool 'mcp_finance' is not available in this workspace"

The tool scope limitation is set per workspace. Different customers can have different tool access, based on their subscription tier, their configuration, or their security requirements.

Layer 5: Context Window Scoping

The agent's context window is per-session. Sessions are scoped to workspaces. The runtime ensures that the model never receives context from a different workspace:

# Session for ws_acme_corp: context contains Acme data
session_context = {
    "system_prompt": "You are an agent for Acme Corp...",
    "memory": [Acme Corp memories],
    "conversation_history": [Acme user interactions],
    "tool_results": [Acme-specific results]
}

# Different session for ws_other_customer: context contains Other data
session_context = {
    "system_prompt": "You are an agent for Other Co...",
    "memory": [Other Co memories],
    "conversation_history": [Other user interactions],
    "tool_results": [Other-specific results]
}

The two sessions operate with disjoint contexts. The model never sees both contexts. There's no path for context to leak between workspaces.

Layer 6: Audit Log Scoping

Every audit log entry is tagged with the workspace ID. Audit log queries are filtered by workspace:

# Workspace ws_acme_corp's audit log
audit_log_ws_acme = [
    {"timestamp": "...", "workspace": "ws_acme_corp", "action": "..."},
    {"timestamp": "...", "workspace": "ws_acme_corp", "action": "..."},
    ...
]

# Query: audit log for ws_acme_corp
read_logs(grep="agent action")
# Returns: only entries with workspace = ws_acme_corp
# Other workspaces' logs: not included in the results

The audit log scoping ensures that operators can review one customer's activity without seeing other customers' data.

The Cross-Workspace Operations

Some legitimate operations span workspaces. The boundary enforcement accommodates these through explicit cross-workspace grants:

# Explicit grant: workspace A can read a specific file in workspace B
grant = {
    "granting_workspace": "ws_partner_data",
    "receiving_workspace": "ws_acme_corp",
    "scope": "read:/data/workspaces/ws_partner_data/shared-inventory.json",
    "expires_at": "2026-07-10T00:00:00Z",
    "approved_by": "partner_admin_user"
}

# Cross-workspace read: ALLOWED (with grant)
read_file(path="/data/workspaces/ws_partner_data/shared-inventory.json")
# Runtime sees the grant
# Permission check: OK (read is in scope)
# Result: file contents returned

Cross-workspace operations require explicit grants. The grants are scoped (read-only, specific path), time-limited, and auditable. The default is deny; the grant is the explicit permission.

The Boundary Violation Detection

Even with enforcement, the runtime detects attempts to violate boundaries and alerts:

# Detection: agent attempted path traversal
alert = {
    "severity": "high",
    "type": "boundary_violation_attempt",
    "workspace": "ws_acme_corp",
    "session_id": "...",
    "attempted_action": "read_file with path resolving outside workspace",
    "attempted_path": "../../workspaces/ws_other/MEMORY.md",
    "blocked": true,
    "notification_sent_to": "security_team@acme.com"
}

# Detection: agent attempted unauthorized credential access
alert = {
    "severity": "critical",
    "type": "unauthorized_credential_access",
    "workspace": "ws_acme_corp",
    "session_id": "...",
    "attempted_action": "use credential not in workspace scope",
    "credential_ref": "ws_other_customer/database",
    "blocked": true,
    "notification_sent_to": "security_team@acme.com, ciso@acme.com"
}

The detection logs the attempt, blocks the operation, and notifies the security team. The team can investigate whether the attempt was a bug, a misconfiguration, or an attack.

The Workspace Lifecycle

Workspaces have a full lifecycle, managed by the runtime:

Creation. When a customer signs up, a workspace is provisioned with default isolation settings, default tools, default credentials (none), default rate limits.

Configuration. The customer's admin configures the workspace: adds credentials, enables tools, sets rate limits, configures retention.

Operation. The workspace operates normally. Sessions, tasks, and audits are scoped to the workspace.

Suspension. If the customer fails to pay, violates terms, or requests suspension, the workspace is suspended. Sessions are blocked; credentials are revoked; data is preserved.

Deletion. When the customer requests deletion (or after a retention period), the workspace is deleted. Files, memories, audit logs, credentials are all removed. The deletion is logged for compliance.

The lifecycle is managed through the platform's admin interface, with appropriate RBAC for customer admins vs. platform admins.

The Workspace Boundaries Don't Do

Honest limitations:

• They don't prevent the model from learning across customers. The underlying LLM is shared; the model's weights are shared. Cross-customer learning happens at the model level, not the application level. The boundaries protect runtime data, not the model's training data.
• They don't prevent side-channel leaks. Sophisticated attackers may infer information through side channels (response times, error patterns, resource usage). The boundaries prevent direct leaks but not inferential leaks.
• They require correct configuration. A workspace with overly permissive tool scope or over-broad credential grants weakens the boundaries. The boundaries are only as strong as the configuration.
• They can break legitimate cross-customer workflows. If Customer A needs to process data from Customer B, the boundaries require explicit grants. The grants add friction to legitimate operations.
• They don't substitute for the customer's own security. The customer is responsible for securing their credentials, configuring their tools, and managing their own users. The platform's boundaries protect against cross-tenant issues, not against the customer's own issues.

The Boundary as a Foundation

Workspace boundaries are a foundation, not a complete security model. The foundation enables:

• Multi-tenancy. Multiple customers on shared infrastructure without data leakage.
• Compliance. DSGVO, SOC 2, ISO 27001 — all require data isolation; the boundaries provide it.
• Trust. Customers trust the platform because the boundaries are architectural, not behavioral.
• Operability. The platform team can scale the infrastructure without worrying about customer data mixing.

Without the boundaries, multi-tenant platforms are unsafe. With the boundaries, they're viable. The boundaries are the difference between a prototype and a production multi-tenant platform.

Bottom Line

An AI agent that serves multiple customers needs hard boundaries. Memory, credentials, files, tools, contexts, and audit logs must not leak across customers.

Facio's workspace boundaries enforce tenant isolation at the runtime level through six layers: filesystem isolation, credential vault scoping, memory namespace isolation, tool scope limitation, context window scoping, and audit log scoping. The enforcement is architectural, not behavioral. The agent cannot accidentally violate a boundary because the boundary is in the architecture.

The platform without boundaries is unsafe for multi-tenancy. The platform with boundaries is production-ready. The customers trust the production-ready one.

Because multi-tenant AI agents are valuable. Multi-tenant AI agents without isolation are dangerous. The boundaries are what makes the value safe.

---

See the workspace boundaries documentation for workspace configuration, cross-workspace grants, and boundary violation monitoring.