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:
@@ -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']
|
||||
|
||||
Reference in New Issue
Block a user