Design review
The Microsoft design review, and what it changed
On 11 October 2026 we asked a Microsoft identity specialist whether our use of Entra Agent ID, managed identities, Key Vault, Container Apps and Copilot Studio is correct, supported and safe. This page records the outcomes we asked them to test, what came back, and our position on each point.
Seven outcomes, each with a status
The goal is for each Copilot Studio agent to take part in the OpenID Federation as a named entity the federation can resolve and trust. Demonstrated means shown end to end in the August deployment. Partial means demonstrated with a stated gap. Proposed means not yet in place.
| # | Outcome | Status | What it requires of Microsoft |
|---|---|---|---|
| O1 | One federation entity per Copilot Studio agent. Each agent has its own entity id, which is also its OAuth client_id, and the delegated token names it in act.sub. | Demonstrated one agent | A distinct Entra agent identity (the mirror) per agent, under our blueprint, with a stable app id we can map to the entity. |
| O2 | Each call carries Microsoft-issued evidence for the agent's mirror. The attestation service verifies it before it signs. | Partial identifies the mirror and the connection holder, not a run | The Federated Identity Credential chain must issue v2 tokens carrying the agent identity claims, audienced to our Bridge API. |
| O3 | The right agent maps to the right entity. The caller is identified per agent before a mirror token is used. | Demonstrated by shared secret | Each agent's connection must carry its own agent id and a per-agent secret. No Microsoft-verifiable agent identifier reaches us. |
| O4 | The customer is delegated, not impersonated. The customer's own Entra token is the subject of the token exchange. | Partial subject validation incomplete | Copilot Studio must deliver an unexpired, v2, correctly audienced user access token on each call. |
| O5 | No long-lived secrets for Azure service authentication. | Partial two secrets remain | Managed identities and federated identity credentials for service-to-service calls. Signing keys in Key Vault with access scoped per key. |
| O6 | Signing authority is split across services. | Partial see the compromise model | Three Container Apps with separate managed identities, and a signing service that accepts calls only from the bridge's identity. |
| O7 | Onboarding a new agent touches Entra, not PingFederate's key configuration. | Proposed automation not yet run end to end | Agent identities can be created programmatically under our blueprint and assigned an app role on the Bridge API. |
The reviewer's two headline points
The agent's identity depends on the per-agent connection secret, checked by an internet-facing gateway
Our position. This is the constraint the design starts from, not a finding against it. On the tested custom connector path, Copilot Studio gives the external API no verifiable agent identifier. The reviewer confirmed the limit still holds. What needs fixing is wording: the mirror token is an Entra-signed, revocable record that the gateway accepted this agent's connection secret. It is not independent Microsoft evidence about the agent.
A bank will expect network isolation, revocation, monitoring and infrastructure-as-code
Our position. Agreed. The review listed these as gaps without a plan. The network design is the first of those plans. Revocation, monitoring and the infrastructure-as-code baseline follow.
One point changes the design and not only the wording: one sign-in app per Copilot Studio agent. The customer token's azp would then name the agent's sign-in app. That gives a Microsoft-signed link between customer and agent whenever a customer is signed in, though still not proof of which run made the call. We adopt it, with a PingFederate check that azp matches the agent's entity.
Point by point
| Area | Reviewer says | Our position and the change |
|---|---|---|
| Agent ID token to external APIs | No supported way today for a custom connector, MCP tool or REST tool to carry the agent's own Agent ID token. | Confirmed against Microsoft Learn. Recorded as not supported. Spike planned: a Copilot Studio skill endpoint receiving an agent-associated token. |
| Per-run identity | Agent ID has no per-run identity, and Microsoft advises against creating directory identities per session. | Agree. Carry the Copilot Studio conversation id in the attestation's upstream context, labelled self-asserted. |
| Sign-in app per agent | One secretless sign-in app per agent removes the credential cap and makes the customer token's azp identify the agent. | Agree, and adopt. The customer token is still a bearer token, and PingFederate must check azp against the agent's entity. |
| Federated credential subject | Microsoft does not document the subject format. Treat it as per-environment configuration. | Agree. Re-read the subject after environment moves and agent re-creation. |
| Blueprint privilege | The blueprint principal can create agent identities, so protect the blueprint, the gateway identity and the gateway app at the highest tier and alert on changes. | Agree, with two corrections. A new identity gets no attestation without a registry change and a redeploy. Alerts detect misuse, so the preventive control is restricting who can assign the gateway's identity or deploy the gateway. |
| Connection ownership | The maker who creates the connection knows the key, and a shared connection can be reused. Have a service account own each connection, ship the connector in a managed solution, and get a written commitment that maker credentials stay enabled. | Agree with all of it. The third item is a dependency on a tenant setting we do not control. |
| Public gateway | Anyone with an agent key and a customer token can call a public gateway directly. Make Power Platform VNet support mandatory. | Agree, and Microsoft's documentation supports it. See the network design. |
| User token refresh | Refresh behaviour of System.User.AccessToken is undocumented. Add offline_access, test a conversation idle for 65 to 95 minutes, and remove the Authorization fallback. | Agree. The fallback removal is a gateway code change. The idle test goes into the test plan. |
| Step-up timing | Agent flows must respond within 100 seconds, so a poll loop cannot fit in one run. Use a turn-based step-up and add idempotency keys. | Agree. This corrects the review. The step-up section is rewritten for a turn-based resume, and payment submission gets an idempotency key. |
| Data loss prevention | Blocking a custom connector by name elsewhere does not confine it. Use a tenant-level policy with a host URL rule and block HTTP connectors pointed at the gateway host. | Agree. DLP does not replace network isolation. |
| Stale connections | With one shared connector, a single change can break every agent at once. Freeze its authentication settings and publish changes as a new version. | Agree. Add connector versioning and automated test conversations per agent to the monitoring plan. |
| Key Vault roles | A custom role with only key read and sign. | Confirmed. Moved from proposed to the plan. |
| Key generation | Generate keys inside the vault as non-exportable EC-HSM keys in a Premium vault. | Agree. Onboarding changes so keys are created in the vault and the repository step is removed. |
| Signing budget | Vault limits allow roughly 50 to 100 calls per second, fine for a pilot. Pre-sign the federation statements, cache public keys, and give each signing service its own vault. | Change required. Either pre-sign the leaf and subordinate statements, or have the attestation service verify the mirror token before the bridge signs anything. |
| Container Apps network | Internal ingress is reachable from every app in the environment. Recreate the environment with VNet integration, private endpoints, an egress allow-list and a separate environment for the signing service. | Agree. Folded into the network design and the infrastructure-as-code baseline. |
| Rate limiting | Only the rightmost X-Forwarded-For value comes from the platform. Key the limiter on it and share its state across replicas. | Change required in the gateway. |
| Regulatory | Have the bank's risk team map the design to APRA CPS 234 and CPS 230. | Agree. The bank owns that mapping. We supply the control inputs: key custody, separation of signing authority, revocation, monitoring and dependence on Microsoft-managed components. |
The channel decides whether the design can obtain a customer token
The design needs manual authentication in Copilot Studio, because System.User.AccessToken is available only under "Authenticate manually".
| Channel | Customer token available | Status |
|---|---|---|
| Web and custom sites | Yes | Tested |
| Teams 1:1 chat with manual single sign-on | Documented by Microsoft | Untested |
| Teams one-click and Microsoft 365 Copilot | No. These expect "Authenticate with Microsoft". | Not possible |
Admin controls the design depends on
The Power Platform control "Authentication for agents" can be set per environment to require Microsoft authentication, which removes manual authentication. A published agent whose setting is no longer allowed stops responding to users. The bank must keep that environment at "Require Entra authentication" or "Allow all supported authentication methods", and keep maker-provided credentials permitted.
The changes, in order
Design review wording
Describe the mirror token as a record of the gateway's decision. Name the connection secret as the agent credential. Correct the DLP statement and the step-up timing.
One sign-in app per agent
The one design change, with the PingFederate azp check. It addresses the missing binding between customer and agent.
Code fixes
Rate limiter source address. Remove the Authorization fallback and add offline_access. Verify before signing, or pre-sign. Idempotency key on payment submission.
New plans
The network isolation target, a revocation and monitoring plan, and an infrastructure-as-code baseline in three layers: Azure resources, app registrations, agent identities.
Tenant checks
Key Vault key type, exportable flag and audit events, to confirm no signing key was ever generated outside the vault.
Still waiting on Microsoft
Agent ID licensing, the dependency on beta Graph APIs for agent identities, and documentation links for the 100 second agent flow limit.
Sources
Checked 23 October 2026.