# Authentication

Choose workspace API keys or personal and workspace MCP connections.

API keys are currently available to selected workspaces. [Contact Brigg](mailto:axel@brigg.no) to enable access.

## Workspace API keys

Send your secret key in the `Authorization: Bearer …` header on every HTTP request. Keys are named workspace credentials with explicit grants. Their creator is recorded for audit; the integration's access does not depend on the creator remaining a member.

Owners and administrators create, revoke, and replace workspace keys in [API keys in Brigg Settings](https://brigg.app/settings/developer). Revocation prevents subsequent requests. When replacing a key, deploy the replacement credential to your integration before revoking the old one.

Store keys on a server or in a trusted agent client's secret store. Secret workspace keys must not be embedded in websites, mobile bundles, URLs, logs, or documentation.

## Member delegation

An administrator can allow a workspace key or shared MCP connection to act for **selected members** or **all current and future members**. The default is **Workspace only**. Existing credentials keep that default.

For an HTTP call, select the member with `Brigg-Act-As`:

```sh
curl 'https://api.brigg.app/v1/operations/documents.ListDocuments' \
  -H "Authorization: Bearer $BRIGG_API_KEY" \
  -H "Brigg-Act-As: $BRIGG_ACT_AS" \
  -H 'Content-Type: application/json' \
  --data '{"scope":"user"}'
```

List the active members your credential may use:

```sh
curl 'https://api.brigg.app/v1/delegation/members' \
  -H "Authorization: Bearer $BRIGG_API_KEY"
```

The response is `{ "items": [{ "id": "account_example", "name": "Alex Taylor" }] }`. Use the returned `id`, not an email address. Only members authorized by the stored delegation grant are returned.

With the [server helper](https://developer.brigg.app/files), create a client for each identity:

```typescript
const brigg = createBriggClient({
  apiKey: process.env.BRIGG_API_KEY!,
  actAs: process.env.BRIGG_ACT_AS!,
});
```

The request must satisfy **both** the key's approved operations and resources **and** the member's current permissions. This includes their private data. Disabled members and members outside the credential's workspace cannot be selected. Omitting the header uses workspace access, even on a key with delegation enabled.

Use the same member and idempotency key when retrying. Receipts and open uploads are isolated by credential and member. Audits record the credential and effective member. Changing a member's permissions or revoking the credential affects subsequent requests and background callbacks. Rate limits remain shared by credential and workspace; changing members does not reset them.

## Agents using MCP

MCP clients use OAuth rather than API keys. Choose personal access for an agent
acting with your own permissions, or workspace access for a shared integration.
See [connect an agent with MCP](https://developer.brigg.app/mcp) for setup, identity and revocation.

## Existing integrations

Existing MCP connections retain their personal identity, granted scopes, and launched tool contracts. Reconnecting is not required merely because the public operation catalog has expanded.

Existing conversion-tracking keys retain their conversion permissions. A previously issued key does not automatically gain the expanded operation API. Browser-safe publishable conversion keys remain limited to conversion tracking.