Give your agents tools.
Keep the boundary intact.

The deployment shape.

The agent, Warden, relay and tool container run in the same Fort VM. The backend can run elsewhere.

Fort already runs declared tool-server images as separate Docker containers on the same VM, outside every agent sandbox. You supply the images and declarations; fort apply starts and maintains them. This managed path needs one Fort VM. Your backend systems may live on other servers or networks that the tool container can reach through approved routing.

The agent decides which tool to call. The tool server makes the backend request and holds the backend credential. The agent calls through Warden and the relay; keep backend credentials and direct backend access outside its sandbox. Declaring tool_access authorizes and configures access to a service; the agent's application must still implement an MCP client and use that service.

If the tools currently live inside your agent.

Move the functions that touch the backend, and the SDKs and credentials they need, into a separate MCP server image. Replace the agent's local function calls with MCP calls to that server. Keep reasoning, planning and model calls in the agent image. For example, the tool server can hold a Kubernetes token and expose a narrow get_status operation, while the agent receives the result through the relay.

Fort does not extract Python functions, wrap a stdio server or build images from your agent automatically. In v0, the hosted MCP transport is Streamable HTTP. Package an HTTP adapter in the image when starting with a stdio-only tool server.

Prepare the two images and the backend.

Before applying, have all of these ready:

• An agent image with the correct command, executable paths, user and writable paths. Its MCP client must read the injected tool URL described below.
• A tool-server image pinned by digest, listening on its container interface at the declared port/path. Run it as a non-root user. Implement its declared tools and a health endpoint if you configure one.
• For MCP requests, the tool server must check the x-fort-relay-token header against the injected FORT_RELAY_TOKEN. Let Fort provide that value; do not hardcode or log it.
• Backend DNS, routes, TLS trust and a least-privilege backend identity. A policy declaration does not create VPC peering, backend accounts or database permissions.
• Images that Fort/OpenShell can pull. For a private tool image, store registry credentials as a tool secret of kind registry and reference it with registry_auth. Agent-image registry access must also be configured for its runtime.

The cloud template's bootstrap secret contains installation TLS and sign-in material. Backend tool credentials go into Fort's tool secret store after the project exists. Model credentials are registered separately as providers and stay outside the agent. Do not put these values in Terraform variables, policy YAML or agent env.

Create the project and register credentials.

Run this walkthrough as the user who received the installer's local context. For a manual sudo fort up, that is the invoking operator: continue as that user. The customer Terraform bootstrap runs as root, so for that specific path open root's login shell with sudo -i before the commands below. Do not switch users for a manual installation whose credentials were saved in the operator's home.

Enable the cloud template's SSH option only for your approved source network when using this CLI path. On an established installation, substitute your authorized operator context for --context local. Keep the API private and use approved local or tunneled access; browser sign-in does not configure a remote CLI connection. The initial bootstrap token expires, so use the installation guide's recovery procedure when needed and provision normal operator access for ongoing work.

Plain fort init creates a policy repo containing project default. Create that project on the server before registering its providers and tool secrets:

fort --context local init ./fort-policy
fort --context local project create default --wait
fort --context local --project default provider add anthropic --api-key-file /protected/anthropic.key
fort --context local tool secret set default/ops-backend --from-file /protected/ops-backend.token

Select your actual CLI context, provider and protected credential files. The provider line is an Anthropic example; register only the providers your agent declares. An agent that does not use a model does not need that provider. Skip the tool-secret line for a server that needs no backend credential. Secret values are file contents, never literal command arguments. Keep the complete desired policy repo, including other projects already managed by this Fort installation.

Declare the tool server.

Create fort-policy/projects/default/tool-servers/ops.yaml. This is a template: replace the image/digest, backend, environment names and tool names with your actual server before validating or applying. The server must implement get_status and /healthz if you keep those declarations.

kind: ToolServer
name: ops
image: REGISTRY/TEAM/ops-tools@sha256:REPLACE_WITH_REAL_IMAGE_DIGEST
listen: { port: 8080, path: /mcp }
transport: streamable-http
run_as: "10001:10001"
env:
  BACKEND_URL: https://api.internal.example.com
credentials:
  - { secret: ops-backend, env: BACKEND_TOKEN }
backends:
  - { host: api.internal.example.com, ports: [443] }
resources: { cpus: 0.5, memory_mb: 256, pids: 128 }
health: { path: /healthz }
tools:
  - { name: get_status }

List the actual backend hostnames and IP/CIDR routes the service uses. Fort uses this set to reject agent egress that would bypass the governed tool path. In v0, these backend declarations do not restrict the tool container's outbound destinations; tool containers have outbound access except to the VM and cloud metadata. Treat tool images as trusted code, scope their backend credentials narrowly, and do not rely on VM metadata credentials from inside them.

Fort injects the declared backend secret only into the tool container. It also pulls the pinned image, creates the container on its tools network, provides its relay token, checks health, and handles restarts and replacements. Leave its port private; agents use the relay rather than a public container port.

Give the agent access and configure its client.

Add this fragment to your complete agent declaration in fort-policy/projects/default/agents/<agent>.yaml:

tool_access:
  - server: ops
    rules:
      - id: status-read
        tools: [get_status]
        outcome: allow

Declare the rest of the agent too: its pinned image, command, network-capable executables, resources, providers and egress. Unlisted tool calls remain denied. Use ask rules for actions needing approval and deny for prohibited actions; keep the existing human step-up and self-approval protections.

For a granted server named ops, Fort injects FORT_TOOL_OPS_URL into the sandbox. Read it and pass it to your framework's Streamable HTTP MCP client. A server called my-tools produces FORT_TOOL_MY_TOOLS_URL. Do not set the reserved FORT_* variables in policy yourself or hardcode a container IP.

import os
mcp_url = os.environ["FORT_TOOL_OPS_URL"]
# Configure your agent framework's Streamable HTTP MCP client with mcp_url.

The client must initialize the MCP connection, discover permitted tools and issue tools/call. Handle an ask as a pending human approval, then retry the same call when approved. Do not add backend network access to work around a denied tool call. Use the returned reason code to distinguish policy denial, pending approval and a tool-service failure. Ask your Fort contact for the complete integration reference.

Apply and prove the complete path.

After all placeholders are replaced and credentials are registered:

fort --context local policy validate ./fort-policy --server
fort --context local apply ./fort-policy --dry-run
fort --context local apply ./fort-policy --wait
fort --context local tool get default/ops
fort --context local agent list

--server adds the installed server's provider/secret checks to local validation. A successful apply or a running sandbox alone does not prove a backend operation works. Finish these checks before handing the environment to a customer:

1. The tool server reports Healthy. Check the Tools page in the console too.
2. The agent reaches its intended running state and reads its injected tool URL.
3. From the agent, initialize MCP, list the permitted tools and make one allowed, read-only call. Confirm the backend returned the expected result.
4. Check the corresponding decision in the ledger. A prohibited call must be denied; an ask must wait for a different authorized human's approval and step-up.

If the agent is pending, inspect tool health first. If a sandboxed agent cannot use its tools, check the MCP client URL, tool name and policy rather than opening direct backend access. Useful operator checks:

fort --context local tool get default/ops
fort --context local tool logs default/ops --since 10m
fort --context local agent get default/YOUR_AGENT

Logs require a container to exist. For a pull/start/health failure, check the digest, registry access, non-root user, listen interface, health path and backend routing. A healthy server with failing calls often needs its backend credentials, TLS trust or permissions corrected. Keep credentials and tool arguments out of diagnostic logs.

The SRE/payments demos and their published images are not a prerequisite for this flow. Example images containing placeholder digests are not deployable release images. Use the complete tool-server and policy references supplied with your Fort checkout for all supported fields.