Service credentials

A service credential is an OAuth2 client_credentials client that your organization owns. A headless client — an n8n workflow, a CI job, a server-side script — exchanges its client ID and secret for a short-lived access token and calls the gateway with that token. No browser, no interactive login, no static API key.

Reach for one when the client cannot complete an interactive OAuth login — it runs on a server with no browser — but can perform the token exchange itself: n8n's OAuth2 credential, most server SDKs, a CI script with a few lines of shell. If your client can launch a local command instead, the mcp-remote bridge is simpler — see Clients without OAuth.

Who can create one

• Creating and rotating require an organization admin on Premium, Team or Company.
• Listing and revoking stay available to an org admin on any plan. That is deliberate: an organization that downgrades must still be able to kill a credential that is live.
• The credential belongs to the organization, not to the admin who created it — any of the organization's admins can see it and revoke it, and can rotate it while the organization is on one of those plans.
• On Team and Company, the first five credentials come with the workspace and take no seat; each further credential takes a seat of its own, so you buy seats to run more agents. On Premium, every credential takes a seat of its own, counted together with people: your own sign-in holds one, so a single-seat organization adds a second before it can mint a credential. The account page shows how many seats are used and how many of the included credentials are in use. Seats and roles are covered in Manage your organization.

Create one

1. Open your account area → Service credentials and choose Create credential.
2. Name it after the system that will use it — n8n production, nightly CI. The name is how you will know what breaks when you revoke it.
3. Copy the client ID and the client secret into the secret store that client already uses.

Connect with it

Exchange the credential for an access token at auth.ansvar.eu, then send that token to the gateway as a bearer token:

# 1. Exchange the credential for an access token
TOKEN=$(curl -s -X POST https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token \
  -d grant_type=client_credentials \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET | jq -r .access_token)

# 2. Call the MCP endpoint with that token
curl -s -X POST https://gateway.ansvar.eu/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Access tokens last 15 minutes. The credential itself is long-lived, so the client should exchange the secret for a fresh token whenever the current one is close to expiry, and never write an access token to disk or into a saved configuration. Clients that speak OAuth2 client credentials natively — n8n's HTTP Request credential, most server SDKs — handle that refresh once you give them the token URL, the client ID and the secret.

Connect an agent to it

The steps above get you a token and prove the connection. What consumes that token is your own agent — the gateway is a tool source, not a model, so something on your side has to run the model and its tool loop. Two shapes, depending on how much you want to own.

Let your model provider connect for you

If you build on the Anthropic API, its MCP connector takes a remote server URL and a bearer token and runs the tool calls for you — you never write a tool loop. Pass the access token from step 1 as authorization_token:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 4096,
    "mcp_servers": [{
      "type": "url",
      "url": "https://gateway.ansvar.eu/mcp",
      "name": "ansvar",
      "authorization_token": "'"$TOKEN"'"
    }],
    "tools": [{"type": "mcp_toolset", "mcp_server_name": "ansvar"}],
    "messages": [{"role": "user",
      "content": "Using Ansvar: search EU law for the NIS2 incident reporting deadline. Cite the article."}]
  }'

The response carries mcp_tool_use and mcp_tool_result blocks alongside the text, so you can see which corpora answered and check the citations.

Or run the loop yourself

Any model can use the gateway if you drive the loop: call tools/list as above, hand those schemas to your model as its tool definitions, and when it asks for a tool, call tools/call and feed the result back. This is what an n8n workflow or a CI script is doing under the hood, and it is the route to take when your provider has no MCP support of its own.

What it can and cannot do

A service credential gets the same tool surface as a signed-in seat on your plan: search across the corpora, provision lookup, citation validation, workflow runs, document upload and report generation. It passes the same tier gates as any other seat.

Where its budget comes from follows your plan. On Team and Company, seats pool: the credential draws on the organization's shared daily and monthly allowance alongside your people. On Premium, each seat carries its own allowance, so a credential spends its own and never your people's.

• Run ceiling — each credential carries a monthly workflow-run ceiling of its own, on top of whichever allowance above applies. The default is half of what one Team seat contributes to a pool, so on Team one runaway agent cannot drain what the rest of the organization shares, and on Premium it stops a loop well before the plan's own overage band ends.
• Stays with signed-in humans — audit-ledger decryption, and assent on architecture proposals (a credential can propose changes; a person approves them). The gateway enforces this on both sides of the call: those tools are hidden from tools/list and refused at tools/call even if the client asks for one by name.

Standard seats

A credential can hold a seat of a licensed ISO standard, and that is how you build an agent that reads the standard rather than paraphrasing it from memory. Your organization buys seats of a standard; an admin then assigns each seat, under Standards & documents in the account area, to a person or to a credential.

The recipe for an ISO-expert agent is two things: a service credential, and a standard seat assigned to it. Each has its own floor. A standard seat does not require an organization seat — a person can hold a standard on any plan. A credential requires Premium, Team or Company. And assigning a standard seat to a credential requires Team or Company: that assignment is an organization-management action, which Premium does not include. So a Premium organization cannot make that assignment itself — an assignment made while on Team survives a later move to Premium. Write to [email protected] if you need an ISO-expert agent on Premium.

Seats are per holder, not per organization: assigning a standard to one credential does not give it to the others. Releasing a seat returns it to the pool to assign again, and revoking a credential releases any seat it held. Volume discounts on seats are available on request — the pricing page has the contact route.

Rotate and revoke

Rotate issues a new secret and keeps the same client ID. The old secret stops working immediately, so update the client in the same change window. Rotate on a schedule you set, and straight away if a secret may have been exposed.

Revoke refuses new tokens immediately and frees the seat. Access tokens already issued keep working until they expire — up to 15 minutes. Plan for that window: revocation is not a kill switch for a request already in flight.

A row marked needs attention means the credential does not work — the client behind it cannot get a token. Revoke it and create a new one; there is nothing to repair in place.

Troubleshooting

• 401 right after a rotation — the client is still sending the old secret. The old one dies the moment the new one is issued; there is no overlap period.
• 401 on a token that worked minutes ago — the access token expired. Exchange the secret for a fresh one instead of storing the token.
• 404 at the endpoint — the MCP endpoint is https://gateway.ansvar.eu/mcp, not the bare host.
• Create refused, "all your seats are in use" — a credential past the included five on Team and Company, or any credential on Premium, takes a seat like a member does. Raise the seat count under Manage subscription, or revoke a credential you no longer need.
• Create or rotate refused on your plan — minting starts at Premium. Listing and revoking still work, so an existing credential can always be shut off.
• A tool you expected is missing from tools/list — a credential sees the tool surface of its plan's tier, so check the tier gate for that tool first. The two admin-side surfaces (audit-ledger decryption, assent on architecture proposals) are hidden from credentials by design; run those from a signed-in seat.