Chapter 2 of 6
Architecture at a glance#
The candidate agent gets a token for the MCP audience. APIM validates its tenant, client application, audience, and app role, then exposes only get_policy. APIM gets a second token for its system-assigned identity. The backend accepts that identity at the exact approved read scope.
The backend validates policyId. APIM records the tool, status, latency, W3C operation_Id, and client X-Correlation-ID. It records no arguments, results, prompts, responses, tokens, or bodies.
Design choices and tradeoffs#
| Decision | Chosen approach | Cost or limit |
|---|---|---|
| Tool surface | One get_policy tool | Another action needs review and deployment |
| Backend access | APIM managed identity with the exact read role and scope | Two audiences and role assignments need ownership |
| Release | Test an unpinned candidate | Enablement waits for both checks |
| Telemetry | Correlation and tool metadata; zero body bytes | Content investigations stay in governed source systems |