Authentication

Wire supports two authentication methods for accessing containers. These work the same way for both MCP and REST API requests:

• OAuth 2.1: recommended for individual users and agents running on your computer
• API Keys: recommended for headless agents and server-side automation

Using OAuth

Most MCP clients handle OAuth automatically. When you first connect, your browser will open to:

1. Sign in to Wire (if not already authenticated)
2. Review the requested permissions
3. Approve access

If a client doesn’t send a resource indicator, the approval screen asks you to pick an organization and the containers the client can use.

After approval, the client stores your credentials and you won’t need to sign in again until the token expires.

Using API Keys

Pass an API key to Wire via either header:

x-api-key: wire_live_...

or

Authorization: Bearer wire_live_...

Both MCP and REST transports accept either form. Wire supports two kinds of keys, and you should prefer the scoped variant whenever possible.

Container-scoped keys (recommended)

A container-scoped key only works for a single container. If the key is ever leaked, only that one container is exposed. We recommend creating a separate scoped key for every agent, integration, or automation you connect. This gives you granular, revocable access without sharing credentials across surfaces.

Creating a container-scoped key:

1. Open the container in the Wire dashboard
2. Click the ⋯ menu in the container header and choose Access
3. Click Create API Key
4. Name the key after the agent or integration that will use it (for example, “Cursor workspace” or “Linear backfill script”)
5. Optionally set an expiration
6. Under Tools, keep All tools or choose Specific tools (see Limiting a key to specific tools)
7. Copy the key immediately, since this is the only time the full key is shown

Every attempt to use a scoped key against a different container returns 403 Forbidden on both MCP and REST transports:

{
  "error": "forbidden",
  "message": "API key is scoped to a different container"
}

This is enforced at the container worker regardless of the key owner’s broader organization role.

Limiting a key to specific tools

A container-scoped key can be limited to a list of tools. The agent using it sees only those tools in tools/list and can call only those, over MCP and REST alike. The list can include the container’s custom tools, so a common setup is a key that can call log_decision and find_decisions and nothing else.

A new key can call every tool your own access to the container allows. To limit one, choose Specific tools when you create it, or choose Edit Tools from an existing key’s dropdown menu on the container’s Access page. Editing a key’s tools does not change the key itself, so nothing needs to be redeployed.

A key’s list can only narrow what you can do. The key reaches a tool only when the tool is on its list and your own access to the container includes it, so a key never reaches past your permissions, and it narrows further if your access later does. Wire refuses a list that names a tool the container does not have, or a tool outside your access, and a key must allow at least one tool. To stop a key working, disable or delete it instead.

The list and a tool’s visibility are separate controls. A tool that is turned off on the container stays unavailable to every key, including keys that list it.

When a change takes effect. Agents pick up an edited list within about 30 seconds. In rare cases it takes up to 90 seconds.

Every change to a key’s tools is recorded in the container’s activity, with the lists before and after.

Rotating a key keeps its tool list.

Account API keys

An account key grants access to every container in your organization. Reserve these for trusted automation that legitimately needs to operate across multiple containers, for example a one-off migration script or a backfill tool. For anything long-lived or shared with an external system, use a container-scoped key instead.

Creating an account API key:

1. Open the user menu in the Wire dashboard and choose API Keys
2. Click Create API Key
3. Name the key, optionally set an expiration
4. Copy the key immediately, since this is the only time the full key is shown

Rotating a key

Both account and container-scoped keys can be rotated in place from the same dropdown menu. Rotation creates a new key with the same name, scope, and tool list, then revokes the old key. The new key is shown once, so copy it and update wherever the old key is in use.

Rotate a key when:

• You suspect it may have been exposed or committed to version control
• Someone with access to the key (an employee, contractor, or shared device) no longer needs it
• You’re doing a periodic security review

Disabling or deleting a key

From the key’s dropdown menu, choose Disable Key to temporarily block requests without losing the record, or Delete Key to permanently revoke access. Either action takes effect immediately for any client using the key.

Key metadata

Each key stores a small amount of metadata you’ll see in the dashboard:

• Source badge: shows whether a key was created from the dashboard or by a plugin connect flow (for example, the wire-memory plugin)
• Tools: All tools, or the tools the key is limited to
• Last used: the timestamp of the most recent authenticated request
• Expiration: when the key will stop working automatically, if set

---

OAuth Technical Details

This section is for developers building MCP clients.

Wire’s OAuth implementation conforms to OAuth 2.1 and the MCP Authorization specification. Key requirements:

• PKCE is mandatory (no client secrets)
• Uses authorization code flow only
• Follows RFC 8707 for resource indicators

Discovery

Fetch the OAuth configuration:

GET https://YOUR_ORG_SLUG.mcp.usewire.io/.well-known/oauth-authorization-server

Authorization Request

GET /oauth/authorize?
  response_type=code&
  client_id=mcp-client&
  redirect_uri=...&
  scope=containers:read&
  code_challenge=...&
  code_challenge_method=S256

Token Exchange

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=...&
redirect_uri=...&
code_verifier=...

Security

• PKCE required - All OAuth flows must use Proof Key for Code Exchange (S256)
• JWT tokens - Access tokens are signed with EdDSA and contain user ID, email, name, session ID, and an audience claim scoped to the container
• Token lifetime - Access tokens expire after 7 days; refresh tokens last 90 days