A scope authorises a read and says nothing about volume. An agent reads a
thousand records in seconds where a person clicks ten, and until now nothing
noticed: the token is valid, the tool is permitted, the ACL passes. That gap
stopped being theoretical the day an autonomous run started reading the whole
catalog on a schedule.
identifier: credential keys the counter on the sub claim — the end user,
whoever is asking on their behalf — so an agent looping under one person's
identity spends that person's budget and cannot spend everyone's. Verified on
catalog: pm-user and ro-user hold separate counters.
Per-route namespace, so a busy domain cannot exhaust another's.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
list-payments/get-payment (all 5 roles) and create-payment (admin
only — matches PaymentPermission's actual write-access logic, not
guessed). One KongRoute for GET/POST/DELETE, one ai-mcp-proxy
binding — avoids the duplicate-tool-name bug found and fixed on
customers-mcp (STATUS.md section 18), built correctly here instead
of repeating the two-route mistake.
Keycloak (local): mcp-payments-audience client scope + mcp-payments
resource client, attached to librechat as an optional scope, no
dedicated protocol mappers on the client itself.
6 routes over Payment, composite key (customernumber + checknumber),
proxying to classic-models-api. openid-connect with RFC 8693 token
exchange to classic-models-api audience, rate-limiting, proxy-cache,
audit-log — same structure as customers-api's REST layer.
Keycloak (local): payments-api-audience client scope + payments-api
resource client added, attached to kong-token-exchange-broker's
default scopes. No dedicated protocol mappers on payments-api
itself, same practice as customers-api/mcp-customers.
No MCP layer — same as customers-api, not needed yet.
Stéphane Tailland