Security

Workspace Isolation

How MarcoPolo isolates each user's workspace using dedicated containers.

Every MarcoPolo user gets a dedicated workspace: a separate Kubernetes container that runs in isolation from all other users.

What isolation means

Separate containers. Your workspace is its own container with its own filesystem, DuckDB instance, and process space. No other user's AI agent or workspace shares your container.

No cross-tenant access. User A cannot access User B's files, cached data, query history, or connections. There is no shared filesystem or shared database between workspaces.

Separate credential scope. Each workspace has access only to the connections its owner has set up or been granted access to. Sharing a connection with a colleague creates a separate credential binding, not shared access to your credentials.

Lifecycle

Provisioning. When you first sign in to MarcoPolo (via Google, GitHub, Microsoft, or email), a workspace is created for your user account and associated with your company (based on email domain).

Active use. While you're working, the workspace runs as a live container with compute resources. Your AI operates within this container.

Idle. When you're inactive, the runtime scales down. Your filesystem persists. Files, scripts, cached data, and artifacts are all preserved.

Resume. When you or your AI make a new request, the workspace spins back up. Your files are exactly as you left them.

Shared connections

When you share a connection with a colleague, they get their own binding to that source in their own workspace. They don't access your workspace, and you don't access theirs. The source becomes available in both workspaces independently.

Company-level sharing (all users on the same email domain) works the same way. Each user gets their own isolated workspace with access to the shared connection.

On this page