docs: stop naming the middleware

An agent talks to URLs that honour a contract: an MCP endpoint, an OIDC token
endpoint, an OpenAI-shaped LLM endpoint. Whatever serves those URLs is
replaceable, and naming it in an agent's code or docs implies a coupling that
does not exist.

Every product name is gone from prose, comments and identifiers, replaced by
what the agent actually depends on. Where a behaviour of the current middleware
leaks into the contract — the second audience scope, the tool ACL — the text
now says what the caller must do and why, not who imposes it.

One string survives and cannot be fixed here: the broker client an agent must
name in its audience scopes is itself named after the middleware. Closing that
means renaming it in Keycloak and following the rename through the gateway
configuration and LibreChat. Recorded as a blocker.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Stéphane Tailland
2026-08-29 07:35:15 +02:00
parent 31020e25dc
commit 601bd6343e
8 changed files with 47 additions and 41 deletions
+9 -9
View File
@@ -3,8 +3,8 @@
Product management agent for the Classic Models catalog domain. Serves a product
manager: what exists, how it is priced, whether it sells, what to discontinue.
Reached over **A2A**; reads data over **MCP** through the Kong gateways; thinks
through the **Kong AI gateway**. It is one MCP client among others, exactly as
Reached over **A2A**; reads data over **MCP** from the domain servers; thinks
through the estate's **LLM endpoint**. It is one MCP client among others, as
LibreChat is — nothing under it changes to accommodate it.
## Running it
@@ -40,7 +40,7 @@ is fine.
```
A2A SendMessage ──► exchange the user's token, once per audience
──► build one MCP toolset per server, with that turn's tokens
──► PydanticAI runs the model through the Kong AI gateway
──► PydanticAI runs the model through the LLM endpoint
──► answer, toolsets dropped
```
@@ -50,8 +50,8 @@ holding one long-lived connection would mean one long-lived token.
Several narrow tokens rather than one broad one: a token minted for
`mcp-catalog` is refused by the sales gateway, so a prompt injection that talks
the agent into reaching the wrong domain fails at Kong rather than succeeding
quietly.
the agent into reaching the wrong domain is refused at the endpoint rather than
succeeding quietly.
## What it can and cannot do
@@ -62,10 +62,10 @@ quietly.
| Calls | nothing yet. `Approvisionnement.check_availability` comes with discontinuation decisions |
| Exposes | `describe_catalog` |
Who may write is decided by Kong, not by this agent. `ai-mcp-proxy` carries a
per-tool ACL — `create-product` allows the `admin` and `product_manager`
consumer groups — and the group comes from `realm_access.roles` in the end
user's own token. The filtering happens at **discovery**, not just at call time:
Who may write is decided by the MCP server, not by this agent. It authorises
each tool against the roles in the end user's own token — `create-product`
needs `admin` or `product_manager` — and it does so at **discovery**, not only
at call time:
```
pm-user catalog ['create-product', 'get-product', 'list-products']