Documentation menu

Security Architecture

Overview

Printhouse gives an AI agent its own computer in the cloud. That is what makes it useful: it can install tools, edit files, run commands, and work across connected services.

The security model is built around a simple idea: the agent should not be the thing enforcing its own limits.

Here’s how that works.

Credential proxy

The agent never sees your real API keys or OAuth tokens, so it cannot leak them in a message, log, file, or shell command.

Each workspace has two separate components:

  1. Sandbox — where the agent runs. It has the AI harness, your files, and your tools. It does not have your real credentials. Instead, it has dummy placeholder keys.
  2. Credential proxy — a separate process that intercepts standard outbound web traffic from the sandbox. For direct API-key connections, it swaps those placeholder keys for the real credentials at request time.

When the agent makes an outbound request:

  1. The request includes a dummy placeholder key
  2. Standard outbound web traffic is routed through the credential proxy
  3. The proxy matches the request to one of your connections
  4. For direct API-key connections, it swaps the dummy key for the real credential in the right header
  5. For brokered OAuth connections, the request is routed through the broker that holds the OAuth token
  6. The response flows back to the agent

The agent can use the services you connected, but it cannot print, log, or copy your raw credentials because they are not in its environment.

For API-key connections, credentials are encrypted at rest using AES-256-GCM before being stored in the database. They’re only decrypted when loaded into the credential proxy. For OAuth connections managed through Composio, the raw OAuth token lives in Composio’s managed auth layer instead of the agent workspace.

User control lives outside the agent

Printhouse treats the agent runtime as powerful but untrusted. The agent gets a computer to work from. It does not get to rewrite the rules for that computer.

Credentials, network access settings, connected app authorization, and user confirmation flows live in the Printhouse control plane, outside the agent’s sandbox. The agent can request access or propose an action, but it cannot silently grant itself new network access, reveal real credentials, or change the settings that govern what it is allowed to do.

A policy layer inside the same process, filesystem, or container as the agent can be a useful guardrail. It is not the same thing as a boundary. Printhouse keeps the sensitive controls outside the agent’s hands.

Network access controls

You control what your agent can reach on the internet. There are three modes:

Open access

The agent can reach arbitrary web domains. Requests to connected services get automatic credential injection. Requests to other domains pass through without credentials.

This is the default mode, and it works well for normal use: reading docs, researching, hitting public APIs, downloading packages, and generally letting the agent move around.

Connections only

Standard outbound web access is limited to services you have explicitly connected.

If GitHub is connected, the agent can use your GitHub credential with the scopes you authorized. If a service is not connected, the request is blocked.

Use this when you want tighter control over where data can go.

No external access

Standard outbound web access is blocked except for model-provider calls and internal Printhouse platform services required to operate the agent. Connections are inactive.

Use this when you want the workspace to keep working locally without letting the agent reach arbitrary external web services.

Workspace isolation

Every user gets an isolated workspace. Your files, processes, and network namespace are separate from everyone else’s.

Workspaces run under gVisor, a container runtime built for stronger isolation than standard Linux containers alone. gVisor intercepts system calls in userspace, which adds another layer between code running in the workspace and the host kernel.

That does not make arbitrary code harmless. It does give the agent a real place to work without putting it directly on your laptop or on shared host infrastructure.

What this means in practice

Printhouse does not try to make the agent harmless. That would defeat the point.

Instead, it gives the agent a useful workspace and keeps the highest-risk pieces outside that workspace:

  • real credentials are not available to the agent
  • connected apps are deliberately authorized by the user
  • network access can be narrowed to connected services only
  • sensitive platform settings live outside the agent runtime

The result is not magic safety. Prompt injection, malicious code, and bad instructions are still real problems. The point is to make the security model easy to reason about: you can see what the agent can access, keep the highest-risk pieces outside its workspace, and lock the workspace down as tightly as the job requires.