Agents are starting to do real work inside access workflows. They request access, approve it, and pull the evidence for a review. Before any of that, the agent has to connect to Opal, and that connection is itself an access decision. It deserves the same governance as any other grant.

Until now, connecting a client meant creating an API token and pasting it into your config as a bearer header. The token is personal and it works, but it is a long-lived secret:

• It sits in the config until someone rotates or revokes it

• Every person has to mint and store their own

• The moment one gets shared to save time, it stops being personal

You sign in, Opal issues a short-lived token

Opal’s MCP servers now support OAuth. Instead of creating and pasting a token, each person signs in through their browser. Here is what happens:

• Opal issues a short-lived token scoped to your account

• The client refreshes it automatically, so nothing long-lived sits in a config

• The flow uses OAuth 2.1 authorization code with PKCE, and most clients run it end to end: add the server URL, sign in, approve, done

• It covers all three servers: End User, Admin Provisioning, and Admin Audit

• You can review or revoke your own grants under User > Settings > OAuth Grants

Every agent acts as the person who signed in

This is what lets you give MCP to everyone who should have it, not just the few willing to manage a token.

Every action an agent takes runs as the person who signed in. It is scoped to what that person is allowed to do, routed through the same approvals, and written to the same audit trail as any other request:

• An employee asking their assistant to request access

• An admin adding a grant

• A reviewer pulling evidence

Each one acts as themselves, on their own permissions, on the record. There is no shared secret standing in for a person and no long-lived token to leave behind.

Available now, in beta

OAuth support is in beta. As an alternative, you can use an API token, e.g. for scripts and other non-interactive clients.

Add a server and sign in

1. Add the server you want, without an Authorization header

2. Run your client’s sign-in step

For Claude Code, that is:

claude mcp add --transport

claude mcp add --transport

claude mcp add --transport

Per-client commands and manual configuration values are in the docs.