Tool Worker Policies

Overview

A tool worker policy controls what tools are available when an agent calls out to external systems. Each policy is embodied by a tool connector key — a string in tools.{id}.{secret} format.

The tools worker binary (auxot-tools) connects to Auxot using that key. On connect, the server sends the full policy back: which built-in tools are enabled, and which MCP servers to start. The worker:

Starts each configured MCP server as a subprocess via npx -y <package>@<version>
Calls tools/list on each subprocess to discover available commands
Reports the full tool schema back to the server
Routes incoming tool calls to the correct subprocess at request time

The key is the policy. Whoever holds the key gets exactly the tools defined in it — no more, no less.

Built-in Tools

Each policy can enable or disable the following built-in tools:

Tool	What it does	Requirement
`web_search`	Web search via Brave Search API	Requires `BRAVE_API_KEY` in the tools worker environment
`web_answers`	Summarized answers from Brave Search	Requires `BRAVE_API_KEY`
`web_fetch`	Fetches and extracts content from a URL	None
`code_executor`	Runs sandboxed code (Python, JS, shell)	None

Toggle individual tools on or off in the policy editor. An agent that doesn’t need web access shouldn’t have web_search enabled.

MCP Servers

MCP servers are npm packages. You configure them inside a policy by specifying the package, version, environment variables, and which commands are enabled.

Adding an MCP server

In Settings → Tool Policies, open a policy and click Add MCP Server. Fill in:

Package — the npm package name, e.g. @modelcontextprotocol/server-github
Version — e.g. latest or a pinned version like 1.2.0
Env vars — one or more environment variables the MCP process needs (see Credential Sources below)
Commands — after the worker connects, discovered commands appear here; toggle individual ones on or off

Via the admin agent:

Add a GitHub MCP server to the engineering tool policy:
- package: @modelcontextprotocol/server-github
- version: latest
- GITHUB_TOKEN from the oauth source (github)

How the model sees MCP tools

The LLM sees MCP servers as aggregate tools — one tool per MCP server slug, not individual commands. For a GitHub MCP server with slug github, the model calls:

{
  "tool": "github",
  "command": "create_issue",
  "arguments": {
    "owner": "acme",
    "repo": "backend",
    "title": "Fix null pointer in payment handler"
  }
}

This keeps the tool schema compact regardless of how many commands the MCP server exposes. Individual commands you don’t want accessible can be disabled in the policy.

Credential Sources

Each environment variable on an MCP server config has a source that tells the worker where to get the value at runtime:

Source	Description	Example use
`static`	A literal string value baked into the policy	Non-secret config like a base URL or region
`org_secret`	A credential stored at the organization level	A shared service account API key
`team_secret`	A credential stored at team scope	A team-specific database password
`user_secret`	A credential at user scope — requires the user to set it in their profile	Personal API tokens
`oauth`	Resolves the calling user’s OAuth access token from a connected OAuth provider	GitHub, Google, Slack — per-user, auto-refreshed

Credentials from org_secret, team_secret, and user_secret are encrypted at rest with AES-256-GCM using AUXOT_SECRET_KEY. They are never returned in API responses, never logged, and only decrypted in memory inside the tools worker process.

OAuth-Backed MCP

The oauth source is what enables per-user MCP authentication. Instead of a shared service account token, each user’s MCP calls are made with their own OAuth access token — automatically refreshed if expired before being injected into the subprocess.

Example: GitHub MCP with per-user OAuth

Setup:

Configure a GitHub OAuth app in Auxot (Settings → OAuth Providers, client ID + secret).
In the tool policy, add the GitHub MCP server. Set GITHUB_TOKEN env var with source oauth, provider github.
Users connect their GitHub account in their profile (Settings → Connected Accounts).

At runtime: when a user’s agent calls the github tool, the worker resolves that user’s stored GitHub OAuth token, injects it as GITHUB_TOKEN into the MCP subprocess environment, and executes the command. If the token is expired, it’s refreshed first.

This means:

Alice’s github calls use Alice’s token — she sees the repos she has access to
Bob’s github calls use Bob’s token — scoped to his permissions
No shared service account. No over-provisioned API key.

User connection required: If a user hasn’t connected their GitHub account and tries to use a tool backed by oauth source, the tool call will fail with a message prompting them to connect the account in their profile.

Managing Policies

Settings UI

Settings → Tool Policies shows all tool connector keys in your organization. Click a key to open the policy editor:

Toggle built-in tools on/off with credential status indicators
Add, edit, or remove MCP servers
Configure env var sources for each MCP server
Enable/disable individual MCP commands
Assign the policy to teams
Regenerate the key (old key is immediately invalidated)

Admin agent commands

Create a tool key for the engineering team with GitHub MCP and web_fetch enabled.
GITHUB_TOKEN should use the oauth source with the github provider.

Assigning to Teams

A tool connector key can be restricted to specific teams. Use this to keep sensitive integrations scoped to the right group.

This is how you give the engineering team GitHub access without exposing it to the support team — create separate policies with appropriate team assignments.

Assign the engineering-tools key to the Engineering and Platform teams.

Tool policies are the boundary for what external capabilities an agent can reach. Keep them narrow — a focused policy is easier to audit and rotate than a single key that does everything.