Loading

API Keys

Inbound callers authenticate with an API key. A key belongs to an identity, and inherits that identity's permissions.

Where to find it

Architect Panel → Integration & Connections:

  • API Server — where keys are created and managed
  • Agent Access (A2A) — agent access, which a key can be permitted to use
  • AI Tool Access (MCP) — AI tool access, likewise

Architect Panel → Security:

  • Permissions — the groups a key’s identity belongs to

What a key carries

  • The identity it acts as, in the platform's usual three parts.
  • A name, so you can tell your keys apart.
  • Enabled, and an expiry date.
  • Last used.
  • Three capability flags: MCP, A2A and BI.

The key is not the permission

A key does not carry access of its own — it carries an identity, and that identity's group memberships decide what it can reach. Widening a key means changing the groups behind it, which is the same review as widening a person.

That is a good property: there is one permission model, not a separate one for machines.

The three capability flags

These are separate from permissions and gate whole subsystems rather than data:

  • MCP — the key may be used for AI tool access.
  • A2A — the key may be used for agent access.
  • BI — the key may reach business intelligence.

They ship off. A key intended for an ordinary integration should not carry them, because they open routes that integration has no use for.

Name keys after what uses them

"Partner X order feed" rather than "key 3". Names are what make revocation possible: when you need to disable a key in a hurry, you need to know which one, and the alternative is disabling several and finding out what breaks.

Always set an expiry

A key with no expiry outlives the integration, the supplier relationship and often the person who created it. An expiry forces a review — and an integration whose key is about to lapse is one somebody has to confirm is still wanted.

Annual is a reasonable default. Diary the renewal so it does not lapse mid-trade.

Last used is your cleanup tool

A key unused for months is usually a decommissioned integration nobody told you about. Review the list periodically and disable what is idle — quietly, since a genuinely live caller will complain within a day and can be re-enabled.

Treat a key as a credential

It is equivalent to a password for the identity behind it. It should not travel by e-mail, live in a repository, or be shared between integrations — sharing destroys the whole benefit of per-integration keys, which is that the log tells you who did what.

Rotating

Create a new key, move the caller to it, confirm traffic on the new key in the log, then disable the old one. Deleting first produces an outage; running two briefly does not.

Worked example

An organisation runs eleven keys, each named for its integration and expiring annually on staggered dates. A review finds two unused for six months — both decommissioned projects — and disables them. When a partner reports a failure, the log identifies their key immediately because no two integrations share one.

Recommendations

  • One key per integration, named after it.
  • Always set an expiry, and diary the renewal.
  • Leave the capability flags off unless the key needs them.
  • Rotate by overlapping, never by deleting first.