What it can do, and as whom

Every session stores its owner when it’s created, and the host compares that owner to the verified caller on every connect and every task. So leak or guess a sessionId and you still can’t resume someone else’s conversation.

Long-term memory is namespaced by the verified sub (/facts/{sub}, /users/{sub}/preferences), not by anything the client sends. Recall never crosses users.

Autonomous work runs as one of two identities, and they don’t get the same trust. { type: "user", id: sub } is a verified person, and it’s the default for POST /agent/tasks. { type: "system", id: "booked" } is a service with nobody behind it. A first-party emitter on the internal bus can claim a system principal for free, because only first-party code can reach that bus. Over the public API, claiming one is a privilege.

# sub abc-123 may run as "booked" only; svc-sub may run as any system id
SystemTaskPrincipals="abc-123:booked,svc-sub:*"

In a shared hosted runtime, shell exec is remote code execution, and filesystem access reaches the host’s disk. No thanks. A host that really wants them can import them from the SDK and register them itself, as an explicit choice that shows up in code review.

What a session can use is a registry of named first-party tools. Turning on a tool that already ships is a data change. Writing a new one is the only time you touch code.

import { tool, builtinTools, resolveTools, createAssistant } from '@readysetcloud/agent';
import { z } from 'zod';

// Host registry: built-ins plus the host’s own.
const TOOL_REGISTRY = {
  ...builtinTools,                                   // http_request, notebook
  get_current_time: () => tool({
    name: 'get_current_time',
    description: 'Returns the current server time as an ISO-8601 string.',
    inputSchema: z.object({}),
    callback: async () => new Date().toISOString(),
  }),
};

// A session opts in by name: { tools: ['http_request', 'get_current_time'] }
const tools = resolveTools(config.tools, TOOL_REGISTRY, { sessionId, userId });
const agent = createAssistant({ sessionId, tools: [...tools, ...mcpClients] });

Attaching an MCP server is the one place a session gets to point the runtime at an outbound URL, so it gets the most scrutiny. Servers are keyed by label, and the host connects to each one at build time and adds its tools alongside the first-party ones. Secrets never live in the session row, since users create those. They come from the host’s environment through ${VAR} interpolation.

await createSession({
  userId,
  mcpServers: {
    blog: {
      url: 'https://mcp.example.com/mcp',
      headers: { 'x-api-version': '2025-01' },        // user-supplied; ${VAR} interpolated by the host
      authHeader: {                                     // authority-minted, forwarded verbatim
        name: 'x-booked-auth',
        value: '<base64url(payload)>.<sig>',
      },
    },
  },
});

The other outbound door is the http_request built-in, which lets the model pick the URL. Turn it on deliberately, and put a fence around egress when that matters.

The runtime is just a courier. A trusted server-side session creator mints a token that binds tenant, user, session, and a version. The runtime forwards it verbatim, after the user’s headers so they can’t shadow it, and never looks inside. The MCP server checks the signature with a shared secret.

The threat model, plainly: the HMAC proves the authority minted this token for user U. It does not prove the presenter is this runtime. That’s fine here because users can’t reach the config row, the host is allowlisted, and transport is TLS. The token gets replayed on every reconnect for the session’s ~30-day life, so bind it to the sessionId and include a version the authority can bump to revoke it.

Library mode means passing tableName and running the core in your own stack, which is exactly how every persistent agent runs. It doesn’t get the shared runtime’s guarantees for free. Your stack owns the Bedrock grant, the allowlist, and memory isolation.