how it worksreach

Cast draws the reach

An agent holds personal information. The harness keeps it sealed by default, and lets you open it deliberately, in both directions.

What the agent holds

An agent accumulates things about you: what you've told it, what your participants have said, the work it has done on your behalf. Over time it becomes a small, specific record of your life, addressed to you, written down in memory/, sitting in a folder on your disk.

That makes the agent a single security surface worth protecting. The reach question is simply: what can touch this surface, and on whose say-so?

Sealed by default

fig. 1: the default perimeter
out of boundsharnessagent

By default the agent runs in its own sandbox. It cannot read your filesystem beyond the folders you mounted. It cannot reach the network beyond the Anthropic SDK (the API it uses to think). And nobody can reach in to talk to it without you having explicitly let them.

That floor is not enforced by asking the model nicely. It's enforced mechanically, by the container the agent runs in, the mount table the harness fixes, and the network policy the operator sets. The agent has no path around any of it.

Letting the agent reach out

fig. 2: outbound gateways
internetharnessnetworkextensionserviceagent

When the agent needs to do more than think (fetch a web page, call an API, read your calendar), you give it a deliberate way out. Three of them, in order of escalating trust:

The tradeoff is the same shape each time: more reach, more functionality, more surface area you're vouching for. Cast doesn't pick for you. It exposes the choice.

MCP is supported as an escape hatch for connecting to third-party servers, but we don't currently recommend it. The trust surface is unsettled. Each MCP server is third-party code, and the agent reads its tool descriptions and outputs directly as context, so a compromised server can manipulate the agent through either. The admin console has the full caveats before you turn one on.

Letting people reach in

fig. 3: inbound gateways
harnesstelegramwebagent

The other direction matters just as much. The agent listens on transports, the protocols by which people contact it: CLI, web, telegram, and so on. A transport is just a wire. On its own it grants nothing.

When a message arrives, the identity provider resolves who the sender is. A stranger gets a fresh identity but no permissions, and their first message is held. To let them in, you approve that held message from the dashboard, once or for good. An allow-always grant is durable, and from then on the agent recognizes them.

That approval is the gate at the front door. Without it, no inbound message earns the agent's real attention. With it, a specific person, at a specific transport, can carry on a real conversation, and their messages accrue into the agent's memory addressed to them.

Where Cast's guarantees end

Cast secures the perimeter mechanically. What sits inside the perimeter is your judgment, not Cast's: the extensions you've installed, the service code you've written, the laptop the harness runs on, the operator at the keyboard. If you install a malicious extension, it runs. If your laptop is compromised, the agent is compromised. The sandbox protects your other things from the agent, not the other way around.

That's the honest scope. The mechanical guarantees do real work, and the rest is the standard developer-on-their-own-machine trust model.