Agent broker

The agent broker is a hosted MCP server that gives an AI coding agent — Claude Code, Cursor, Codex — the ability to use your credentials without ever reading them. Instead of pasting a Stripe key or a database password into a prompt (where it lands in the model’s context, your logs, and the provider’s servers), you connect the agent to Veil once. From then on the agent asks Veil to make the call, and Veil injects the secret at the network edge. The agent sees the API response; it never sees the key.

This is the core idea of Veil Keys, applied to autonomous agents: secrets are used, never read.

What the agent can do

Once connected, the agent gets exactly four MCP tools. None of them can return a secret value.

• list_services — the agent’s source of truth. It returns the services you set up that this agent is allowed to use: their names, their hosts, and whether they’re ready (filled). It never returns a value. The agent reads this list to discover what it can reach.
• create_service — when the agent needs a service you haven’t set up, it can register the non-secret config for it (a base URL and an auth scheme). It cannot supply the secret — you open the Veil app and fill that in. The agent proposes; you provision.
• call_api — the workhorse. The agent names a service, a request path (not a full URL), a method and optional body. Veil attaches or signs the credential server-side and returns only the upstream response. See below.
• query_db — run a single read-only SQL statement against a database service. PII is masked and destructive statements are refused before anything reaches the agent. See the database proxy.

Connect an agent

Mint an agent token in the Veil app (it starts with veil_agent_), then add the broker to your agent over HTTP MCP:

That’s the whole setup. The agent now sees list_services, create_service, call_api, and query_db, and starts working against the services you’ve granted it.

How call_api keeps the value invisible

When the agent calls an API, it supplies the intent of the request — never the credential. Veil resolves the service, injects the right auth, makes the call, and hands back only the response.

Several auth schemes are supported, and the agent never touches any of them:

• Static header — Bearer, x-api-key, or a custom header. Veil attaches it to every request.
• AWS SigV4 — set the service and region; Veil signs every request with your AWS credentials.
• OAuth2 — you store the client ID, client secret, and refresh token; Veil auto-refreshes the access token and attaches it. The agent never sees a token, fresh or stale.
• Database — a Postgres connection routed through the read-only database proxy.

Scoping what an agent can reach

Two independent controls keep an agent’s blast radius small:

• Per-token scope restricts which tools and which HTTP methods a token may use. A read-only reporting agent can get a token that only allows call_api with GET and query_db — it can look, but it can’t mutate.
• Per-credential policy governs each individual secret: allow, require_approval (an admin must approve each use), or deny. See policies & approvals.

And because a token is scoped to one or more workspaces with explicit permissions, the cleanest setup is to give an agent use on a single workspace — the narrowest reach that still lets it work.

Next: wire up the database proxy, set policies & approvals, or read the token reference.