DEV Community: Anton Staykov

The AI agent kill switch is a procedure, not a feature

Anton Staykov — Thu, 15 Oct 2026 10:53:00 +0000

An invoice-processing agent starts submitting the same job repeatedly. You disable its principal. Even if Microsoft Graph now rejects its requests, the agent may still use a provider key, write export files or leave accepted jobs running.

Which effects did the kill switch actually stop? The credential operation may have succeeded without containing the workload.

An AI agent kill switch is an operational procedure with a testable outcome.

The hypothetical invoice agent has four action paths: Graph access, model access, local writes and submitted jobs. Following those paths exposes the architectural obligation: someone outside the agent must retain the authority and information needed to stop its consequential activity.

The stop objective determines the control

"Stop" needs a defined outcome. Containment denies specified consequential actions; quiescence additionally requires relevant execution and outstanding work to reach verified terminal states. A paused or queued job is not terminal, and completed work may still have produced effects requiring recovery.

The invoice incident requires both: no further submissions or export writes, no remaining agent execution and no unresolved processing jobs. A lower-risk incident might permit isolated computation to continue while denying every forbidden effect.

Three artifacts make that objective reviewable. The stop scope identifies effects, execution units and permitted collateral impact. The shutdown protocol assigns independent authority, dependencies and failure handling. The acceptance report records observed coverage, timing and persistence.

Build the scope from credentials, reachable destinations, writable resources and submitted work. "All registered paths are closed" is a bounded claim; "the agent cannot cause harm" is not. Every new tool integration should identify both the authority it adds and how that authority will be withdrawn.

For the invoice agent, ending model access is not the business objective; preventing further duplicate submissions and export changes is. If queued work needs no further model call, model denial does not end that exposure. Prioritize interventions by the effects that remain possible, not by which administrative action is easiest. Otherwise a convenient control operation quietly becomes the organization's definition of successful containment.

Token revocation changes authorization, not execution

"Revoke the token" can mean stopping issuance, invalidating a refresh token or access token, or making a resource reject an existing token. RFC 7009 requires refresh-token revocation support, recommends access-token revocation support and acknowledges propagation delay. These are not interchangeable guarantees.

A successful revocation response does not prove resource-side rejection. Self-contained tokens can be validated locally; an issuer-side change therefore needs additional resource interaction for immediate enforcement. Waiting for expiry is a different shutdown assumption.

Token introspection lets a protected resource ask whether a token is active:

{
  "active": false
}

That response carries authorization information, not a termination instruction. Cached active responses can preserve a revoked token's usability. Your design must identify participating resources and refresh behavior, not merely name the introspection protocol.

Microsoft Entra continuous access evaluation (CAE) improves enforcement for eligible single-tenant service principals calling Microsoft Graph, with clients declaring cp1 and handling claims challenges. Managed identities and third-party or multitenant applications are excluded from that workload CAE scope. For Microsoft Entra Agent ID, verify eligibility rather than assuming ordinary service-principal behavior applies.

Assume the invoice agent's participating Graph path is now denied. Model access, local writes and accepted jobs remain. Revocation could suffice where every forbidden effect depends on a current participating-resource decision and no relevant work is already admitted. This architecture does not meet those conditions.

Request boundaries must leave no accepted bypass

A gateway lets an operator withdraw access without the caller's cooperation. Separating caller and backend authentication also permits targeting one caller without necessarily withdrawing everyone's backend access.

That advantage requires mandatory routes. The topology below separates model and tool requests from local execution, because closing one does not establish the state of the others:

flowchart LR
    A["Agent runtime"] --> G["Model gateway"]
    G --> M["Model"]
    A --> T["Tool boundary"]
    T --> S["Downstream systems"]
    C["Shutdown control"] -. Deny .-> G
    C -. Deny .-> T
    C -. Quarantine .-> R["Host and network"]
    R -. Contains .-> A

Backend authorization and network restrictions must prevent bypass. Azure API Management's return-response policy illustrates denial before backend forwarding in an inbound policy:

<return-response>
  <set-status code="403" reason="Forbidden" />
  <set-header name="Content-Type" exists-action="override">
    <value>application/json</value>
  </set-header>
  <set-body>{"error":"agent_execution_disabled"}</set-body>
</return-response>

The fragment denies every caller reaching its policy scope. Targeting an agent instead requires validated caller claims, not a supplied agent-name header. Distinguish delegated user identity from client identity; shared principals require another trusted discriminator or an explicitly broader shutdown.

Shutdown granularity is therefore an architectural choice made before the incident. Sharing an identity may simplify operation while making isolation of one caller harder. And return-response governs the current pipeline, not jobs already admitted elsewhere.

Credential custody determines whether denial can be bypassed. If the agent retains a provider key and direct access, an alternative authentication path survives. Keep backend authority outside the runtime: API Management's own managed identity or Docker's supported host-side credential injection can mediate use without exposing that credential to the workload.

Credential custody also determines the incident's blast radius. If the backend credential remains under trusted control, denying the affected caller can preserve service for unrelated workloads. If that credential escaped, caller denial no longer covers its possible use elsewhere. The procedure must then address the credential itself, with any broader disruption explicitly accepted rather than hidden behind a claim of per-agent isolation.

Credential modernization is not bypass elimination: Azure AI's disableLocalAuth disables key-based authentication, while Anthropic's workload identity federation replaces static keys for the configured flow. Neither alone makes a gateway mandatory.

Managed identity likewise does not imply instant token revocation; it is outside workload CAE. For the example, assume accepted bypasses are now closed and model and tool routes deny the caller. Local execution, admitted jobs and replacement remain.

Local effects require host and network enforcement

Start with the forbidden effects, not the preferred sandbox. Network isolation can deny remote submissions while leaving local writes possible. Microsoft Execution Containers (MXC) can contain a tool or an entire agent; choose the unit at which an independent operator can control the relevant effect.

Isolation does not remove deliberately granted access. Docker's local sandboxes use lightweight virtual machines, or microVMs, with separate Linux kernels, yet writes through directly mounted workspaces affect host files immediately. The invoice agent's writable export directory is an authorized capability, not an isolation failure. Its withdrawal still needs a control.

Likewise, Docker's outbound policy proxy must cover the actual destinations and connection states. MXC's permissive mode records rather than blocks ungranted access; enforcement and learning modes block it. Count only deployed, enforcing interventions, not experimental or forthcoming capabilities.

Windows 365 for Agents offers managed Cloud PCs with session orchestration and intervention capabilities. To use that isolation platform in the procedure, identify the assigned session, independent operator, available intervention and collateral impact.

Suppose the export process has now stopped. Local writes and new registered requests have ended; jobs accepted by other systems have not necessarily ended with them.

Independent authority must keep the stop latched

If the supervisor replaces the terminated process, routine recovery defeats containment. The operator stopped an instance, not the logical agent. A durable administrative stop must govern admission, retries and replacement from the start of the incident until independent clearance.

The workload cannot authorize its own restart or remove its restrictions. An agent must not be its own security authority, and the controller needs authority and information that survive the target losing access.

Connect the logical agent to principals, runtime instances, boundaries and accepted jobs. Validated identity alone does not supply that inventory. Record external job identifiers, owning services and available interventions outside the submitting process so termination does not destroy the means to cancel its work.

Independent control does not require one all-powerful credential. Keep intervention privileges at the relevant boundaries, with named owners and a coordinated procedure. The requirement is that each intervention remains available after the target loses access. If stopping the agent also disables the only credential that can inspect or cancel its submitted jobs, the procedure has removed its own ability to finish.

Include uncertain submissions. If a service accepted a job but its response was lost, the missing identifier leaves an unresolved obligation. Reconcile the attempt with the owning service; until then, retain an explicit coverage gap.

If a downstream service offers no cancellation, independently verified completion may be the only route to quiescence. That waiting time belongs in the stop budget. If the organization cannot tolerate it, constrain what the agent can admit before delegating that capability. During the incident, an uncancellable job remains outstanding work; tracking its identifier does not turn it into a stopped job or remove the need to assess its effects.

The protocol follows those dependencies: prevent replacement, close paths, stop execution and reconcile admitted work. Some interventions can run in parallel, but the control planes do not constitute one atomic transaction. Gateway denial can succeed while execution or an external job remains active.

Record requested actions separately from observed outcomes. Name an escalation owner and any permitted broader intervention, including its collateral impact. A per-agent failure must not silently become a shared-service shutdown, nor a successful command become a claim that every path is closed.

Acceptance requires coverage, timing and persistence

A command response is not an acceptance test: RFC 7009 returns HTTP 200 even for an already-invalid token. Use controlled fixtures to verify effects across every in-scope path:

Acceptance test	Required observation	What failure means
Replay a pre-incident credential against the participating resource	Forbidden action rejected within the agreed interval	Resource enforcement cannot carry that path's guarantee
Submit through each denied gateway route	Requests denied before forwarding across serving instances	Route remains open or convergence is unverified
Attempt each registered direct-provider route	No accepted independent route for the affected workload	Credential custody or backend access permits a bypass
Continue a harmless local-write fixture and observe the runtime	Writes cease; execution also stops where quiescence is required	Local effects or required execution remain outside stop coverage
Reconcile accepted jobs against the trusted inventory	Every in-scope job cancelled or independently proven terminal	Admitted work remains active or its outcome is unknown
Exercise queued retries and replacement instances	No submission-capable replacement before clearance	Instance termination mistaken for a durable agent stop

The following YAML is an example operational contract, not product configuration. Its 15-, 30- and 60-second thresholds are illustrative targets to negotiate and test, not vendor latency guarantees:

agent: invoice-reviewer
scope: one-agent
clock_starts_at: incident_trigger_accepted
required_observations:
  model_tool_and_credential_paths_denied:
    within_seconds: 15
    evidence: independent_authenticated_probes_denied
  runtime_execution_stopped:
    within_seconds: 30
    evidence: supervisor_confirms_no_agent_execution
  known_downstream_jobs:
    within_seconds: 60
    evidence: every_job_cancelled_or_proven_terminal
restart:
  automatic: forbidden
  requires: independent_approval
failure:
  state: containment_incomplete
  action: escalate_and_keep_stop_latched

Choose the time budget from acceptable exposure, not a convenient vendor timeout. Fast denial on one route fails coverage; comprehensive but late denial fails timing. An unavailable enforcement point leaves an unverified path, not a latency to average away.

Test the intended denial, not merely a failed request. A controlled action should be known to work before the stop, and its rejection afterward should be attributable to the selected enforcement point. A timeout, malformed credential or unrelated outage cannot establish that the procedure withdrew authority. Capture the trigger, target, observed result and enforcement evidence without copying raw credentials into the report.

Test old credentials and cached authorization decisions, not only new tokens. Preserve running work, queued retries and replacement behavior in the fixtures. Verify the execution boundary independently of model access, and reconcile jobs against service-observed outcomes.

Suppose gateway denial is verified at eight seconds, runtime termination at 22 and the last job becomes terminal at 41. With all required paths covered, those illustrative observations support a 41-second stop, not an eight-second stop. A submission-capable replacement at 43 seconds invalidates it.

Record coverage, completion times, unresolved paths and the observation window. Distinguish cancellation from completion: a terminal job may already have submitted the duplicate, just as host-file writes may already have changed an export. Shutdown ends further activity; it does not certify earlier results.

Choose an observation window that exercises the deployment's relevant retry and replacement behavior. A snapshot showing no process at one instant is weaker evidence than a denied restart attempt under the latched stop. The report should say which behaviors were tested and which remain unverified. That preserves the boundary between a demonstrated operational result and an unlimited assurance about future execution.

Re-entry requires independent clearance

Restarting does not establish that the cause changed. Persistent sandbox state and queued work can reproduce the incident. An independent approver must authorize reused state and restored permissions after the cause is addressed.

Likewise, returning a Cloud PC to its pool is resource lifecycle, not incident clearance. Choose controls, including resource-enforced revocation, for the authority they remove rather than the length of the security checklist.

Delegating work creates an obligation to retain independent withdrawal and account for work already set in motion. For every action that survives the stop command, require an owner, an intervention and evidence of its result. A product name is not that answer.

References

To passkey or not to passkey? Microsoft Entra has changed the question

Anton Staykov — Wed, 07 Oct 2026 10:33:00 +0000

Scepticism about passkey onboarding is understandable. It is not a reason to evaluate today's synced-passkey support in Microsoft Entra through yesterday's Authenticator Passwordless sign-in setup. For an employee signing in on their own phone, the important change is how much of the registration journey can stay on that phone.

A customer needed one working phone, not a passwordless programme

The discussion started with a concrete customer situation: front-line workers needed access to a web-based application from their personal mobile devices, outside the corporate network. The company did not provide laptops, mobile phones or other authentication hardware. There were no terminals on the manufacturing floor, and deploying terminals was not the desired answer.

The company also did not want to distribute passwords. That matters because a recommendation built around sending every worker an initial password changes the requirement before the architecture discussion has even started. The desired outcome was a usable access journey on the device the worker already owned, not a new fleet-management project.

The existing authenticator passwordless sign-in onboarding was generating too many support requests. In the customer's discussion, approximately half the users were reportedly unable to complete the configuration. That is the reported experience of this population, not an industry-wide failure rate or a measured comparison with a completed passkey deployment.

One contributing factor was that workers were being asked to configure an authenticator application both for multifactor authentication (MFA) and for passwordless sign-in. Those are different capabilities inside Microsoft Authenticator, not interchangeable names for the same setup. For the worker, the distinction appeared as more instructions, more settings and more opportunities to get stuck.

It is tempting to answer this with the architecture that works well for a managed corporate laptop. Require a particular authenticator, prohibit synced credentials, standardize the hardware, then write a guide around that standard. That is a coherent answer to a different problem.

Here, neither a managed computer nor a company-issued phone was available. Requiring one as the starting point would not simplify the customer scenario; it would replace it. The useful question was whether the worker's existing phone could provide both the application surface and the authentication experience.

This is why an account of difficult cross-device registration in a restrictive corporate environment is relevant evidence, but not a verdict. You still need to test the experience under the actual device, browser and provider combinations that Entra supports. A phone-only browser journey deserves its own evaluation.

Optimize the journey the worker must complete, not the deployment you would prefer to manage. The device constraint is part of the design brief, not a detail to remove from it.

The recent Entra changes make this a different discussion

There are specific changes behind this recommendation, not just renewed enthusiasm for passkeys. Microsoft lists synced passkeys as generally available in March 2026, with passkey profiles controlling their use alongside device-bound credentials. An evaluation based on an earlier device-bound-only assumption is therefore evaluating a different set of available choices.

Microsoft then lists passkey support in registration campaigns as generally available in May 2026. The initial experience is optimized for users whose passkey profile has no restrictions. That is particularly relevant when the goal is to let a heterogeneous population use an available provider rather than an administrator's predicted provider.

There is also a more recent default change. From September 1, 2026, Microsoft documents automatic passkey enablement and registration nudges for users enabled for SMS or voice authentication, with a documented temporary opt-out. This is not a statement that every user is already enrolled, that every tenant now has the same policy, or that passwords have disappeared.

Those adoption nudges are useful context, but they do not bootstrap a worker who has no usable sign-in method yet. A campaign that appears after an existing authentication succeeds and a first-credential onboarding process solve different problems. The latter still needs a deliberate entry path, described later.

The practical change is that Entra supports passkeys in native and third-party providers as well as Microsoft Authenticator and security keys. For a supported phone with its provider already configured, the synced-passkey registration flow can use that provider. A separate Authenticator installation is not inherently part of that journey.

Notice the qualification: with its provider already configured. Microsoft explicitly documents a password-manager prerequisite for synced-passkey registration, including platform-specific settings. The improvement is not that every phone arrives in an identical state; it is that a usable existing state no longer has to be replaced with an additional application setup.

It would also be wrong to freeze Authenticator at an old onboarding experience. Microsoft now documents direct passkey registration from the Authenticator application, including configuration of passkey, passwordless and MFA capabilities according to account policies. That is a legitimate alternative when Authenticator is the chosen provider.

Reassess the current supported experience, not the reputation of an older one. For this customer, the meaningful improvement is a shorter same-phone route, not a promise that every operating-system dialog has become identical.

Authenticator is an application, not an authentication method

"Use Authenticator" is not a sufficiently precise authentication recommendation. The application supports MFA notifications and verification codes, passwordless phone sign-in, and device-bound passkeys. Those capabilities do not have the same enrollment requirements or the same authentication strength.

The distinction that matters most is passwordless versus phishing-resistant. Microsoft's built-in authentication-strength definitions place Authenticator phone sign-in in passwordless MFA, but not phishing-resistant MFA. Removing the password prompt is valuable; it is not the same property as requiring a phishing-resistant credential.

Passkeys use Fast Identity Online 2 (FIDO2) authentication. Entra treats both synced and device-bound passkeys as phishing-resistant, while giving administrators controls over which credentials they permit. The storage decision adds a separate trust question; it does not turn a synced passkey into an Authenticator notification.

Experience	Passwordless?	Phishing-resistant?	What the worker is configuring
Authenticator MFA, using a notification or verification code	Not by itself; it supplies an additional factor	No	An MFA method in the application, commonly used alongside a password
Authenticator passwordless phone sign-in	Yes	No	The application's passwordless phone-sign-in capability, distinct from a passkey
Device-bound passkey in Authenticator	Yes	Yes	A FIDO2 credential bound to that phone, with Authenticator acting as its provider
Synced passkey in a native or third-party provider	Yes	Yes	A FIDO2 credential managed and synced by the selected provider, rather than necessarily by Authenticator

The first row often leaves the worker with a password plus an additional verification step. The second removes the password from the sign-in experience, but remains a different method from FIDO2 passkey authentication. You cannot infer the required strength from the fact that the same application appears on the screen.

The third row is not "phone sign-in with a new label." Microsoft documents Authenticator passkeys as device-bound credentials. Choosing that option is a credential decision, not just enabling the application's older passwordless-notification feature.

The fourth row moves the credential-storage relationship into a passkey provider such as Apple Passwords or Google Password Manager. Microsoft documents provider-dependent synchronization across the user's devices. It is not a promise of unrestricted portability between every ecosystem.

The worker does not need this taxonomy on the welcome sheet. You need it in the design review so that "passwordless," "Authenticator" and "passkey" do not silently become synonyms. Otherwise, an apparently small wording error becomes a different enrollment path or an authentication-strength mismatch.

An application name is not a security property. Specify the credential and the required strength before deciding which application, if any, the worker must configure.

Same-device is the design choice that removes the detour

There are two independent axes in this discussion. Synced versus device-bound describes how the credential is stored and made available; same-device versus cross-device describes where the application and the authenticator are used. Microsoft documents both same-device and cross-device sign-in with device-bound Authenticator passkeys, so device-bound does not mean cross-device.

For the customer scenario, same-device means the worker opens the application on the phone and uses an available passkey provider on that phone. The supported synced-passkey setup follows that local provider experience. The user does not need a second screen merely to make the intended phone-only journey work.

Phone-assisted cross-device sign-in is different: the application is on a computer, while the passkey is on the phone. Microsoft's documented synced-passkey flow uses a QR code and requires Bluetooth and internet connectivity on both devices. Those are additional participants and dependencies, not properties that every passkey sign-in necessarily has.

Same-device sign-in

flowchart LR
    A["Web app on phone"] --> B["Passkey provider<br/>on that phone"]
    B --> C["Local verification:<br/>face, fingerprint or PIN"]

Phone-assisted cross-device sign-in

flowchart LR
    D["Web app on computer"] --> E["QR code, Bluetooth<br/>and internet"]
    E --> F["Passkey provider<br/>on phone"]
    F --> G["Local verification:<br/>face, fingerprint or PIN"]

Both paths still need to complete authentication and meet the application's Conditional Access authentication requirements. The two diagrams separate the user-facing topology, not different levels of permission. Cross-device is a useful capability when there actually is another device to sign in on.

A synced passkey does not force a cross-device ceremony either. If the provider has made the credential available locally on another supported device, that device can use the local credential rather than borrowing the phone. That follows the provider-dependent availability model for synced passkeys; it is a different situation from scanning a computer's code with a phone.

Why start a phone-only worker's registration guide on a computer?

For this scenario, that adds a device the worker was never promised. It also moves the demonstration away from the experience the company actually wants to support. A guide that begins on the personal phone keeps the registration flow and its provider selection in the same place as subsequent application use.

This is where the experience becomes almost unremarkable on a supported, correctly configured phone: select the passkey flow, confirm with the device's local verification, finish registration, then use the credential for sign-in. That is the target the documented registration and local sign-in experiences make possible. It is not a claim that every browser, old handset or provider configuration will behave identically.

The demonstration worth showing is the complete same-phone journey.

Keep the intended journey local before evaluating cross-device exceptions. Credential storage and authentication topology are separate decisions, and neither should be inferred from the other.

A permissive worker profile is a deliberate trust decision

For this particular population, the proposed starting point is a passkey profile without provider restrictions. Allow both device-bound and synced passkeys, do not enforce attestation, and do not target specific authenticator identifiers. These are supported passkey-profile choices, scoped to the relevant worker group rather than automatically applied to the whole tenant.

An Authenticator Attestation GUID (AAGUID) identifies an authenticator type, such as its make and model. Attestation gives Entra evidence about the authenticator creating the credential. Microsoft documents both controls and their limitations; they are not equivalent to confirming that a worker's personal phone is company-managed.

Here is the administrative intent, not an API payload. The self-service setting is global rather than profile-specific, which is a relevant distinction when reviewing existing configuration.

Population: Front-line worker pilot
Allow self-service set up (global): Yes
Enforce attestation (profile): No
Passkey types (profile): Device-bound + Synced
Target specific authenticators / AAGUID restrictions: Off

The sharp edge is that synced passkeys do not support attestation. Disabling attestation does not make FIDO2 authentication cease to be phishing-resistant, but it gives up verified authenticator provenance. Microsoft's warning is explicit: without enforced attestation, Entra cannot guarantee passkey attributes, including whether the credential is synced or device-bound.

That is why an AAGUID allowlist without attestation is not a substitute for hardware assurance. Microsoft says to treat unattested AAGUID restrictions as policy guidance rather than a strict security control. If the requirement is an attested, approved, device-bound authenticator, use a design that actually supplies that assurance.

For these workers, however, predicting one approved provider for every personal phone can add the constraint that the customer is trying to remove. An unrestricted profile permits the available native or third-party provider experience instead of blocking it through an administrator-maintained list. It does not guarantee that Entra will always choose the fastest provider or eliminate every provider-selection prompt.

The expectation in the discussion was that most users would register a synced passkey and a smaller number might choose a device-bound one. Treat that as a pilot hypothesis, not documented product behavior. Measure the registered methods and actual completion rate before turning an expectation into a rollout claim.

There are also configuration boundaries to review before changing an existing tenant. Microsoft documents that opting into passkey profiles cannot be reversed and transfers existing settings to a Default profile. It also documents that users scoped for multiple profiles can register or authenticate when the credential fully satisfies at least one applicable profile.

Do not accidentally put privileged accounts into a permissive worker scope and assume a stricter profile takes precedence. Conversely, do not assume tightening provider restrictions later is only a registration change: removing an allowed AAGUID can also prevent existing credentials from signing in. Scope and recovery are part of the policy change.

Less restrictive onboarding is a conscious trust decision, not absent security design. Keep the worker profile separate from populations whose credential-provenance requirements are different.

Bootstrap registration before you enforce the credential

The worker still needs a secure starting point. A Temporary Access Pass (TAP) is a time-limited passcode that can be configured for single use or multiple sign-ins and used to register passwordless authentication methods. It is the bootstrap credential, not the permanent method you want the worker to keep using.

First verify the worker's identity through the established onboarding process. Then issue a short-lived TAP through a controlled delivery process, and ensure the user is actually included in the TAP authentication-method policy. Creating a TAP for an account does not, by itself, make that account eligible to sign in with it.

SMS, personal email and a physical help desk are possible delivery channels to assess, not interchangeable identity-proofing guarantees. The security question is who can obtain the bootstrap credential and register the next method. A printed code handed to a verified worker and a code sent to an unverified contact address do not establish the same trust contract.

Prefer a single-use TAP where the tested journey supports it. Microsoft documents a 10-minute completion limit for passwordless-method registration after sign-in with a one-time TAP, so do not write an onboarding process that spends that window on unrelated setup. The code is also only visible at creation, making secure handling and delivery part of the operational design.

Conditional Access is where a sensible credential choice can still become a circular dependency. TAP satisfies the MFA authentication strength, not the phishing-resistant strength. Requiring an already-registered phishing-resistant method as the only way to reach its initial registration is not a stronger bootstrap; it is a route the new worker cannot complete.

Separate the bootstrap-compatible security-information registration policy from application access enforcement. Require an appropriate registration strength that permits the issued TAP, then require the intended credential for the application once the worker is ready. Review the complete applicable policy set, including broad resource scopes, rather than assuming one new registration policy neutralizes every other requirement.

Be precise about the application's requirement too. The built-in phishing-resistant MFA strength allows methods besides passkeys. If the requirement is specifically passkey-only access, use a custom authentication strength permitting Passkeys (FIDO2), with restrictions consistent with the worker profile.

The intended sequence is short. The TAP bootstrap and same-device passkey registration establish the method before application enforcement becomes the worker's gate.

sequenceDiagram
    participant Support as Onboarding support
    participant Worker
    participant Entra
    participant Phone as Phone passkey provider
    Support->>Worker: Verify identity and deliver time-limited TAP
    Worker->>Entra: Open Security info on phone and sign in with TAP
    Entra-->>Phone: Request passkey creation
    Phone->>Worker: Present provider and request local verification
    Phone-->>Entra: Complete credential registration
    Worker->>Entra: Fresh web app sign-in using the passkey
    Entra-->>Worker: Application access after policy checks

The worker-facing instruction should follow that sequence, using the labels in the documented registration flow. It should not ask the worker to choose a security architecture before they can open the application.

On your personal phone:
1. Open the Security info link in your onboarding message.
2. Enter the work username supplied in that message.
3. Sign in using your Temporary Access Pass.
4. Choose Add sign-in method, then Passkey.
5. Continue with the passkey provider offered on this phone.
6. Confirm with your face, fingerprint or device PIN.
7. Name the passkey, finish, then test the web application sign-in.
8. If Passkey is missing or setup cannot finish, contact support.

Test this with a genuinely new account, not just an administrator's already-configured phone. Microsoft documents that some combined MFA or password-reset registration interruptions after TAP sign-in do not support FIDO2 registration. An unrelated registration requirement can therefore derail the carefully written passkey guide.

Register, perform a fresh sign-in using the passkey, verify the application accepts the intended strength, and then enforce for the ready population. Use the documented report-only approach when evaluating registration policy, and keep an established recovery path. A recorded credential is not the same evidence as a successful application journey.

One final distinction: TAP does not replace or delete the account's password. This design avoids distributing a password and using one for this access journey. It does not, by itself, prove that every password-based route in the tenant has been removed.

Bootstrap establishes the credential; enforcement requires it. Keep those stages connected without making either one depend on a method the worker does not yet possess.

Automate the surrounding work, not the user's private key

Can onboarding be automated? Much of the surrounding work can, but installing an application and registering a personal credential are different operations. The supported synced-passkey registration flow still includes the user interacting with the provider on their device.

Microsoft Entra Lifecycle Workflows has a built-in task that generates a TAP and emails it to the new user's manager. That is a concrete automation option, not a claim that a workflow silently creates a synced passkey in the worker's personal provider. The documented task also has prerequisites, including manager and manager-email attributes.

The prehire onboarding tutorial documents the relevant licensing requirements. If that fits the organization's operating model, automate eligibility, timing, manager notification and the supported bootstrap task. Still decide how the manager verifies the recipient and delivers the code without turning a sensitive credential into an indefinitely retained onboarding attachment.

A third-party onboarding product can improve orchestration, guidance or verified delivery. Ask which step it automates and which device-side interaction remains. A claim of "automated passwordless onboarding" is not enough to establish that it removes the user steps in the supported registration flow.

There is a different administrator-led route for hardware. Microsoft documents FIDO2 security-key provisioning through Microsoft Graph and custom clients as a preview capability, including provisioning and registering a physical key for the user. That introduces hardware procurement, handling, distribution and replacement, so it changes this customer's no-additional-hardware scenario rather than automatically solving it.

Recovery deserves the same attention as first registration. With a synced credential, the provider's synchronization and account-access model becomes part of the trust decision. Do not assume that a worker replacing a phone always has the right provider account, settings and recovery access immediately available.

With an Authenticator passkey, do not promise that restoring application backup moves the credential to new hardware. Microsoft explicitly states that Authenticator passkeys are device-bound and cannot be synced. Maintain a verified recovery process for workers who lose access to their existing method.

Nor does phishing-resistant authentication establish the security posture of an unmanaged personal phone. The passkey policy's credential controls and attestation limits are not a device-management programme. Accepting this access model remains a business and security decision about the application and its exposure.

The pilot should therefore measure more than whether a passkey can be created. Record unassisted registration completion, time to a fresh successful application sign-in, support contacts, provider distribution and recovery completion. Compare those outcomes with the existing journey before claiming the customer problem has been solved.

The honest answer to "to passkey or not to passkey" is not a universal instruction to relax every policy. For this population, a broadly compatible passkey profile and same-device synced-passkey journey are the design worth testing first. A corporate population requiring attested, device-bound credentials has a different requirement and can reach a different answer.

Keep the administrative concepts in the control plane and the worker's task on the worker's phone. The useful improvement is not asking workers to understand four authentication methods; it is no longer requiring them to navigate four methods to reach one application.

References

Agent-to-agent authorization with Entra Agent ID on AWS AgentCore

Anton Staykov — Tue, 29 Sep 2026 09:07:00 +0000

The first two versions of my Amazon Web Services (AWS) proof of value established cross-cloud Microsoft Entra Agent ID and removed the long-lived client secret. Version 3 answers the question customers now ask most often: what happens when one agent calls another?

It is tempting to treat Agent2Agent (A2A) as a new identity problem because the caller and resource are both agents. It is not. A2A changes the communication contract. It does not replace the authentication and authorization contract.

The sample is astaykov/agentid-agentcore. Release v3.0 adds that missing hop. Agent 1 delegates directory work to Agent 2 on behalf of a signed-in user. Agent 3 calls Agent 2 autonomously. Both use A2A, both present Microsoft Entra access tokens, and they receive deliberately different capabilities.

Version 3 makes agent-to-agent authorization the point

The first article proved that an AWS-hosted agent can use Entra Agent ID to reach Microsoft and AWS resources. Its purpose was cross-cloud identity portability.

The second article replaced the blueprint client secret with an AWS Security Token Service (STS) assertion and a federated identity credential (FIC). Its purpose was secretless workload authentication.

Version 3 begins where those two stop. It keeps the cross-cloud federation and introduces two more agents:

Agent 1 remains the user-facing orchestrator in AgentCore Runtime.
Agent 2 is an A2A specialist in a second AgentCore Runtime.
Agent 3 is an autonomous caller running in AWS Lambda and triggered by Amazon EventBridge Scheduler.

The v3 repository documentation makes the new authorization split explicit. Agent 1 calls Agent 2 with delegated user authority, while Agent 3 calls the same agent with application authority. Agent 2 exposes directory tools only to the delegated path.

That is what v3 adds. Blueprint 2 becomes a resource boundary where two kinds of principals arrive through one protocol and must not collapse into one permission set.

A2A standardizes the message, not the trust decision

The A2A specification defines a common model for agent discovery, messages, tasks, artifacts, and protocol bindings. An Agent Card advertises what an agent can do and how a client can reach it. A message/send operation carries work from one agent to another.

None of that turns an Agent Card into a permission grant.

AWS makes the separation visible in its AgentCore A2A deployment model and protocol contract. An A2A server exposes its Agent Card at /.well-known/agent-card.json, receives JSON-RPC requests at the root path, and can authenticate clients with OAuth 2.0 bearer tokens or AWS Signature Version 4. AgentCore provides the transport and an authentication gate. The agent application still owns the claim-level authorization decision.

The sample currently pins A2A protocol version 0.3.0, matching the implementation documented in the v3 setup guide. The current A2A specification lists 1.0.0 as the latest released version. That version difference matters for interoperability work, but it does not change the identity principle: the protocol relies on standard web security rather than inventing an agent-specific token.

flowchart LR
    User["User + browser"] -->|"Token for Blueprint 1"| A1["Agent 1<br/>orchestrator"]
    A1 -->|"A2A delegated token"| A2["Agent 2<br/>specialist"]
    Scheduler["EventBridge"] --> A3["Agent 3<br/>autonomous Lambda"]
    A3 -->|"A2A app-only token"| A2
    A2 -->|"Delegated token"| MCP["Microsoft MCP server"]
    R1["AWS role 1"] -.->|"FIC"| B1["Blueprint 1"]
    R2["AWS role 2"] -.->|"FIC"| B2["Blueprint 2"]
    R3["AWS role 3"] -.->|"FIC"| B3["Blueprint 3"]

The A2A request does not contain a magical statement that one agent trusts another. It contains a normal bearer token for Blueprint 2, and that resource validates normal Microsoft Entra claims. The task is agent-shaped. The trust contract is still OAuth.

Protocol interoperability does not imply authorization equivalence. Two callers can speak the same A2A dialect and still belong on opposite sides of a capability boundary.

Separate blueprints make three workload trust roots visible

All three agents belong to the same proof-of-value deployment, but they do not all use the same compute surface. Agent 1 and Agent 2 run in AgentCore Runtime, while Agent 3 runs in Lambda. They could still reference agent identities created from one shared blueprint because a blueprint is a reusable template for multiple agent identities.

I deliberately did not model them that way.

Each agent has its own blueprint, its own child agent identity, and its own AWS execution role. Each blueprint has one FIC whose subject is the matching AWS role Amazon Resource Name (ARN). Blueprint 1 trusts ExecutionRoleArn, Blueprint 2 trusts SpecialistRoleArn, and Blueprint 3 trusts AutonomousRoleArn, as recorded in the Entra setup guide.

Why spend three blueprints where one might function?

Because the sample is meant to expose the control planes. Microsoft documents that the blueprint holds the credential while the child agent identity has no credential of its own. Reusing one blueprint would therefore reuse one credential-bearing parent across three operational roles. That can be a legitimate production design. It is the wrong teaching design when the goal is to inspect three independent workload attestations.

The separate model makes a one-to-one relationship visible:

an AWS execution role identifies the running workload;
a FIC tells one blueprint which AWS role assertion it accepts;
the blueprint acquires a token for one child agent identity; and
that agent identity appears as the caller or actor in downstream authorization.

The cost is more Entra objects and more configuration. The benefit is a smaller conceptual and operational blast radius. Rotating, disabling, or misconfiguring Blueprint 3 does not change the credential trust for Agent 2.

A shared blueprint groups agents by kind or runtime. A separate blueprint isolates credential ownership and blast radius. The right production choice depends on whether those agents are interchangeable instances or independent security principals. For this demonstration, clarity wins.

Blueprint 2 is an API surface, not just Agent 2's credential holder

The most important setup step in v3 is easy to misread. Blueprint 2 authenticates Agent 2 through its FIC, but it also represents the resource API that Agent 1 and Agent 3 request tokens for. Microsoft documents that a blueprint receiving incoming requests needs an identifier URI and OAuth scope, just like any other protected web API.

The sample gives Blueprint 2:

the identifier URI api://{blueprint-2-client-id};
access-token version 2;
delegated scope user_impersonation;
user role Agent2.Tools.User; and
application role Agent2.Chat.Application.

The relevant shape is below. The actual setup uses generated globally unique identifiers for every scope and role.

{
  "identifierUris": ["api://{blueprint-2-client-id}"],
  "api": {
    "requestedAccessTokenVersion": 2,
    "oauth2PermissionScopes": [
      {
        "id": "{scope-guid}",
        "value": "user_impersonation",
        "type": "User",
        "isEnabled": true
      }
    ]
  },
  "appRoles": [
    {
      "id": "{user-role-guid}",
      "value": "Agent2.Tools.User",
      "allowedMemberTypes": ["User"],
      "isEnabled": true
    },
    {
      "id": "{application-role-guid}",
      "value": "Agent2.Chat.Application",
      "allowedMemberTypes": ["Application"],
      "isEnabled": true
    }
  ]
}

Why define both a scope and a user role for the delegated path?

They answer different questions. The scope says that the client agent has delegated consent to call Blueprint 2 on behalf of a user. The user role says that this user is assigned to the directory-tool capability exposed by Agent 2. Microsoft recommends that a protected API verify scopes for calls made on behalf of users and app roles for application callers. The same guidance allows a user-assigned app role to add a second claim-based boundary to delegated access.

The application role answers a third question: may this autonomous principal call Agent 2 without a user? Microsoft Entra emits assigned app-role values in the roles claim, and app roles can be assigned to users, groups, or another application's service principal.

Definitions are not grants. Creating user_impersonation does not consent Agent Identity 1 to it. Creating Agent2.Tools.User does not assign a user. Creating Agent2.Chat.Application does not authorize Agent Identity 3.

The setup therefore creates three separate grants:

An oauth2PermissionGrant from the Agent Identity 1 to the Blueprint 2 resource service principal for user_impersonation.
A user or group assignment to Agent2.Tools.User on the Blueprint 2 resource service principal.
An app-role assignment from Agent Identity 3 to Agent2.Chat.Application on the Blueprint 2 resource service principal.

Microsoft Graph distinguishes application IDs from service-principal object IDs here. The oAuth2PermissionGrant resource expects the client and resource service-principal object IDs. The app-role assignment API likewise uses the principal, resource, and role IDs.

That distinction is not administrative trivia. It determines which principal receives the claim. A delegated grant on the blueprint principal is not a grant to Agent Identity 1. An application role assigned to Blueprint 3 is not automatically a role assigned to Agent Identity 3. Authorize the principal that will actually appear in the token exchange.

The delegated path composes client consent, user assignment, and caller identity

The user-delegated path begins before A2A. The browser obtains a token for Blueprint 1 and invokes Agent 1. Agent 1 then needs a new token whose audience is Blueprint 2. Forwarding the browser token would be wrong because an access token is valid only for its intended audience, and Microsoft explicitly warns against relaying middle-tier access tokens to another resource.

Agent 1 first authenticates through Blueprint 1. Its AWS role obtains a short-lived AWS assertion, Blueprint 1's FIC accepts that assertion, and the blueprint obtains the federated managed identity (FMI) token bound to Agent Identity 1. Agent Identity 1 then performs the Microsoft Entra agent on-behalf-of (OBO) flow using the user's Blueprint 1 token as the assertion and api://{blueprint-2-client-id}/user_impersonation as the requested downstream scope.

The resulting token for Agent 2 carries the user's identity, the delegated scope, the role assigned to that user on Blueprint 2, and the authorized-party identity of Agent Identity 1. Agent 2 validates all of them.

sequenceDiagram
    participant U as User
    participant A1 as Agent 1
    participant E as Microsoft Entra
    participant A2 as Agent 2
    participant M as MCP server

    U->>A1: Token for Blueprint 1
    A1->>E: AWS assertion + Agent 1 FMI/OBO exchange
    E-->>A1: Blueprint 2 token with scp + user role
    A1->>A2: A2A message/send + bearer token
    A2->>E: Agent 2 FMI/OBO exchange
    E-->>A2: Delegated MCP token
    A2->>M: Directory tool call

The v3 authorizer does not treat scp as sufficient. It requires:

aud to identify Blueprint 2;
scp to contain user_impersonation;
roles to contain Agent2.Tools.User;
azp to equal Agent Identity 1; and
the token not to identify itself as an app-only token.

This composition blocks several accidental privilege paths. A user assigned to the role cannot invent a client that lacks delegated consent. A consented client cannot use directory tools for a user who lacks the role. A different client cannot replay an otherwise valid Blueprint 2 token and pass the caller check.

After that first A2A authorization, Agent 2 still does not forward the Blueprint 2 token to the Microsoft MCP server. It performs another OBO exchange through Blueprint 2 and Agent Identity 2 for the MCP resource scopes. The OBO protocol exists precisely for this audience transition: each middle tier receives a token for itself, then requests a different token for the next resource.

There are two authorization boundaries in this chain. Blueprint 2 controls whether the user and Agent 1 may invoke Agent 2's directory skill. The MCP resource controls what Agent 2 may do with the user's delegated authority. A2A delegation does not erase downstream consent. It adds another resource to the chain.

The autonomous path receives an app role and no inherited tools

Agent 3 has no signed-in user. EventBridge Scheduler invokes its Lambda under AWS controls, then Agent 3 uses its own AWS role, Blueprint 3 FIC, and Agent Identity 3 to request an app-only token for Blueprint 2.

The Microsoft Entra autonomous agent flow still starts with the blueprint credential and an FMI token for the child agent identity. The second exchange uses client credentials and requests api://{blueprint-2-client-id}/.default. For client-credentials flows, .default resolves the application permissions already granted for that resource.

Agent Identity 3 has exactly one such assignment on Blueprint 2: Agent2.Chat.Application.

No scp claim is expected because there is no user delegation. Agent 2 instead requires:

roles to contain Agent2.Chat.Application;
azp to identify Agent Identity 3;
oid to identify Agent Identity 3; and
the requested skill to be chat.

The sample's authorization implementation reduces the distinction to an explicit branch:

if claims.get("scp") is not None:
    require_scope(claims, "user_impersonation")
    require_role(claims, "Agent2.Tools.User")
    require_caller(claims, agent1_id)
    mode = "delegated"
else:
    require_role(claims, "Agent2.Chat.Application")
    require_caller(claims, agent3_id)
    require_subject(claims, agent3_id)
    mode = "application"

if skill == "directory" and mode != "delegated":
    deny()

The actual code validates the signature with Microsoft Entra signing keys, issuer, audience, expiry, issued-at time, tenant, and claim types before this authorization branch. That follows the protected-API rule that authentication alone is insufficient: the API must verify the expected permission claims.

Notice what is not in the autonomous path. There is no user role, no delegated scope, and no MCP token exchange. Agent 2 constructs a tool-free agent for chat; an app-only caller asking for directory is rejected before a model or tool is invoked. Prompt text cannot promote the caller into another authorization mode because the tool list is selected after claim validation, not by the model.

This is the useful A2A result. Agent 3 can collaborate with Agent 2 without inheriting the directory authority available to Agent 1's user-delegated path. Agent-to-agent connectivity is not transitive permission.

Authorization must fail before the model gets a vote

An Agent Card can advertise a skill. That does not mean every authenticated caller may execute it. The A2A specification deliberately aligns security with standard enterprise web practices, and AgentCore supports OAuth bearer authentication at the runtime boundary. The sample adds the missing resource-server checks inside Agent 2.

That ordering matters:

AgentCore verifies the inbound JWT configuration before invoking the runtime.
Agent 2 validates the token signature, issuer, audience, lifetime, and required identity claims.
Agent 2 distinguishes delegated from application mode.
Agent 2 checks the scope, role, expected caller, and requested skill.
Only then does it construct a model with either directory tools or an empty tool list.

AgentCore currently forwards the A2A bearer token through an allowlisted runtime header so the application can perform those checks. AWS documents that custom headers can reach the runtime only when allowed by its configuration, and that the Authorization header requires a custom JWT authorizer. The sample accepts the AgentCore-compatible forwarded header and never puts the token into the A2A message, Agent Card, prompt, or logs.

The negative tests are as important as the successful calls. The v3 demonstration guide checks a user without the Blueprint 2 role, Agent 1 without delegated consent, Agent 3 without its application role, an app-only request for the directory skill, and tokens with the wrong issuer, audience, signature, or lifetime.

Those failures locate the trust boundary:

missing consent fails token acquisition;
missing assignment fails token issuance or resource authorization;
the wrong caller fails claim authorization;
the wrong skill fails capability authorization; and
an invalid token fails authentication.

There is no single "A2A authorized" bit. There is a chain of independently testable decisions, and every one happens before a model can interpret the request.

The first version of this proof of value showed that Entra Agent ID is not limited to Microsoft-hosted agents or Microsoft-hosted resources. The second showed that cross-cloud identity does not require a shared client secret. Version 3 closes the next gap: one governed agent can call another through an open protocol without abandoning scopes, roles, consent, workload attestation, or resource-specific enforcement.

A2A is not a shortcut around your authorization model. It is where that model becomes visible.

References

Encryption in transit is not end-to-end encryption: block unsanctioned GenAI access

Anton Staykov — Tue, 22 Sep 2026 10:33:00 +0000

Encryption in transit is not end-to-end encryption

The distinction is simple and it matters more in GenAI than in most other areas of technology. TLS protects a connection while data is moving across a network segment. It does not mean the application data is protected from every intermediary that handles the request. A reverse proxy, gateway, WAF, or API layer can terminate TLS, inspect the payload, and then forward it onward. That is still encryption in transit. It is not end-to-end encryption.

This is the real security question behind the AI risk conversation. If an employee pastes a secret into a third-party AI assistant, the data leaves the trust boundary of the organization. At that point, the provider, the proxy, and any downstream service can observe, store, or process it. The issue is not whether the connection was protected while it crossed the public Internet. The issue is whether the organization still controls the data lifecycle.

NIST describes TLS as protecting data during electronic dissemination across the Internet in the classic sense, and that is accurate. But it is not the same as saying the data remains protected from every system that participates in the request path. NIST SP 800-52 Revision 2 is careful about transport security, not end-to-end application protection.

There is a quiet assumption baked into many security conversations, and it usually goes unspoken: if the data is encrypted on the wire, the problem is solved. It is not. The network path can be encrypted on every hop while the gateway still sees the plaintext. That is the core distinction.

The common gateway topology looks like this:

sequenceDiagram
    participant Client as Browser/App
    participant Gateway
    participant Backend
    Client->>Gateway: TLS connection 1
    Note over Gateway: TLS terminates here<br/>plaintext exists here
    Gateway->>Backend: TLS connection 2

That diagram has two separate cryptographic relationships. The browser is not cryptographically protected all the way to the backend service. It is protected to the gateway, and then the gateway creates a second protected connection to the backend.

TLS connection 1:
Browser/App <=================> Gateway

TLS connection 2:
Gateway <=================> Backend

That is a valid transport-security architecture. It is not an end-to-end content-protection architecture.

True end-to-end encryption protects the payload from the gateway

End-to-end encryption changes the location of the cryptographic boundary. The gateway can still route the request, enforce some policy, and observe metadata. It cannot decrypt the protected application payload.

sequenceDiagram
    participant Client as Browser/App
    participant Gateway
    participant Backend as Backend Service
    Client->>Client: encrypt(payload, backend key)
    Client->>Gateway: TLS plus encrypted payload
    Note over Gateway: Gateway transports ciphertext<br/>Gateway cannot decrypt
    Gateway->>Backend: TLS plus encrypted payload
    Backend->>Backend: decrypt(payload)

In that model, the application content is protected before it reaches the gateway. The gateway sees an HTTP request, but the sensitive body is opaque unless it has the backend-controlled decryption material.

{
  "payload": "BASE64_ENCRYPTED_BLOB..."
}

The gateway might see routing data and headers like this:

POST /api/messages
Host: service.example
Authorization: ...
Content-Type: application/octet-stream

8gh29HFn4k...     <-- opaque encrypted content

That distinction is not academic. It determines whether the gateway is a reader of the data or a carrier of ciphertext.

Architecture	Data encrypted on wire?	Gateway sees plaintext?	E2E encrypted?
Client -> TLS gateway -> HTTP backend	Partially	Yes	No
Client -> TLS gateway -> TLS backend	Yes	Yes	No
Client encrypts payload -> gateway -> backend decrypts	Yes	No	Yes

The gateway is the control plane, not just a door

This is where the real security story starts. A gateway is not merely a convenience layer between users and services. It is often the central choke point for policy enforcement, authentication, logging, routing, and transformation. In enterprise architecture, that makes it a high-value concentration point for sensitive data and a privileged path to the Internet.

The design pattern is common across Azure and enterprise stacks. An application gateway, API gateway, or reverse proxy does not just pass traffic. It terminates connections, reads headers, inspects payloads, enforces policies, and often writes transaction metadata to logging, monitoring, and analytics systems. Azure Application Gateway TCP/TLS proxy overview describes exactly this behavior: the gateway acts as a reverse proxy and can proxy TCP and TLS traffic as part of the service architecture. In API management terms, the platform sits in front of backend APIs and shapes how traffic moves and is governed. What is Azure API Management? describes the gateway as an operational control layer, not just a network convenience.

That matters because gateway functionality is never isolated from data exposure. The same component that handles TLS, routing, and policy enforcement also sees the application content unless the design explicitly encrypts beyond that boundary. If the gateway is visible to the enterprise as a single control point, then the enterprise also has to treat it as a single blast-radius concentration point.

This is the part many organizations miss. Endpoint controls are designed for the client devices, not for the central trust boundary that sits between the organization and the Internet. The endpoint can be managed, patched, and monitored. The gateway is different. It is a shared service used by many applications and many users. It often sits near the edge of the trust boundary, and it often has deep visibility into the same data that the browser or mobile app sends.

That makes the gateway a strategic security object. It is both:

a concentration point for highly valuable company information, because it sees data from many users, workloads, and applications, and
a gateway to the Internet, because it provides the path that traffic uses to leave the enterprise boundary.

If you treat the gateway as purely an infrastructure detail, you miss the real architectural risk. You are treating a privileged control plane as if it were just a traffic relay.

The trust boundary is the thing that matters

The key concept here is the trust boundary. A prompt sent to a public AI assistant crosses the enterprise trust boundary whether or not the network path is encrypted. In many cases, the user is not just calling a service. They are handing their data to a third party and the provider decides what it does with the data next. The organization may not control the log retention, model training settings, contract terms, or retention policy.

The same architectural reality appears in an internal enterprise API gateway. If a backend service has to see customer data to do its job, then the gateway is an important intermediary but not the authoritative security boundary. The real security question is where the data becomes visible and who can access it.

This is exactly why the phrase "encrypted in transit" is not enough. It says the data is protected while traveling between endpoints. It does not say the data is protected from the endpoints themselves. A TLS connection between browser and gateway and then between gateway and backend can be secure and still leave the gateway in the clear. The gateway can observe the plaintext, and that is enough to change the risk model.

The honest answer is that you do not need a single broken protocol to create a dangerous exposure pattern. You need a better boundary model.

Why the GenAI risk is different

The GenAI category widens that problem because it combines two factors that are easy to ignore when taken separately:

employees are under pressure to move quickly and show productivity, and
the AI assistant experience is designed to feel like a normal consumer product, not a corporate system with controls.

That combination is toxic. People paste code, customer data, pricing files, internal proposals, and architecture notes into tools that are not part of the approved enterprise trust domain. Sometimes it is a free tier. Sometimes it is a personal subscription. Sometimes it is because the company license is exhausted or the app is simply more convenient. Sometimes it is because the employee is trying to solve a real business problem under pressure and there is no policy or review path.

This problem is not theoretical. The recent AI supply-chain and exposure stories show the broader pattern: the path to an AI model is no longer just an application call. It is a software supply chain, a routing layer, a credential boundary, and sometimes a logging sink. The article about the LiteLLM compromise describes a malicious package supply-chain story in which compromised open-source tooling resulted in secrets theft and credential exposure from CI/CD and runtime environments. The investigation is presented as a real-world supply-chain incident, with the article citing forensic research from Snyk, Trend Micro, and Cycode and describing the malicious package behavior in detail. InfoStealers on the LiteLLM incident and the linked Snyk, Trend Micro, and Cycode coverage point to the same risk class: if a tool sits in the path to the model, it becomes part of the exposure surface.

The Pandaily story about a reported 6 TB LLM router log data exposure should be treated carefully. It is not the same as a definitive forensic closure on every claim, but it reinforces the same basic truth: AI router layers, model gateways, and data processing intermediaries are becoming valuable operational targets. Pandaily claim on LLM router logs is a useful cautionary example even if the final attribution and scope remain contested.

The broader point is not that every AI service is malicious. The point is that once a prompt, file, or API key crosses into an unvetted service, the organization no longer controls the trust boundary. The data becomes part of a new processing environment with a different contract, a different logging model, and a different risk posture.

This is why the enterprise question is not "does this service use TLS?" It is "what is the data-handling contract and where is the trust boundary?"

Strong AI governance already has an identity plane

The governance answer is not only "block the app." It is also "move the control plane to the identity layer." Microsoft Entra Global Secure Access gives organizations a cloud-delivered security service edge that can enforce policy around private and internet access based on identity-aware controls, rather than relying only on endpoint posture. What is Global Secure Access? frames the problem in exactly this way: the modern workforce needs an identity-aware, cloud-delivered network perimeter.

That matters because AI governance is not just a DLP conversation. It is also an access-governance conversation. What is entitlement management? describes how organizations can automate access request workflows, assignments, reviews, and expiration across apps, groups, and SharePoint resources. Governance fails when access is granted on an ad hoc basis and never reviewed. Entitlement management is how you turn AI access into a time-bound, auditable trust decision.

And the last layer is user authentication. If the employee is authenticating with a phishing-resistant method such as a passkey, Face ID, or Windows Hello, the enterprise is materially reducing the chance that the decision to use a third-party AI tool is driven by a credential theft event. Passwordless authentication in Microsoft Entra is the modern model here: secure, modern credentials reduce the risk that a weak human factor becomes the path into an unauthorized AI workflow.

You do not solve unsanctioned GenAI risk by adding one more checkbox to a policy page. You solve it by combining: a real trust boundary, policy enforcement at the edge, time-bound access, and phishing-resistant identity. That is how you turn a convenience problem into a governed control plane.

The real answer is not a policy slogan. It is a system design rule

Most organizations already know the first half of this story. They know they should not permit employees to dump customer data into a random public AI tool. The harder question is how to make that true in practice without breaking productivity.

The answer is simple but not trivial: build an approved AI path and block the rest.

That means a clear policy that treats unsanctioned GenAI like a data exfiltration control issue, not an employee-choice convenience issue. It means approved enterprise services with explicit contracts, data handling statements, and retention boundaries. It means DLP rules that detect prompts, attachments, and API keys. It means browser and network controls that prevent direct access to unapproved AI endpoints. It means a governance process that makes it easy to use the sanctioned tool and hard to use the unsanctioned one.

This is also where the gateway again becomes central. If the gateway is the high-value choke point, then the policy should be enforced there. If an organization treats the gateway as a neutral network device, it will miss the operational fact that the gateway is one of the highest-value security assets in the environment. The gateway is where you can identify unauthorized model traffic, inspect prompts in transit, block exfiltration, and enforce control-plane policy at the edge. That is not a minor operational detail. It is a foundational design decision.

The issue is not that "maybe one employee clicked the wrong thing." It is that the gateway is already the place where a lot of sensitive information is concentrated. Endpoint controls do not apply to the gateway. Endpoint controls do not protect the shared trust boundary. They protect the device. The gateway is not the device. The gateway is the enterprise chokepoint.

This is why the right default posture is to ask a sharper question before approving a new AI use case:

what data crosses the enterprise boundary?
which service receives it?
what logging and retention obligations are in force?
what downstream processing and model training settings apply?
what is the contractual and legal boundary for the data?

If the answers are vague, the answer is no. If the service is not part of the approved enterprise trust domain, it should not receive business data.

And that means the governance question is not about the browser. It is about the trust contract

A lot of AI governance conversations still focus on the user experience. They ask whether a feature is easy to use, whether employees can paste a prompt into a chat box, and whether the assistant is helpful. That is not the right security frame. The question is whether the organization is handing data to a service that it can trust, monitor, and govern.

That is the point behind the Azure AI guidance: approved enterprise services are designed around data boundaries and customer data handling commitments. Data, privacy, and security for Models sold by Azure in Microsoft Foundry lays out the important contract: Microsoft explicitly states that Azure OpenAI does not use customer data to retrain models for the foundation model service, which is a materially different security and governance posture from a personal or unsanctioned AI app.

The organization is not just buying a productivity feature. It is buying a trust contract. A service that does not provide a clear data-handling boundary cannot be treated as a sanctioned enterprise AI tool just because it is convenient.

The policy implication is direct. If you do not have a clear control plane, a policy boundary, and a trusted data-handling contract for the AI service, then the enterprise should not allow business data into it. That is the architectural rule. The app might be encrypted. The gateway might be protected. The logs might be clean. But if the organization does not control the data lifecycle, it does not control the risk.

The gateway is a privileged point in your architecture. You should design around it as if it were a crown jewel. If it sits on an unsanctioned AI path, the enterprise data is already outside the trust boundary. That is not a training issue. It is a governance issue.

References

How an AWS-hosted Entra Agent ID drops the client secret

Anton Staykov — Wed, 16 Sep 2026 10:30:00 +0000

After I published One identity, two clouds: an AWS-hosted agent that authorizes with Microsoft Entra Agent ID, most of the follow-up questions were not about the cross-cloud authorization model.

They were about the client secret.

Where should it be stored? How should it be rotated? Should it live in AWS Secrets Manager? What happens when it expires?

Those are sensible production questions. They were also questions about a demonstration compromise, not the architecture I wanted people to take away. The point of the sample was to show that an agent hosted in AWS can carry a governed Microsoft Entra Agent ID. The secret was plumbing used to keep the first proof of concept focused.

Release v2.0 of the sample removes that distraction. The agent now uses Microsoft Entra workload identity federation with AWS IAM Outbound Identity Federation. AWS attests to the workload with a short-lived JSON Web Token (JWT). Microsoft Entra accepts that JWT only when it matches an explicitly configured trust relationship.

There is no Entra client secret in the runtime path.

The interesting part is not that a secret moved somewhere safer. It is that the two clouds stopped sharing one.

The client secret was never the identity

An Agent ID blueprint needs to authenticate before it can acquire tokens for the agent identities it governs. Microsoft documents federated identity credentials, certificates, and client secrets as supported blueprint credential types, while the agent identity itself does not hold a credential of its own (Agent identities in Microsoft Entra Agent ID).

The first version authenticated the blueprint with a client secret. That proved the Agent ID token flow, but it also introduced a long-lived value with the usual lifecycle:

Generate it in Microsoft Entra.
transport it to AWS;
protect it at rest and in deployment;
expose it to the process that needs it;
rotate it before expiry; and
coordinate the old and new values without interrupting the agent.

A capable secret manager improves several of those steps. It does not remove them. Microsoft's workload identity federation guidance makes the recommendation explicit: configure Entra to trust tokens from the workload's external identity provider, then exchange those tokens for Microsoft identity platform access tokens.

For this sample, the external identity provider is not another directory bolted onto the design. It is AWS itself.

What version 2.0 changes

The core agent architecture remains the same. The agent still runs in Amazon Bedrock AgentCore Runtime, still has a Microsoft Entra Agent ID, and still obtains resource-specific tokens for downstream calls.

Only the blueprint authentication step changes:

Before, the AgentCore process presented an Entra client secret.
Now, the process asks AWS Security Token Service for a short-lived web identity token representing its IAM role.
Microsoft Entra validates that AWS token against a federated identity credential (FIC) configured on the Agent ID blueprint.
After that validation, the established Agent ID blueprint-to-agent token flow continues.

Microsoft now lists AWS workloads using IAM Outbound Identity Federation as a supported workload identity federation scenario (Workload identity federation concepts). AWS documents the corresponding outbound identity federation setup and the AWS Security Token Service (STS) GetWebIdentityToken API.

The flow looks like this:

sequenceDiagram
    participant Agent as AgentCore runtime
    participant STS as AWS STS
    participant Entra as Microsoft Entra token endpoint
    participant API as Downstream API

    Agent->>STS: GetWebIdentityToken using the runtime IAM role
    STS-->>Agent: Short-lived AWS-signed JWT
    Agent->>Entra: Blueprint token request with AWS JWT as client_assertion
    Entra->>Entra: Match issuer, subject, and audience
    Entra-->>Agent: Blueprint token (T1)
    Agent->>Entra: Agent token request with T1 as client_assertion
    Entra-->>Agent: Agent identity access token
    Agent->>API: Call with agent identity access token

There are two assertions here, and conflating them hides the actual security model.

The AWS JWT proves which AWS workload is calling. The blueprint token proves that the authenticated blueprint is allowed to acquire a token for a particular agent identity. Neither token is the final downstream access token.

Configure AWS to attest to the workload

AWS IAM Outbound Identity Federation lets an IAM principal request an OpenID Connect (OIDC)-compatible token for an external service. The account must first have outbound web identity federation enabled, and the AgentCore runtime role must be allowed to call sts:GetWebIdentityToken (Enabling AWS IAM Outbound Identity Federation).

The permission should constrain what the role can request. In this design, the audience is:

api://AzureADTokenExchange

That is the audience Microsoft recommends for an external assertion presented to its token exchange (Configure an app to trust an external identity provider). Restricting the AWS permission to this audience prevents the role from using the same permission to mint arbitrary outbound identity tokens for unrelated relying parties.

The runtime obtains the assertion from STS:

import boto3

sts = boto3.client("sts")

response = sts.get_web_identity_token(
    Audience=["api://AzureADTokenExchange"],
    SigningAlgorithm="RS256",
    DurationSeconds=300,
)

aws_assertion = response["WebIdentityToken"]

The method and response shape are defined by the AWS GetWebIdentityToken API. A five-minute lifetime is not a universal requirement, but it keeps the assertion useful only for the immediate exchange and limits the value of a captured token.

The token has three claims that matter to the Entra trust:

iss identifies the account-specific AWS outbound identity federation issuer.
sub identifies the AWS IAM principal, in this case the AgentCore runtime role.
aud identifies Microsoft Entra's token exchange as the intended recipient.

AWS signs the token and publishes the metadata Microsoft Entra needs to validate it. The application does not create or sign the JWT itself.

Configure Entra to trust one AWS role

The corresponding federated identity credential belongs on the Agent ID blueprint's application registration. It contains the expected issuer, subject, and audience:

{
  "name": "agentcore-runtime",
  "issuer": "https://<account-specific-id>.tokens.sts.global.api.aws",
  "subject": "arn:aws:iam::<account-id>:role/<agentcore-runtime-role>",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

These are not descriptive labels. Microsoft Entra compares them with the iss, sub, and aud claims in the incoming AWS token. The values must match exactly and case-sensitively (Workload identity federation concepts).

That exact match is the authorization boundary.

Do not set the subject to an account-wide wildcard. Federated identity credentials do not support wildcards anyway, and that limitation is useful here (Configure an app to trust an external identity provider). Trust the runtime role that represents this workload. If another role needs the same blueprint, make that an explicit trust decision rather than an accidental side effect of a broad pattern.

The trust can now be stated without cloud branding:

Accept a token from this issuer, for this subject, intended for this audience.

That is the part workload identity federation standardizes. Microsoft Entra does not need the AWS access key. AWS does not need the Entra client secret.

The most important code is in the MSAL constructors

The raw HTTP requests explain the protocol, but they are not how version 2.0 implements it. The important part of the sample is how it composes two long-lived msal.ConfidentialClientApplication instances with two callable client-assertion providers.

There are two documentation layers behind this code. The Microsoft Authentication Library (MSAL) team's FIC and federated managed identity (FMI) guidance for agentic scenarios describes the Agent ID-specific blueprint, fmi_path, blueprint token (T1), and child-agent exchange. The MSAL Python ConfidentialClientApplication reference describes the generic confidential-client constructor and its client_credential parameter. The v2.0 sample joins those two layers by supplying functions as the client assertions.

That distinction matters because a client assertion is short-lived. Passing the current JWT as a static string would make the MSAL client depend on an assertion that eventually expires. Passing a function lets MSAL ask for an assertion when it actually needs to send a request to the token endpoint.

The resulting chain is:

sequenceDiagram
    participant Agent as Agent CCA
    participant AgentProvider as _agent_assertion()
    participant Blueprint as Blueprint CCA
    participant AwsProvider as _get_blueprint_assertion()
    participant STS as AWS STS

    Agent->>AgentProvider: Request client assertion
    AgentProvider->>Blueprint: Acquire T1 for fmi_path
    Blueprint->>AwsProvider: Request client assertion
    AwsProvider->>STS: GetWebIdentityToken
    STS-->>AwsProvider: Fresh AWS JWT
    AwsProvider-->>Blueprint: AWS client assertion
    Blueprint->>Blueprint: Exchange AWS JWT for T1
    Blueprint-->>AgentProvider: T1
    AgentProvider-->>Agent: T1 client assertion
    Agent->>Agent: Continue OBO request

There is no special MSAL class for "AWS-hosted Agent ID." Both objects are normal confidential clients. Their client_credential configuration delegates assertion acquisition to application code.

The blueprint confidential client application delegates its credential to AWS STS

The blueprint confidential client application (CCA) is created once per process:

_blueprint_app = msal.ConfidentialClientApplication(
    BLUEPRINT_CLIENT_ID,
    client_credential={
        "client_assertion": _get_blueprint_assertion
    },
    authority=AUTHORITY,
)

Notice what is passed as client_assertion. It is the function object _get_blueprint_assertion, not the result of calling that function.

The constructor therefore does not contact AWS STS and does not capture one JWT forever. It stores a callable that can provide the credential later. This extends the generic client_credential assertion mechanism with a provider backed by AWS. In the v2.0 implementation, that provider asks STS for a five-minute assertion:

def _get_blueprint_assertion(*args, **kwargs) -> str:
    response = _ensure_sts_client().get_web_identity_token(
        Audience=[FIC_AUDIENCE],
        SigningAlgorithm="RS256",
        DurationSeconds=300,
    )
    return response["WebIdentityToken"]

MSAL invokes the provider when it needs a client assertion for an Entra token-endpoint request. The application deliberately does not add another cache around the AWS JWT. MSAL caches the Entra token produced by the exchange, while a later token-endpoint request can obtain a fresh AWS assertion.

The *args, **kwargs signature is intentional. The sample tolerates MSAL Python versions that invoke the assertion provider with no arguments and versions that provide assertion context. The provider does not need that context because its issuer, audience, signing algorithm, and lifetime are fixed by the workload-federation configuration.

This is the first delegation point:

When the blueprint client needs to authenticate, delegate credential production to AWS STS.

The blueprint remains the confidential client from Entra's perspective. AWS STS is simply the component that supplies its short-lived proof.

The agent client delegates its assertion to the blueprint client

The second constructor repeats the pattern at the next identity boundary:

_agent_app = msal.ConfidentialClientApplication(
    AGENT_IDENTITY_ID,
    client_credential={
        "client_assertion": _agent_assertion
    },
    authority=AUTHORITY,
)

This client represents the child Agent ID. It cannot ask AWS STS for its client assertion directly because AWS attests to the runtime role, while the Entra FIC is configured on the blueprint. The agent client's assertion must be T1, the token that proves the blueprint-to-agent relationship.

Its provider therefore delegates back to the persistent blueprint client:

def _agent_assertion(*args, **kwargs) -> str:
    blueprint_app = _ensure_blueprint_app()
    t1_result = blueprint_app.acquire_token_for_client(
        scopes=["api://AzureADTokenExchange/.default"],
        fmi_path=AGENT_IDENTITY_ID,
    )
    if "access_token" not in t1_result:
        raise TokenAcquisitionError(
            "FMI Stage 1 failed: {} - {}".format(
                t1_result.get("error"),
                t1_result.get("error_description"),
            )
        )
    return t1_result["access_token"]

The fmi_path value tells Entra which child Agent ID the blueprint is acquiring T1 for. This is the Agent ID-specific extension described in the MSAL team's FIC and FMI agentic-scenario guidance, not an ordinary resource scope or OAuth OBO parameter. If the blueprint CCA must call the token endpoint, it invokes its own _get_blueprint_assertion provider and receives a fresh AWS JWT. _agent_assertion then returns the resulting T1 to the agent CCA.

This is the second delegation point:

When the agent client needs to authenticate, delegate assertion production to the blueprint client.

The two callbacks model the two trust transitions directly in code:

flowchart LR
    OBO["Agent CCA<br/>OBO request"]
    AP["_agent_assertion()"]
    BP["Blueprint CCA<br/>FMI request"]
    AWS["_get_blueprint_assertion()"]
    STS["AWS STS"]

    OBO -->|"needs T1"| AP
    AP --> BP
    BP -->|"needs AWS assertion"| AWS
    AWS --> STS
    STS -->|"AWS JWT"| AWS
    AWS --> BP
    BP -->|"T1"| AP
    AP --> OBO

This is dependency injection applied to client authentication. MSAL owns token acquisition, protocol parameters, and its token cache. The application owns how a valid assertion is produced at each boundary.

Construct once, refresh through the callbacks

Both confidential clients are lazy-initialized singletons in the container process. That is not just a small optimization.

Reusing the blueprint CCA preserves its in-memory cache for T1. Reusing the agent CCA preserves its in-memory cache for downstream user tokens. Constructing either CCA for every request would discard the corresponding cache and force avoidable token-endpoint calls.

The locks around both constructors make the initialization safe when concurrent invocations reach a newly started process:

with _blueprint_lock:
    if _blueprint_app is None:
        _blueprint_app = msal.ConfidentialClientApplication(...)

The inner check matters because another invocation might have initialized the client while the current invocation waited for the lock.

The callbacks do not mean AWS STS is called for every tool call. The normal path is:

try the relevant MSAL cache;
return a usable cached token when one exists;
invoke the assertion provider only when MSAL needs a token-endpoint request; and
let that provider produce a current assertion rather than reuse an expired string.

This is why the constructor wiring is the center of the implementation. The code does not contain a scheduled client-secret rotation job because the credential lifecycle has become part of token acquisition itself.

Assertion delegation is not user delegation

The word "delegation" can hide two different mechanisms in this sample.

The callback functions delegate credential production between Python components. _get_blueprint_assertion supplies the AWS workload assertion, and _agent_assertion supplies T1. No user identity is involved in either callback.

OAuth 2.0 on-behalf-of (OBO) user delegation happens later, when the persistent agent CCA calls:

tr_result = agent_app.acquire_token_on_behalf_of(
    user_assertion=inbound_user_token,
    scopes=scopes,
)

At that point MSAL has two different inputs:

the agent CCA's callable client_assertion, which produces T1 and authenticates the Agent ID; and
user_assertion, which is the inbound user token and carries the delegated user context.

T1 answers, "Which agent is making this request, and may this blueprint act for it?" The user assertion answers, "On behalf of which signed-in user is the agent acting?" The final resource token combines those parts of the flow for the requested downstream scope.

Keeping these inputs separate is what makes the sample useful. The AWS workload assertion is not treated as a user token. T1 is not treated as the downstream access token. The inbound user token is not used as the agent credential. Each assertion has one job.

Exchange the AWS assertion for the blueprint token

Underneath those MSAL constructors, the AgentCore runtime presents the AWS JWT to the Microsoft identity platform token endpoint as a client assertion. This is the client credentials flow with a federated credential, not a custom token format or a vendor-specific backchannel.

For an Agent ID blueprint, the first request also identifies the target agent identity through fmi_path:

POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=<agent-blueprint-client-id>
&scope=api://AzureADTokenExchange/.default
&grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<aws-sts-jwt>
&fmi_path=<agent-identity-client-id>

Microsoft documents the fmi_path parameter as the instruction that tells the blueprint which agent identity it is acting for (Authenticate and acquire tokens for autonomous agents).

If the AWS token's signature is valid and its issuer, subject, and audience match the federated identity credential, Entra returns the blueprint token, often called T1 in the Agent ID flow.

That is where the workload federation step ends.

Continue with the Agent ID token exchange

T1 is not the token the agent sends to Microsoft Graph, an MCP server, or another protected API. The runtime uses T1 as the client assertion in a second request, this time as the agent identity:

POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=<agent-identity-client-id>
&scope=<downstream-resource>/.default
&grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<agent-blueprint-token-T1>

That second request is the documented agent identity token request. The resulting access token represents the Agent ID and is scoped to the downstream resource.

This separation matters operationally:

AWS proves the runtime role to the blueprint.
The blueprint proves its authority to act for the child agent identity.
Microsoft Entra issues a resource-specific token for that agent identity.

Workload identity federation replaces the blueprint credential. It does not flatten the Agent ID parent-child model, bypass consent, or grant the agent new downstream permissions. The agent still needs the appropriate application permissions and administrator authorization described in the autonomous agent authorization flow.

Authentication proves which workload and which agent are involved. Authorization still decides what that agent may do.

What became safer, and what did not

The most visible gain is the removal of a long-lived Entra client secret from the AWS runtime. There is no secret value to copy into deployment configuration, retrieve from a secret store, rotate on a calendar, or accidentally leave valid after the workload changes.

The assertion is also bound to the AWS identity that requested it. Microsoft Entra accepts it because the configured subject identifies the expected IAM role, not because the bearer knows a shared string.

But "secretless" should not be read as "trustless" or "credential-free."

The AgentCore runtime's access to its IAM role is now the root of trust. A process that can run as that role and call GetWebIdentityToken can request the same AWS assertion. The AWS role assignment, its trust policy, the permission to call STS, and the audience and duration conditions therefore need the same review you would give any production identity boundary.

Short-lived tokens also remain bearer material while they are valid. Do not log the AWS assertion, T1, or the final access token. Do not pass them into model context or tool output. Cache them only for their useful lifetime and keep token acquisition in the trusted application layer.

Federation removes an entire secret lifecycle. It does not excuse weak runtime isolation.

Failure modes worth testing

The happy path is short. The useful tests are mostly about proving that the trust is narrow.

Change the audience

Request an AWS token for an audience other than api://AzureADTokenExchange. The Entra exchange should fail because the incoming aud no longer matches the federated identity credential. Audience checking is a required part of the configured trust (Configure an app to trust an external identity provider).

Run under another IAM role

Obtain a valid AWS token as a different role. Signature validation should still succeed, but the token exchange should fail because the sub claim does not match. This test demonstrates the difference between trusting AWS as an issuer and trusting every AWS workload.

Point to another AWS issuer

Use a token from another AWS account's outbound identity issuer. The subject might look familiar, but the iss value will differ. Entra uses the issuer and subject combination to identify the external workload (Configure an app to trust an external identity provider).

Request a permission the agent does not have

Keep the workload federation valid and ask for a downstream scope or application permission that has not been granted. The Agent ID token request should fail independently of AWS authentication. This is evidence that workload authentication has not bypassed the Agent ID authorization model.

Remove `sts:GetWebIdentityToken`

The failure should happen in AWS before any call reaches Microsoft Entra. That gives operators a clean boundary when diagnosing incidents: AWS controls whether the runtime can obtain an assertion, while Entra controls whether that assertion is trusted and what the resulting Agent ID may access.

The configuration is the architecture

The code change in version 2.0 is not large. That is exactly why the configuration deserves attention.

The security properties live in four places:

the IAM role attached to the AgentCore runtime;
the role's permission and conditions for sts:GetWebIdentityToken;
the Entra federated identity credential's exact issuer, subject, and audience; and
the permissions granted to the resulting Agent ID.

Reviewing only the Python token requests misses three of those four boundaries.

The first version asked, "Can an AWS-hosted agent authenticate and authorize as a Microsoft Entra Agent ID?" The answer was yes.

Version 2.0 asks the production question: "Can it do that without distributing a Microsoft credential into AWS?" The answer is also yes.

AWS attests to the workload it runs. Microsoft Entra decides whether to trust that attestation. The Agent ID blueprint then acquires a token for the child agent identity through its established flow.

No shared secret crosses the cloud boundary. Trust does.

References

Your API gateway is not an identity provider, and promoting it to one is a liability

Anton Staykov — Tue, 08 Sep 2026 10:37:00 +0000

Nobody disputes that the API gateway belongs at the center of an enterprise architecture. It is the discovery surface, the throttle, the routing layer, the audit point, and the place where a platform team decouples consumers from the services they consume. That is not the problem.

The problem starts the moment a gateway stops validating tokens and starts issuing them. At that point it is no longer a gateway. It is an identity provider. And in most estates I have looked at, it is not governed, audited, monitored, or operated as one. It is operated as middleware.

So let me put my position at the top rather than build to it. It is not the API gateway's job to be an identity provider. The gateway does discovery, governance, quota, decoupling, routing, and pre-authorization at the edge. It does not mint identity. Everything that follows is a reason why that line exists and an accounting of what it costs to cross it.

This article is a critical review of my own earlier piece, The industry does not have an agent identity propagation standard yet. In that article I drew a cross-provider agent flow, and I drew it clean, because I wanted the propagation problem to be legible. The simplification did its job. It also hid the thing I now think matters most: in a real enterprise topology, the gateway quietly becomes an extra authorization server, and nobody counts it.

Let me be honest about what this is. It is not a migration plan. It is a view, and an attempt to raise awareness of a risk that gets dismissed in design reviews with a shrug and the phrase "that is just how our platform works." I know these are brownfield estates. I know a re-platform does not land in a quarter, or in a year. I also know that most of the decisions that produced this shape were rational at the time they were made, taken by competent people under real constraints. None of that changes what the resulting architecture is. It is a liability, it deserves to be named as one, and naming it is not where the work stops.

So here is the recommendation the rest of this article argues for, stated before the argument. Start consolidating your identity providers now, and keep driving the count down until the gateway is not one of them. That is not a personal preference. Microsoft's CISA Zero Trust Maturity Model guidance for the identity pillar recommends consolidation of identity providers, identity stores, and identity management systems as the way to establish an identity foundation at all, and the enterprise-wide identity management guidance for M-22-09 puts the target plainly: as few managed identity systems as possible, with a consolidation plan behind them. Slow is acceptable. Not started is not.

The words I use are OAuth words

Before the argument, the vocabulary. I am not inventing terms here, and I want the disagreement to be about architecture rather than about definitions.

RFC 6749 section 1.1 defines four roles, and every one of them shows up in this article. The resource owner is the entity capable of granting access to a protected resource, which in this article is Bob. The resource server hosts the protected resource and accepts access tokens. The client is the application making requests on the resource owner's behalf. The authorization server issues tokens after authenticating the resource owner and obtaining authorization. OpenID Connect Core 1.0 sits on top of that as the identity layer, which is how a client learns who Bob actually is rather than merely that some authorization exists.

Four claims carry the whole argument.

sub is the subject, the entity the token is about. RFC 7519 section 4.1.2 defines it as the principal that is the subject of the JWT, and states plainly that the value is only guaranteed to be unique within the issuer's scope. Hold on to that sentence. It becomes the crux of this article.

client_id identifies the client the token was issued to. RFC 8693 section 4.3 defines it as the client identifier of the party to whom the token was issued, and RFC 9068 section 2.2 makes it a required claim in a standards-compliant JWT access token. Microsoft Entra spells the same idea as appid in v1.0 tokens and azp in v2.0 tokens, which the access token claims reference documents alongside the rest of the claim set.

act is the actor. RFC 8693 section 4.1 defines it as the party acting on behalf of the subject, and it nests, so a chain of delegation can be expressed as a chain of act claims.

The rule that follows from those definitions is small, and it is the one people skip. sub answers who authorized this, and the client and actor claims answer who is carrying that authorization. Those are two different questions with two different answers, and an architecture that collapses them into one has stopped being able to answer either.

The gateway's job is governance, not authorization

Start with the version of the world where everything is tidy.

The estate is deliberately small. There is an AI agent. There are two remote MCP servers, A and B. There is a REST API that the agent calls directly through a local tool. There is a single-page application that Bob uses. There is Bob. Behind the MCP servers there are the systems they actually talk to, another REST API and a database. I have left the LLM out of the picture entirely, because the model is not an identity, and the REST API stands in well enough for "a thing the agent calls that has its own access control."

One assumption holds this picture together, and I want it stated rather than implied. In this version, the gateway is not an authorization server. Every resource in the estate is registered with the same identity provider. The gateway sits in the traffic path and does gateway things.

What are gateway things? Discovery, so consumers can find an API without asking a human. Governance, so the platform team can see what is being called and by whom. Quotas and rate limiting, so one badly written client does not take down a shared dependency. Decoupling, so a backend can move without breaking every caller. Routing, transformation, and versioning. The Azure API Management authentication and authorization overview describes exactly this shape of responsibility, and it is a good shape.

Pre-authorization at the edge belongs in that list too. A gateway that checks whether an inbound token is well formed, unexpired, signed by a trusted issuer, and carrying the audience it should be carrying is doing valuable work. The validate-jwt policy is precisely the right shape of control, a cheap early sanity check that rejects obvious garbage before it reaches a backend. I have no argument with any of that.

Here is where I draw the line. It is not the gateway's job to decide whether the SPA may invoke the agent. It is not the gateway's job to decide whether the agent may invoke MCP Server A rather than MCP Server B. Those are authorization decisions about business capability, and they belong to an authorization server that owns the identities and the entitlements involved. A gateway that pre-authorizes is enforcing a decision. A gateway that authorizes is making one, and those are not the same architectural role.

A gateway that issues its own tokens has gone past both. It is not enforcing a decision and it is not making one. It is manufacturing the subject that every downstream decision will be made about. That is the identity provider's job, it is the only job on this page the gateway should not have, and no amount of policy configuration turns it into a gateway concern.

A plausible execution path

Now run a request through it, and count the hops honestly.

Bob signs in to the SPA (1). During that sign-in he also authorizes the SPA to invoke the AI agent on his behalf. He is the resource owner, the SPA is the client, and the agent is a resource he is delegating access to.

Bob types a prompt. The SPA invokes the agent (2), carrying Bob's delegated authorization.

The agent validates the request and builds a plan. The plan has three branches. It calls a local tool that hits a REST API (3). It calls MCP Server A (4), and MCP Server A must in turn call a downstream REST API (5) to do its work. It calls MCP Server B (6), and MCP Server B must run a query against a database (7).

Because the agent is acting on Bob's behalf and not on its own account, Bob's identity has to survive every one of those hops. That is not a nice-to-have. If the downstream REST API at step 5 cannot tell that Bob is the reason it is being called, it cannot apply Bob's entitlements, and the agent has just become a confused deputy with a wider reach than any human user. So Bob must hold entitlements in the agent, in the REST API at step 3, in MCP Server A, in the REST API at step 5, in MCP Server B, and in the database at step 7.

The MCP hops are not a matter of preference. The MCP authorization specification treats MCP servers as OAuth 2.1 resource servers and states that a server MUST NOT pass through the token it received to an upstream service. Each hop is a fresh authorization decision by design, and the spec is right to require it. Token pass-through destroys audience binding and turns every server in the chain into an amplifier for whatever token happens to arrive.

I want to be clear that this is not a contrived example built to make a point. It is the ordinary shape of agentic work. An agent that cannot call more than one tool, or whose tools never call anything themselves, is a demo. Anything doing real work in an enterprise looks like this or worse, and "worse" usually means more hops, more providers, and more places where the chain is only as strong as the weakest assertion in it.

In the ideal world, one authorization server sees all seven token requests

Suppose the estate is greenfield and someone with authority made the obvious call: everything registers with one authorization server. Bob exists there as a user. The SPA is registered there as a client. The agent has its own identity there, distinct from Bob's. The REST APIs, both MCP servers, and the database all register there as resource servers with their own scopes.

Seven token requests, and every one of them is an entitlement question with an answer.

The SPA authenticates Bob. Bob needs an entitlement to use the SPA at all.
The SPA obtains delegated authorization to invoke the agent. Bob needs an entitlement to the agent, and the SPA needs to be authorized to ask for it on his behalf.
The agent obtains a token for the REST API. Bob needs an entitlement in that API, and the agent needs to be permitted to request it.
The agent obtains a delegated token for MCP Server A.
MCP Server A obtains a token for the downstream REST API on Bob's behalf. Both MCP Server A and Bob need entitlements there, and they are separate checks.
The agent obtains a delegated token for MCP Server B.
MCP Server B obtains a token for the database on Bob's behalf, with the same double check.

This pattern has a name, and the standards already carry language for it. RFC 8693 section 1.1 distinguishes delegation, where the acting party is given permission to act on the subject's behalf and both parties stay visible in the token, from impersonation, where the acting party disappears and the resource server cannot tell the difference. Microsoft's on-behalf-of flow is the same idea with a vendor implementation attached.

Now count how many times Bob appears as sub in that chain. Seven times, issued by one issuer, with one meaning. There is one policy engine, one place where entitlements live, one enforcement surface, and therefore exactly one place where the entire chain can be denied. Revoke Bob at the authorization server and every hop downstream loses its footing on the next token request. Investigate an incident and there is one issuance log to correlate against.

One authorization server, all resources registered with it, one policy engine. Almost nobody reading this is standing there today, and I am not pretending otherwise. It remains the direction every estate should be actively moving in, and the distance from it is a number you should be able to say out loud: how many authorization servers issue tokens your systems will accept, and which of them has an owner and a retirement date. Microsoft's guidance on migrating apps and authentication to Microsoft Entra ID exists because that consolidation is a program of work rather than a configuration change. Programs of work have to be started before they can finish.

The real world runs four authorization servers, not three

The first reality is that you do not have one identity provider. You have several, with users in some of them, resources in others, and a partial overlap that nobody has fully mapped. And I do not mean the tidy split people reach for first, the on-premises directory alongside the cloud directory with a sync between them. That one at least has a documented relationship and an owner. I mean the genuine fragmentation: an acquired business unit with its own tenant, a SaaS platform with its own embedded authorization server, a legacy estate fronted by a federation product that predates everyone currently on the team, and a partner integration that authenticates against something nobody has permission to change.

Every one of those has a story attached, and most of the stories are true. None of them makes the shape permanent. The number of identity providers in an estate is a design choice that got made incrementally, one acquisition and one integration at a time, and it comes back down the same way. Treat that number as a metric with an owner, not as weather.

The second reality is what teams did about it. To hide that fragmentation from application developers, they made the gateway an authorization server. Not as an act of vandalism, and not against the documentation either. Fronting a backend with the gateway as the token audience is a supported, documented pattern, and the APIM authentication and authorization overview covers scenarios in exactly that family. It works. It ships. It removes a class of problem from every application team at once, which is why it wins the design review.

Walk the same flow through that topology.

Step 1. Bob signs in to the SPA against IDP 0. So far, unchanged.

Step 2. The agent is not directly reachable. It sits behind the gateway. So the resource server registered in IDP 0 is not the agent, it is the gateway. The SPA requests a token to invoke "something in the gateway," and IDP 0 has no opinion about which something, because the gateway is a single registered audience covering many backends.

Step 2.1. This is the step that does not appear in anybody's architecture diagram, and it is the reason I am writing this. The gateway validates the incoming token from IDP 0, runs its own policy, and then issues its own token from its own security token service. From here inward, the estate no longer runs on IDP 0 tokens. It runs on gateway tokens.

Step 3 is skipped here on purpose. I am keeping the numbering aligned with the ideal-world walkthrough so the two can be compared line by line, and the direct REST API call adds nothing that the MCP branches do not already show.

Step 4. The agent is now free of external authorization servers, which was the entire selling point. It validates a gateway STS token and calls MCP Server A through the gateway. Clean, simple, and completely dependent on the gateway being right.

Step 5. MCP Server A has to call a REST API that does not trust IDP 0 or the gateway. It trusts IDP 1. So MCP Server A registers as a client in IDP 1 and requests a token there. And that request has to assert three things at once: that Bob exists in IDP 1, that this Bob is the same Bob who signed in to IDP 0 at step 1, and that he holds entitlements in that REST API. Three assertions, and only the third is a normal authorization check.

Steps 6 and 7. The same again, with MCP Server B, IDP 2, and the database behind it. Another registration, another mapping, another set of three assertions.

Count the authorization servers in that picture. IDP 0, IDP 1, IDP 2, and the gateway's own STS. Four. Ask an architect how many identity providers are in the flow and you will usually be told three, because the fourth one is drawn as a rectangle with a networking icon on it.

There are two places inside the gateway where Bob changes identity

This is the part I want people to sit with.

At step 2.1, Bob's authorization from IDP 0 becomes "Bob's" authorization from the gateway STS. At step 5, that gateway assertion becomes the basis for asserting Bob in IDP 1. Two translations, neither of them visible in the request path, neither of them producing an artifact that an auditor would recognize as an identity event.

flowchart LR
    Bob["Bob<br/>IDP 0"]
    SPA["SPA"]
    GW["API<br/>gateway"]
    Agent["Agent"]
    MCPA["MCP<br/>Server A"]
    API["REST API<br/>trusts IDP 1"]

    Bob -->|"1. sign-in<br/>delegates<br/>to SPA"| SPA
    SPA -->|"2. token<br/>iss: IDP 0<br/>aud: gateway"| GW
    GW -->|"TRANSLATION 1<br/>step 2.1<br/>gateway STS<br/>mints Bob"| Agent
    Agent -->|"4. routed<br/>via gateway"| MCPA
    MCPA -->|"TRANSLATION 2<br/>step 5<br/>asserts Bob<br/>into IDP 1"| API

    linkStyle 2 stroke:#d62728,stroke-width:3px
    linkStyle 4 stroke:#d62728,stroke-width:3px

Remember what RFC 7519 section 4.1.2 actually says about sub. The value is unique within the issuer's scope. Not globally. Not across your estate. Within the issuer. So when the gateway STS emits a token whose sub reads like Bob, that value means whatever the gateway says it means, and when MCP Server A turns that into an IDP 1 assertion, the identity has been through two mappings that no standard is validating for you.

The consequence is one sentence long. Whoever controls the gateway decides who Bob is.

Two questions follow, and in every estate where I have asked them, neither has had a satisfying answer. First, how do you trace that the Bob who signed in at step 1 is the Bob whose entitlements were used at step 5? The correlation exists, if it exists at all, in gateway policy configuration and gateway logs, which are owned by a different team than the one that owns the identity logs. Second, if Bob at step 1 is compromised, what locks down Bob at step 5? Disabling the account in IDP 0 stops new sign-ins. It does not tell the gateway STS to stop minting, and it does not tell IDP 1 anything at all, because IDP 1 was never told that its Bob and IDP 0's Bob were related.

Compare that with what the standards are actually asking for. RFC 8707 resource indicators exists so a client can name the resource it wants a token for, and so the authorization server can bind the token to that audience. The MCP security best practices require a server to reject any token that was not issued for it, and name the confused deputy problem explicitly. Both controls point the same direction: narrow the audience, keep the issuer meaningful, refuse tokens minted for somebody else. A gateway that re-mints identity at the edge is doing the opposite of audience binding. It is deliberately widening the audience so that everything behind it can stop caring.

So here is the position, and I hold it without qualification. In trying to make things simpler behind the gateway, the industry made them worse, because it pushed the gateway into acting as an identity provider without ever admitting that is what happened. The simplicity is real. It was purchased with a trust anchor, and the invoice has not been read. A gateway that mints identity is not a pragmatic shortcut with a documentation page behind it. It is an unowned authorization server sitting in the middle of your estate, and it should not be there.

Four policy engines is a liability, and it should be called one

I will concede the same ground twice, because it is fair ground. These are brownfield systems. They carry years of integrations, contracts, and behavior that nobody has fully documented. The gateway STS does not come out next sprint, and I am not asking anyone to pretend otherwise.

The concession explains why this is hard. It does not excuse leaving it alone. Two things have to happen, and they run in parallel rather than in sequence. The first is naming the liability, because the first control you apply to a liability is writing its real name into a register that somebody reviews. The second is reducing the number of authorization servers in the estate on a schedule that has an owner, starting with the one that was never classified as an authorization server in the first place.

Four authorization servers means four policy engines. Four places where entitlements are managed, with four different models for expressing them. Four places where human and non-human identities are provisioned and deprovisioned, with four different joiner, mover, leaver processes, one of which is a configuration file. Four places where a broad and fragile trust relationship gets created, and only three of them will show up in an identity governance review.

The ownership asymmetry is the part that should worry you most. The gateway belongs to the application platform team. It does not belong to security, and it very rarely belongs to IAM. So the controls that IDP 0, IDP 1, and IDP 2 are subject to, privileged access review, signing key custody and rotation, conditional access on administrative operations, change approval on trust configuration, alerting on issuance policy changes, are simply not applied to the fourth authorization server. Not because anyone decided to exempt it. Because nobody classified it as one.

Now look at it the way an adversary does. IDP 1 gets you the users and resources in IDP 1. The gateway STS gets you an assertion that IDP 1 will accept, an assertion that IDP 2 will accept, and an assertion that every service behind the gateway will accept without further question. To an attacker, that gateway is worth more than IDP 1. It is also patched on an application team's schedule, monitored with application telemetry, and administered by people whose access was never reviewed as identity provider access, because on the asset inventory it is middleware.

RFC 8693 does not fix a broken trust anchor

Whenever I make this argument, somebody reaches for token exchange, so let me address it directly rather than leave it sitting as an unstated rebuttal.

RFC 8693 is a good specification and I am not arguing against using it. It gives you a real protocol for a security token service: a subject_token describing the party on whose behalf the request is made, an optional actor_token describing the party doing the acting, and a token type system that lets you convert between formats deliberately instead of by convention. It gives you the act claim as a nested, inspectable delegation history, so a resource server can see the whole chain rather than a flattened identity. It even gives you may_act, a claim stating which party is authorized to become the actor for a subject, which is genuinely the right primitive for constraining delegation.

Here is what it does not give you: a reason to believe the mapping. RFC 8693 supplies mechanics for exchanging one token for another. It explicitly places the trust model and the policy governing exchanges outside its scope, and it imposes no requirements on how a deployment decides that this subject in this issuer corresponds to that subject in that issuer. That decision is yours. In the architecture above, the answer to "why should IDP 1 believe this is Bob" is that somebody configured a mapping in the gateway's STS, carefully, once, some time ago, and it has been correct ever since as far as anyone knows.

The specification is candid about where that leads. It warns that when an authorization server does not authenticate the client in a token exchange, a compromised or leaked token can be leveraged through the STS into other tokens, and it tells you to require client authentication and to constrain who may exchange what. Apply that warning to a gateway STS that fronts an entire estate and the exposure takes an obvious shape. Control the gateway STS, or control anything that can persuade it to mint, and you can obtain a token for any user in any provider that trusts it. Not through a vulnerability. Through the feature.

So the closing rule is the one I would defend in any design review. Token exchange is a mechanism for propagating identity. It is not a mechanism for establishing who is allowed to assert it. The propagation problem is largely solved, and the standards are in decent shape. The assertion problem is the one your architecture answered by accident.

Which brings me back to where I started, and I will state it once more without softening it. It is not the API gateway's job to be an identity provider. Discovery, governance, quotas, decoupling, routing, versioning, and pre-authorization at the edge are the gateway's work, and a good gateway is genuinely excellent at all of it. Minting the subject that the rest of the estate authorizes against was never on that list and should not have been added to it.

Two actions follow, and they are not alternatives to each other.

Start the first one this quarter. If the gateway is asserting identity today, govern it as an identity provider, because the only other option available right now is an ungoverned one. Put it in the identity asset inventory. Review its administrators as privileged identity administrators. Rotate and custody its signing keys the way you custody an identity provider's. Put change approval on its trust configuration and alerting on its issuance policy. Feed its issuance logs into the same correlation surface as every other issuer, so a chain from step 1 to step 5 can actually be reconstructed.

Then fund the second one. Count the authorization servers your estate trusts, put a name and a date against each one you intend to retire, and drive that number down until the gateway is out of the identity business entirely and back to being the very good gateway it already is. That work is slow, it is unglamorous, and it will outlast several reorganizations. Start it anyway, because the count does not fall on its own.

And hold the line on new build while you do it. Nothing greenfield gets to add another authorization server, and nothing new gets fronted by a gateway that mints its own tokens. If you will not govern the gateway as an identity provider, do not let it assert identity.

References

AI agents need an authorization domain beyond OAuth

Anton Staykov — Thu, 03 Sep 2026 10:03:00 +0000

OAuth 2.0 is not broken because an AI agent uses it. It remains the right protocol family for issuing and presenting access tokens, expressing delegation, and binding a client to an authorization transaction. RFC 9700 still recommends restricted tokens, audience checks, and sender constraints where applicable. That is not the problem.

The problem is the quiet assumption that a valid token and a permitted API operation fully answer whether an agent should perform a particular consequential action now. An agent can turn one user request into a chain of tool calls, select values that the user did not enumerate, and reach a side effect that no scope string can describe by itself. A valid grant is not a standing instruction to proceed.

The industry needs a distinct agent-authorization domain between token issuance and the business operation. It combines the authorization server's proof of grant and delegation, a fine-grained policy engine's model of principal-action-resource semantics, and a context- and risk-driven decision engine. The resource still enforces the result. No one component should impersonate all the others.

This is also where a future interoperability standard could matter. It would give security teams, agent developers, and application operators one plane for describing an action, carrying an evaluated disposition, and proving what the PEP enforced. Without a shared direction, each vendor will define agent authorization semantics differently. The result is fragmented controls, inconsistent decisions across tool boundaries, and complexity that does not improve the transaction. This is a proposed future direction, not an existing standard.

OAuth proves a grant, not the meaning of an agent transaction

OAuth defines the roles that matter here: an authorization server issues access tokens after a grant, and a resource server accepts a token to protect a resource. RFC 6749 deliberately leaves the resource owner, client, authorization server, and resource server with separate responsibilities. That separation remains valuable when the client happens to be an agent.

A protected API must validate a token intended for it before using it as proof of authorization. Microsoft's access-token guidance is equally clear that the API owns token validation and that clients should treat access tokens as opaque. OAuth security guidance also says tokens should be restricted to the minimum privileges, resources, and actions required, with resource servers enforcing those restrictions for every request. RFC 9700 defines that as a core best practice.

That is standardized token and delegation mechanics. It does not supply a universal semantic model for questions such as: Is this payroll export for an approved case? Is the new payee related to the current supplier? Has this agent already attempted the same action through another tool? Should a proposed bulk deletion be staged rather than committed? Those are business- and transaction-specific questions. They require data the authorization server neither owns nor should be expected to infer.

OAuth Rich Authorization Requests is a useful bridge, not the destination. authorization_details lets a client request structured authorization data that an authorization server and protected resource can interpret, including resource, action, and transaction attributes. RFC 9396 gives the protected API and authorization server that shared vocabulary. It does not turn a bearer or sender-constrained token into a live model of an agent's tool chain, business purpose, or current risk evidence. Use OAuth to establish the authorized envelope. Do not turn the token into a mutable risk dossier.

Fine-grained policy gives the transaction its business meaning

An agent-authorization domain needs a policy decision point that understands the action as the business sees it, rather than only as an HTTP method against a route. Cedar is one example: its policies evaluate a principal, action, resource, entity attributes, and transient request context. Cedar's language documentation describes this model and its separation of policy from application code. Similar fine-grained authorization systems can fill the same role.

That distinction matters because POST /vendors/88421 is not a useful authorization verb. vendor.bank-account.change is. It can have a resource owner, a value change, a financial consequence, a required approver, and a rule that applies to this action but not to a vendor-address correction. The policy layer answers whether the authenticated agent, acting within a valid delegated or application grant, may propose this precise action on this precise resource.

The policy decision point must receive trustworthy attributes, not a bag of agent-generated labels. The resource owner supplies canonical resource attributes. The workflow supplies the operation and the proposed effect. The identity layer supplies validated principal and grant attributes. The agent can supply a declared purpose, but a policy should treat that as an assertion until an authoritative workflow record corroborates it. The agent may describe intent. The authorization domain decides which facts are authoritative.

validated identity and grant     canonical business data
             |                            |
             v                            v
      authorization server --> policy decision point
                                      |
agent tool plan and request context ---+--> policy result: permitted or denied

The Agent Governance Toolkit architecture is a concrete application-layer reference architecture for this enforcement shape. It evaluates agent actions against policy before execution and separates policy, identity and trust, runtime controls, tool-call interception, and audit components. That makes it useful implementation evidence for putting a governance gate before an agent action. It is not a platform-neutral authorization protocol, and its component specifications and conformance tests describe the toolkit's own architecture rather than a shared interoperability contract. Reference architectures can prove an enforcement pattern. They do not, by themselves, standardize the decision exchange between systems.

This is already more precise than broad scopes. It is still not the complete decision for an autonomous actor, because permission semantics do not determine whether the current circumstances make execution acceptable.

Static policy needs bounded intelligent judgment for changing context

Static policies remain necessary deterministic guardrails. They define non-negotiable constraints: which principals may act, which business actions are categorically prohibited, which resources require an approval, and which conditions must always deny or stage an effect. Cedar, for example, evaluates explicit principal, action, resource, attribute, and request-context inputs against authored policies. Its language documentation describes that decision model. An adaptive system may not weaken a hard policy constraint.

Static policies alone cannot safely resolve every agent-authorization question. An autonomous actor encounters changing, incomplete, and cross-domain context that a policy author cannot enumerate exhaustively in advance. A bounded intelligent decision system can synthesize that evidence and propose, or make, a transaction decision only within an explicit authority envelope. The resource PEP must enforce that envelope, log the evidence and outcome, and reject decisions that are expired, unbound to the proposed effect, or outside its authority. The system must be tested and evaluated for its intended decisions, with human escalation for consequential or ambiguous cases. NIST's AI Risk Management Framework provides voluntary guidance for governing and evaluating AI systems, not an authorization protocol. Adaptive judgment can operate inside policy. It cannot replace policy ownership or resource enforcement.

The third component is therefore a context- and risk-driven decision engine. It evaluates signals that are time-bound, cumulative, or external to the grant: the sensitivity and volume of data, destination reputation, a sequence of failed attempts, an unusual operation rate, an open investigation, or a human approval that has expired. The engine returns a bounded disposition for this transaction. It does not mint access tokens, reinterpret OAuth grants, silently rewrite authorization policy, or become the policy owner for every resource.

This boundary is particularly important for insider risk. Microsoft Purview Insider Risk Management correlates service and third-party indicators to identify potentially malicious or inadvertent activity, then routes evidence through alerts, triage, investigation, and action. Its documented workflow is an investigative and response system, not a generic inline API authorization server. The Risky Agents template detects signals including risky prompts, sensitive responses, access to sensitive or priority SharePoint files, risky websites, external sharing, and activity above an agent baseline for supported agent platforms. The policy-template documentation defines that scope.

Those signals are useful evidence. They are not enough, by themselves, to dictate every API outcome. A risk system may know an agent's activity is unusual; the resource owner knows whether this operation changes a bank account, publishes a document, or merely reads a record. Risk supplies a disposition. The business policy supplies the meaning.

Agent proposes a business action
             |
             +--> authorization server: is the grant and delegation valid?
             |
             +--> policy decision point: may this principal propose this action on this resource?
             |
             +--> risk context engine: should this transaction proceed, hold, or require review now?
             |
             +--> resource policy enforcement point: commit, deny, hold, or escalate

The resource or application policy enforcement point (PEP) owns the final side effect because it owns the target state. This placement avoids asking an authorization server to understand every business transaction and avoids asking an insider-risk program to become an unbounded authorization service.

A proposed decision contract must bind decisions to the proposed effect

An agent-authorization decision cannot be allow in the abstract. A proposed future decision contract must bind to the proposed effect, the relevant version of policy, the evaluated context, and a short validity period. Otherwise, an agent can obtain a decision for a harmless request and reuse it for a different one.

Consider a procurement agent that receives a valid delegated grant to update supplier records. It proposes changing supplier 88421 from one bank account to another. The policy engine verifies that the agent is allowed to propose this kind of change for that supplier. The risk engine sees that the destination account is new, the amount of pending payments is material, and the agent has already attempted a similar change through a second workflow. The PEP stages the update rather than committing it.

{
  "transaction_id": "6bfbdbd2-0f82-4b44-a27a-e1d939bc0d38",
  "subject": "agent:vendor-onboarding",
  "action": "vendor.bank-account.change",
  "resource": "vendor:88421",
  "proposed_effect_hash": "sha256:4d2c...",
  "policy": { "decision": "permit", "policy_version": "vendor-change-v3" },
  "risk": {
    "disposition": "hold",
    "reason_codes": ["NEW_DESTINATION", "DUPLICATE_ATTEMPT"],
    "expires_at": "2026-09-01T14:20:00Z"
  },
  "enforcement": { "outcome": "staged", "required_approver": "finance-controller" }
}

The hash stands for a normalized representation of the proposed change, not a raw prompt. The PEP must recompute it before committing, reject an expired disposition, and record the policy and risk versions it relied on. This is ordinary transaction integrity applied to an agent decision, not a new claim about what OAuth tokens contain.

allow, deny, hold, and escalate are more useful than a single numerical score. allow permits the PEP to perform the already-authorized operation. deny prevents it. hold preserves a resumable state without the external side effect. escalate routes a specifically described proposed effect to a named approver or workflow. This vocabulary is an example of a proposed product contract, not a standard. Any such contract must be deterministic enough to test and audit. A risk score is evidence. A disposition is an enforceable decision.

Delegation does not erase the human authority boundary

Delegated authority is paramount when an agent operates in a human account context or on behalf of a human. OAuth defines the resource owner as the entity capable of granting access and models the client as a separate role. RFC 6749 preserves that distinction even when the client acts with a delegated grant. The agent may execute within that grant. It does not become the human principal, nor does an earlier authorization settle every later consequential choice.

Long-running operations make the boundary visible. An agent can collect evidence, coordinate tools, and reach a decision point hours after the human's initiating instruction. A future architecture should define a human-authority backchannel through which the agent can present the exact proposed effect, receive an approval, rejection, clarification, or cancellation, and bind that response to the transaction before the PEP commits.

The backchannel must be independent of agent-generated prose. The PEP or workflow service should construct the request from canonical action, resource, effect, deadline, and consequence data, then record the human response with the transaction. A chat message that says "looks good" is not enough unless the system can bind it to one immutable proposed effect. Delegated execution is not delegated sovereignty. The human retains authority over the consequential commitment.

Start with transactions that have a reversible boundary

The sharp edge is timing. An asynchronous investigation system cannot safely become an inline decision point unless its latency, availability, freshness, and failure behavior are explicitly engineered for that job. Purview's documented workflow moves from policy matches to alerts, reviewer triage, cases, and actions. Microsoft's workflow documentation supports a different operational purpose from a low-latency PEP call.

Begin where the application has a natural pending state. A customer-export agent can assemble the candidate set, evaluate sensitivity labels and destination, then hold the delivery link until a data owner approves. A knowledge-management agent can stage an external publication or bulk deletion and submit the exact diff for review. A payments agent can save a proposed bank-account change while preventing release of pending payments until the required approval arrives. For long-running delegated work, this pending state is the practical location for a proposed human-authority backchannel.

authorize grant -> evaluate business policy -> evaluate risk context
       -> stage proposed effect -> approve or reject -> commit once

This design creates a real control point before the state change. Trying to reverse an external email, payment, or published document after an alert appears is incident response, not authorization. The PEP is the last trustworthy place to stop a consequential transaction.

Record observed facts, not an invented provenance story

Every agent transaction needs a durable record at the PEP. It should identify the authenticated agent principal, validated grant reference, initiating workflow or user context when observed, action, resource, proposed-effect hash, policy result, risk disposition, enforcement outcome, and correlation identifiers. That lets an investigation connect agent traces, authorization events, application telemetry, and a case without claiming that an access token proves who authored every intermediate model decision.

The privacy boundary belongs in the design, not the postmortem. Purview describes privacy-by-design controls including default pseudonymization, role-based access control, and audit logs. Microsoft's overview documents those safeguards. An agent-authorization record should minimize sensitive context, separate access to raw content from access to decision metadata, and retain each according to a documented purpose and schedule. Observability is not permission to copy every prompt into every audit system.

NIST's AI Risk Management Framework is voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. NIST AI RMF is useful here as a governance frame, but it does not substitute for a transaction protocol or a resource-specific enforcement decision. Risk governance and agent authorization must meet at the operation, where both can be made concrete.

Do not make the authorization server carry the whole system

It is tempting to solve the agent problem by packing richer claims into tokens or by making the authorization server query every risk source. That centralizes business semantics, changing risk data, and resource-specific side-effect knowledge in a component that cannot reliably own them. The result is either a fragile token schema or a shadow business-policy engine hidden behind token issuance.

Keep the four responsibilities legible. The authorization server establishes a valid grant and delegation boundary. Static policy defines deterministic, non-negotiable constraints for the named principal, business action, and resource. The bounded context and risk engine synthesizes admissible evidence into a time-bound disposition inside its explicit authority envelope. The PEP binds those outcomes to the proposed effect, enforces the envelope, records the decision, and controls the commit.

That is the proposed evolution. Current authorization standards and static policies remain necessary, and fine-grained authorization frameworks already solve a meaningful part of the semantic problem. The additional requirement is a bounded intelligent decision capability for context that is changing, incomplete, or spread across domains, with testing, logging, resource enforcement, and a human backchannel for consequential or ambiguous commitments. A future interoperability standard could define common decision and evidence exchanges while preserving resource-specific policy, the authority envelope, and the human authority boundary. This is an architectural argument, not a claim that a standard already defines it.

References

Authorization options for your AI agents with Entra Agent ID

Anton Staykov — Thu, 27 Aug 2026 09:43:00 +0000

Authorization in Entra has changed, and most of that change is not visible in the product UI. The boundaries have always been there; they are just no longer optional side-quests. When you architect an Entra Agent ID, you are not choosing one authorization mechanism. You are composing five of them, each with its own trust surface. Understanding that composition is the difference between a loosely guarded identity and one that respects the principle of least privilege.

Consent is authorization, not authentication. But consent is only the start. After you have granted the app permission to call Microsoft Graph, the hard work is to ensure it calls Graph with the minimum scope it actually needs, at the exact moment it needs it, and only on behalf of the principals you intended. That is what this article addresses.

User assignment as your outermost gate

User assignment is the first boundary you should establish. It is blunt, but it is not optional. When you require user or group assignment to an enterprise application, you are saying: "Only the principals I explicitly list in this Entra app object can even attempt to authenticate to this workload."

For user-facing applications, this is straightforward. You assign Alice and Bob to the app, and only Alice and Bob can sign in.

For an AI agent, user assignment works similarly. You do not assign the agent's identity to an app. Instead, you assign the users who are allowed to delegate to or authenticate to the agent. In other words that assignment controls which users can invoke the agent or have the agent act on their behalf.

Here is the critical part: user assignment gates access at two levels. First, it controls which users can authenticate to the agent itself. Second, and less obvious, it also gates downstream resource access. If a user is not explicitly assigned to a downstream API or resource, the agent cannot access that resource on behalf of that user—even if the agent's identity is assigned to that API. User assignment is not negotiable at any layer of the call chain.

If you do not require assignment, Entra will still respect the OAuth 2.0 consent framework. However, it will allow any user in your tenant (or any user in a federated tenant, if you have configured cross-tenant access) to attempt authentication. The app sees the request, asks for consent, the user grants it (or the admin pre-consents), and the app gets a token. User assignment closes that loophole. It says: "No request reaches this workload unless the requester is already in my approved list—and no downstream resource request on behalf of that user will succeed if the user is not approved there either."

For AI agents deployed at scale across teams or business units, user assignment is your guard rail. Without it, you are depending on the app and downstream APIs to reject requests from unknown principals. The better defense is to never admit an unapproved principal to the conversation in the first place, and to enforce that control consistently across all resources the agent might access.

Important: User assignment requirement works for both Agent Identity Blueprints and individual agent identities. However, there is currently no Entra Admin Center UX that exposes user assignment functionality — only the Microsoft Graph API. For practical user assignment at scale, consider using Access Packages to facilitate and manage user assignments for AI agents. Another limitation worth mentioning is that at time of writing of this article, only Agent Identity Blueprints support custom roles definitions.

Conditional access as authorization policy

Conditional access is a policy engine that controls token acquisition. Unlike app roles or group claims, which are attributes embedded in a token, conditional access is evaluated before the token is issued. If a policy is violated, the agent does not get a token.

Here are concrete examples of conditional access for AI agents:

Custom Security Attribute filters: "If the app is tagged with Agents.Approved:True then allow access." The agent cannot acquire a token unless it is tagged as approved.
Risk-based controls: "If Entra's identity protection detects a risky sign-in pattern, require additional verification or deny access." In on-behalf-of type of acces, the user's authentication context and user's offline calculated risks are evaluated (unusual location, impossible travel, leaked credentials, etc.), and access is blocked if that evaluation crosses threshold. In autonomous agent access the agent's risk is evaluated and access is blocked if agent's risk crosses defined threshold.
Device compliance: "The device must be compliant with Intune policies." If the user is invoking the AI Agents from a device that is not enrolled or is marked non-compliant, the request is blocked.

Conditional access distinguishes two data access patterns that are critical for AI agents:

Autonomous access: The agent acts on its own behalf (application flow). Conditional access evaluates the agent's context (where it is running, what device it is on, what time it is).
On-behalf-of (OBO) user access: The agent acts on behalf of a user. Conditional access evaluates the user's context (where the user is, their device, their authentication method), not the agent's context.

Critical limitation: At the time of writing, Conditional Access accounts for the User (subject) and Target (resource), but not the AI Agent (actor) - when the agents accesses data on-behalf-of the user. This means CA policies cannot directly distinguish between two different agents making requests in the same context - the same user is invoking two different agents, and both happen to require a token to access Work IQ, the conditional access sees these requests identically.

See Conditional Access for Agents in Microsoft Entra and Recommended policies for autonomous agents for detailed policy patterns.

The sharp edge is timing. Conditional access gates token acquisition. If your agent acquires a long-lived token and then starts running outside the approved perimeter, the existing token still works. Conditional access is a gate at the door, not a checkpoint at every step. If you need continuous context verification, you need a different mechanism.

App roles as delegated authorization claims

App roles are a mechanism for the application, or the AI agent, to define its own authorization model. You define a set of roles in your app registration (or Agent Identity Blueprint). You assign users, groups, or service principals to those roles. When the principal authenticates, Entra puts the role membership in the roles claim of the ID token (or the access token, depending on how you configure the app).

For a human-facing app, this is straightforward. Your app checks: "Is the user in the Manager role? If yes, show the budget page. If no, hide it." Entra does the assignment; your app does the enforcement.

For an AI agent, the model is the same. You can assign humen to a role defined by the Agent Blueprint. In this case, your AI Agent can take authorization decisions for what funcitonality should be avialable to the user. Or, in case of the autonomous agent, you assign the agent's identity to a role defined by downstream API. Then, when your agent acquires a token on behalf of itself (application flow), that token contains the roles assigned to the service principal. Your APIs can inspect the token and make authorization decisions.

Here is an example. You have an agent that needs to read data from one API and another agent that needs to read and write. You define two app roles in the API app registration: DataReader and DataWriter. You assign the read-only agent's service principal to the DataReader role. You assign the read-write agent to the DataWriter role. When each agent calls your API, your API code checks the roles claim. If the token does not include DataWriter, the write operation fails.

Current UX limitations: The Entra Admin Center does not directly expose a UI for defining roles on Agent Identity Blueprints. Roles can be defined and managed via the app manifest. Role assignment to users and groups can be done via the Microsoft Graph API or, more scalably, via Access Packages.

Important distinction: While the "require user assignment" property exists for Agent Identities, there is no real application scenario where interactive authentication to an Agent happens outside of the Agent Identity Blueprint. The Agent Identity Blueprint is the object that defines the authentication and authorization contract for interactive authentications. The way to add role assignments for an Agent Identity Blueprint is via Access Packages (Add Applications). Requiring explicit role assignment for individual agent identities makes sense in an autonomous agent-to-agent interactions where you want strict controls over the autonomous invokation of AI Agents.

App-only roles: App-only roles are defined on the Blueprint and can be assigned to other agents or clients. When assigned to other workloads, these roles appear in the access token with the Blueprint as the audience (aud claim). This allows fine-grained authorization delegation between agents.

The important detail is that your protected API must be configured to emit roles in the access token. This requires a specific configuration step. Many teams forget it. The app roles exist, the assignment exists, but the token arrives empty because the app registration does not emit roles into tokens meant for APIs.

Also note: app roles are defined per app registration, not globally. If you have two APIs, each needs its own set of roles. There is no central app role store.

Group membership claims as attribute-based gates

Group membership claims are different from app roles. When you emit group claims, Entra places the groups that the principal belongs to directly into the token.

Here is the distinction. App roles are defined by the application and assigned by Entra admins within the scope of that app registration. Group claims are based on the broader Entra directory. The principal is a member of the group regardless of the app. The app just asks: "What groups is this principal a member of?" Entra answers by listing them in the token.

This is useful for attribute-based access control (ABAC). Imagine your organization has groups like Sales-Americas, Sales-EMEA, Engineering, and Finance. You assign users and workload identities to these groups. Your API receives a token, extracts the groups claim, and makes decisions based on group membership. "If the token contains the Sales-Americas group, grant access to the Americas sales data. Otherwise, deny."

The value of group-based authorization is that it decouples application-specific roles from organizational structure. If you need to add a new group or restructure existing groups, you do not need to change app role definitions. You adjust group membership. The group claim mechanism is still sending the data; your API just interprets it differently.

There is a configuration step here too. You must tell Entra to emit group claims into tokens for a specific app. By default, groups are not included. Once enabled, Entra sends the group IDs (and optionally display names, but prefer IDs for immutability).

Important: Overage limits and scope configuration. When you enable group claims, you must configure scope carefully. Entra has fixed limits on how many group claims can fit in a token:

OIDC (OpenID Connect): 200 groups maximum
SAML: 150 groups maximum

If a principal belongs to more groups than the limit, Entra sends an "overage claim" instead of individual group IDs. Your API then needs to call Microsoft Graph to fetch the full list. This adds latency and complexity. To avoid overage, emit only "assigned groups" (groups explicitly assigned to the application / blueprint). Be explicit about which groups matter for authorization decisions, and assign only those groups to the target app or agent identity blueprint. This keeps tokens small, predictable, and avoids the overage claim penalty.

See Configure group claims and app roles in tokens for detailed guidance on group claim scope and immutable identifiers.

Access packages as the unified control plane

Access packages are where the other mechanisms converge. An access package is not just governance UI. It is programmable policy choreography. When you assign a principal to an access package, you can configure what happens automatically: group membership additions, app role assignments, Azure role assignments, and so on. All of it coordinated, all of it time-bounded, all of it auditable.

For an AI agent, access packages are a control plane. You define an access package called "Agent-Production-Access". When you assign an agent's service principal to that package, Entra automatically adds the service principal to the groups that the agent needs, assigns the correct app roles to the agent, and even delegated permissions grants (consent) for downstream APIs and MCP Servers. When the access expires, all of it unwinds. The groups are removed. The app roles are stripped, the consent is undone. The agent loses access.

This is different from manually assigning groups and roles one by one or going through admin cosnent workflow. With access packages, you are declaring a coherent policy: "This is what production access means for this type of workload. If the workload is approved, give it everything in this package. If it is denied or if the time expires, take everything away." The access package is a unit of authorization. It is atomic in the sense that you do not pick and choose which parts of it to apply. It is an all-or-nothing proposition.

For enterprises running multiple AI agents, access packages scale the authorization story. You create one access package per authorization context (production, staging, read-only partners, etc.). You assign agents to packages based on their needs. Governance reviews the packages on a schedule and approves or denies. The machinery runs itself.

There is also integration with approval workflows. An access package can require approval before assignment. You can route approvals to a specific manager or group. You can set expiration dates and schedule re-approval. For AI agents running in production, this is the audit trail that compliance teams expect. "Show me who approved this agent to have access to production data and when that approval expires."

Best practices on group emit scope and immutable identifiers

When you enable group claims, you need to decide: should Entra emit all groups the principal is a member of, or only assigned groups?

The answer is clear: use only groups assigned to the application. In a typical enterprise environment, grown over the yers, single user can be member of several thousands of groups. You cannot have a token with six thousand groups in it. And it makes no sense to go over six thousand groups to make authorization decision. Choosing "assigned groups" is tighter and mandatory for production. You explicitly assign the groups relevant for this app to that app. Other groups the principal happens to belong to stay out of the token. This keeps tokens predictable, avoids overage claims, and simplifies authorization logic.

Immutable identifiers are a separate but equally important consideration. Entra can emit group display names or group IDs in the token. Display names are human-readable but fragile. If a group is renamed, the token still carries the old display name until the token expires. Your API might silently fail to recognize the group and deny access. Or worse - someone may create a group with name that they will grant them access to the app. Group IDs are immutable. A group ID never changes, even if the display name changes. For production authorization logic, prefer group IDs. Your API logic becomes:

if token.groups contains "80d61f4e-4c9e-4f8f-9e1f-2e8f3d5c6b7a":
  grant access
else:
  deny

Not:

if token.groups contains "Sales-Americas":
  grant access
else:
  deny

The first version survives a group rename. The second does not. For large organizations managing many agents and APIs, using immutable group IDs and assigned-only scope is the only way to keep authorization logic maintainable and reliable at scale.

Composing the authorization stack

These mechanisms do not compete. They stack. Here is a realistic composition:

Requiring explicit assignment gates whether the principal can even attempt authentication.
Conditional access policies check location, device, and other context.
The token arrives with app roles and group claims embedded.
Your API inspects the token, checks app roles and groups, and makes fine-grained decisions.
All of this is orchestrated through an access package that defines the coherent policy for a given context (production, partner, read-only, etc.).

Each layer has a different trust surface. User assignment is coarse. Conditional access is context-based. App roles and groups are attribute-based. Access packages are policy-coordinated. Together, they form a defense in depth.

When you are designing authorization for an AI agent, ask yourself:

Should this agent be able to authenticate at all right now? (User assignment)
Under what conditions (location, device, time) should token acquisition be allowed? (Conditional access)
If the token is issued, what roles and group memberships should it carry? (App roles and group claims)
How is the agent's access provisioned, reviewed, and revoked? (Access packages and lifecycle management)

If you can answer each question with a specific, enforceable policy, you have authorization architecture. If you are relying on the API layer alone to deny requests, you are carrying unnecessary risk.

References

Flexibility with admin consent in Entra: how to scale consent flows for AI agents

Anton Staykov — Tue, 25 Aug 2026 11:43:00 +0000

Most organizations treat tenant-wide admin consent in Microsoft Entra as a binary decision. Either a central identity team approves every request, or somebody receives a broad administrative role so the queue can move faster.

That is a false choice.

Microsoft Entra supports a more precise control model: define which consent requests are acceptable in an app consent policy, bind that policy to a custom directory role, and delegate only the authority to approve requests inside that envelope. The role action that makes this possible is microsoft.directory/servicePrincipals/managePermissionGrantsForAll.{id}, where {id} identifies the policy that constrains the consent authority.

That is not a smaller version of Global Administrator. It is a different architectural idea: delegate the decision without delegating the directory.

AI agents make this distinction urgent. As organizations create more agent identities and authorize them against Microsoft Graph and other APIs, consent stops being an occasional setup task. It becomes a recurring control-plane operation. Scaling that operation with broad roles is the identity equivalent of solving traffic congestion by issuing everyone a master key.

The usual admin consent model does not scale

Tenant-wide admin consent is deliberately sensitive. A grant can authorize an application to access organizational data or perform privileged operations across the tenant, so Microsoft recommends reviewing the requested permissions carefully before granting it (grant tenant-wide admin consent).

The operational response is usually centralization. Every request lands with a small identity or security team. That team validates the application, checks the requested permissions, finds the business owner, and either approves or rejects the request.

Centralization gives you consistency, but it also creates a queue. The queue grows with every SaaS integration, internal application, automation workload, and AI agent. Eventually the organization reaches for a built-in role such as Application Administrator or Cloud Application Administrator to distribute the work.

That relieves the queue by expanding authority. It does not make the consent decision more precise.

Microsoft Entra already has a control surface for that precision. It is just underused.

An app consent policy is a permission envelope

An app consent policy describes the conditions under which a consent event is allowed. A policy contains one or more include condition sets and can contain exclude condition sets. A request must match at least one include condition set and must not match any exclude condition set for the policy to pass.

That evaluation model matters. You are not handing a delegate a list of instructions and hoping they follow it. You are placing a policy boundary in the authorization path.

The condition sets can describe characteristics such as the permission type, the resource application, specific permissions, client applications, and publisher status (permission grant condition set resource). This lets an organization express consent envelopes such as:

delegated Mail.Read and Files.Read permissions for Microsoft Graph,
selected application permissions exposed by one internal finance API,
permissions requested only by explicitly identified client applications,
delegated permissions from verified publishers, with sensitive resources excluded.

The important word is selected. The policy does not need to authorize every permission exposed by an API. It can describe the exact delegated scopes and application roles the organization has decided are appropriate for this delegation model (manage app consent policies).

Today, Microsoft exposes this policy model through Microsoft Graph. The relevant resources are permissionGrantPolicy and permissionGrantConditionSet, exposed under /policies/permissionGrantPolicies (manage app consent policies with Microsoft Graph).

The custom role binds authority to the envelope

The policy defines what may be approved. The custom role defines who may approve it.

Microsoft documents a specific custom-role permission for tenant-wide admin consent:

microsoft.directory/servicePrincipals/managePermissionGrantsForAll.{id}

The {id} suffix is not decoration. It binds the role permission to an app consent policy. The role assignee can grant tenant-wide consent for delegated permissions and application permissions only when the consent request satisfies that policy (app consent permissions for custom roles).

That gives architects a much better delegation primitive than "make this person a Cloud Application Administrator." The delegate receives a defined consent capability, not general application administration authority.

For example, a data platform team could receive authority to grant a fixed set of delegated scopes against an internal analytics API. A Microsoft 365 integration team could receive a different role tied to a policy for a small set of approved Graph permissions. Neither team needs a role whose authority extends across unrelated application-management operations.

Custom roles and app consent permissions require Microsoft Entra ID P1. The Entra admin center does not currently support adding these app-consent permissions to a custom role definition, so this configuration is available through Microsoft Graph rather than the Entra admin center UX (license and tooling requirements). That is implementation friction, but it does not weaken the control model.

Policy authorship and consent execution are different jobs

The strongest version of this architecture separates two responsibilities.

The central identity or security team authors the permission envelope. It decides which resource applications, delegated scopes, application roles, client properties, and exclusions belong in the policy. That team also controls the custom role definition and its assignments through the documented Microsoft Entra role-management interfaces (create a custom role).

The delegated administrator evaluates individual requests and grants consent only when Entra determines that the request fits the referenced policy.

Those are not the same privilege. Microsoft exposes separate custom-role permissions for creating, reading, updating, and deleting permission grant policies, distinct from managePermissionGrantsForAll.{id} (managing app consent policies through custom roles). A consent delegate should not automatically receive policy-authoring permissions.

That separation is the control.

If the same operator can widen the allowlist and approve the newly allowed request, the policy becomes a speed bump. If one team defines the envelope and another operates inside it, the policy becomes an enforceable delegation boundary.

Watch for alternate paths around the policy

There is one architectural trap worth stating plainly: app consent policies are not the only authorization mechanism that can allow a principal to grant permissions.

Microsoft documents that policies are evaluated independently and that a principal needs only one authorization path that permits a consent event. Ownership of a resource service principal and broad Microsoft Graph application permissions can provide other ways to create grants in some scenarios (multiple policies or authorization mechanisms).

That means the restricted role is only as restricted as the delegate's effective authority.

Do not combine the policy-bound consent role with broad application-management permissions and then describe the result as least privilege. Review the delegate's other directory roles, Microsoft Graph permissions, ownership assignments, and group-derived access. The consent policy should be the intended authorization path, not one path among several wider ones.

This is also why role naming matters. "Finance API Consent Approver" communicates a bounded function. "Application Admin Lite" invites future privilege creep. Names do not enforce security, but they tell future operators whether a role is a contract or a convenience.

A domain-based consent operating model

The practical enterprise model is not one policy for every application and not one policy for the entire tenant. Both extremes create maintenance problems.

Define envelopes around stable trust boundaries. A boundary might be a business domain, an API platform, a class of low-impact delegated permissions, or a controlled set of client applications. The condition-set model supports matching on multiple properties, so the policy can reflect more than a permission name alone (permission grant condition set properties).

Then assign the corresponding custom role to administrators who understand that domain. They can evaluate business purpose and operational context without receiving unrelated directory authority.

This changes the central identity team's job. It stops being the human endpoint for every consent request and becomes the designer of consent boundaries. The team owns policy quality, role lifecycle, exception handling, and periodic review. Domain administrators operate within the encoded boundary.

The result is not decentralized consent without governance. It is federated consent with a centrally defined authorization ceiling.

AI agents turn a useful feature into an architectural requirement

Microsoft Entra Agent ID supports delegated and application permission models for agents. Delegated authorization is represented by an oAuth2PermissionGrant, while application authorization is represented by an appRoleAssignment; Microsoft also documents direct creation of these objects and consent-based flows for granting agents access (grant agents access to Microsoft 365 resources).

That means agent adoption feeds the same consent control plane already used for applications, but at a different operational scale. A blueprint may produce many agent identities, and different agents may need different access as they move from experimentation into production (Agent ID key concepts).

The wrong response is to multiply broadly privileged administrators at the same rate.

The better response is to decide which permission combinations are routine, defensible, and delegable, then encode those combinations in consent policies. High-risk or unusual requests stay with the central authority. Known patterns move through policy-bound delegates.

This complements the argument in Why consent is the trust contract for Entra Agent ID. Consent still answers who authorized an agent, for which resource, and with what permissions. Granular delegation answers the next operational question: who is trusted to make that authorization decision without receiving power over the rest of the tenant?

There is an important current boundary. Microsoft states that custom Microsoft Entra roles cannot be assigned to agent identities (Microsoft Entra role assignments for agent identities). This pattern therefore does not make an AI agent the holder of the restricted consent role. It makes the consent process around AI agents more scalable for supported human role assignees.

The question this architecture creates

Once consent policy becomes an enforceable envelope, a more interesting question appears.

What if an AI agent could assess a consent request, inspect the requested permissions and business context, compare the request with organizational policy, and recommend approval or rejection? What if, one day, the platform supported that agent making the decision inside a boundary it could not rewrite?

That is not the capability described here. Current Agent IDs cannot hold custom Entra roles, and a probabilistic reasoning system should not be mistaken for an authorization boundary (Agent ID authorization restrictions). But granular consent delegation gives that future discussion a serious starting point. The policy remains deterministic. The permission ceiling remains centrally owned. The assessment could become intelligent.

The immediate opportunity is less speculative and more valuable: stop treating admin consent as authority that can only be centralized or broadly delegated. Microsoft Entra already lets you define the exact consent envelope and hand out only the key that fits that lock.

As AI agents increase the volume and variety of consent decisions, that flexibility stops being an obscure role-management feature. It becomes part of the architecture.

References

Dynamic client registration and CIMD are not a trust framework

Anton Staykov — Mon, 17 Aug 2026 10:37:00 +0000

The MCP specification ships with a strong opinion about how AI clients should onboard with authorization servers: dynamically, at runtime, without pre-coordination (MCP authorization spec). The AI community has largely nodded along. Enterprise security teams have largely not been consulted.

That mismatch is the subject of this article.

DCR and CIMD are genuinely useful protocol mechanisms. They are not a trust framework. And in an era where supply chain attacks are the dominant enterprise threat vector, confusing the two is a governance failure waiting for a specific client name to trigger it.

What DCR was designed to remove

RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol solves a real problem. The traditional OAuth onboarding sequence requires a developer to pre-register their client application with the authorization server, receive a client_id and client_secret, configure redirect URIs, and coordinate with whoever manages the identity provider before a single token can flow. For SaaS products, open developer ecosystems, and multi-tenant platforms, this ceremony is expensive. Teams wait days for provisioning. Integration partners hit identity-team backlogs. CI pipelines stall on human approvals.

DCR automates the ceremony. The client POSTs a JSON body describing itself to the authorization server's registration_endpoint. The server returns a client_id and client_secret immediately. No human approval. No pre-coordination. Developer velocity restored.

That is a genuine improvement in the right context. Public MCP servers, open developer tooling, and hobbyist integrations benefit from it directly. The friction reduction is real, and dismissing it is wrong.

The problem is not the protocol. The problem is the assumption that registration equals authorization, and that authorization equals trust.

What CIMD adds to the picture

Client Information Meta Data (CIMD) refers to the structured metadata fields a client submits in the DCR request, and through RFC 7592 (Dynamic Client Registration Management), the management endpoint that lets a registered client later read back and update its own registration record.

The metadata fields are richer than they appear at first. A client can declare its client_name, client_uri, redirect_uris, grant_types, scope, logo_uri, and most interestingly a software_statement (RFC 7591 §2.3). A software statement is a signed JWT issued by a third party the authorization server trusts, asserting facts about the client software: who built it, what version it is, what it is intended to do. It is the closest thing RFC 7591 has to attestation.

CIMD improves signal quality. It gives authorization servers structured, machine-readable metadata to work with. It makes client inventory possible in principle: if you log registrations, you at least know the name each client claimed. Software statements, when an authorization server validates them against a trusted issuer, move the model from "self-asserted identity" to "third-party asserted identity."

The critical word is when. Software statement validation is optional in RFC 7591. Most MCP server implementations do not enforce it. A client that omits the software_statement field registers exactly as successfully as one that includes it. The registration endpoint cannot distinguish a vetted corporate tool from a novel command-line script someone assembled over a weekend and pointed at your server.

CIMD raises the quality of information available at registration time. It does not answer whether your organization approved this client to exist here.

The enterprise security gap

Security teams in regulated industries (financial services, healthcare, critical infrastructure, government) operate on a fundamentally different assumption about software trust than DCR's default model. They run approved-software programs. Patch management is gated on testing and change-board approval. In the most security-mature environments I have worked in across thousands of enterprise security conversations, even Windows Updates are staged, validated, and controlled before rollout to the fleet.

This is not bureaucratic paranoia. It is the appropriate operational posture given how supply chain attacks actually work.

SolarWinds demonstrated that a trusted vendor's signed software update is a viable attack vehicle. CVE-2024-3094 (XZ Utils) showed that a two-year social engineering campaign can insert a backdoor into a compression library that ships inside essentially every Linux distribution. The lesson from both is not "trust nothing." The lesson is that how you establish and revoke software trust matters as much as whether a signature is present, and that self-asserted identity for software is precisely the attack surface adversaries aim for.

Against that backdrop, consider what unrestricted DCR on an enterprise MCP server looks like. Any AI client (any command-line tool, any agentic orchestrator, any LLM-driven system) that discovers the server's registration_endpoint can register itself, receive credentials, and start calling your server's tools. The server knows the client's claimed client_name. It does not know whether your security team reviewed the client's code, whether the vendor passed your procurement process, whether the version running is the one that was reviewed, or whether the registration request is originating from inside your network perimeter or from an endpoint that was compromised last week.

The SOC analyst's question is not theoretical: "Show me every MCP client registered on this server, who approved each one, under which policy, and when that approval was granted." Unrestricted DCR makes that question unanswerable, or worse, the answer is "anyone who sent a POST to the right endpoint."

Small organizations face the same question. The compliance regime may be less formal, but the threat is not.

Entra's deliberate answer: explicit registration as a trust decision

This is where the AI community tends to frame a gap. It is not a gap. It is architecture.

Microsoft Entra ID has no RFC 7591 registration_endpoint. There is no URL on login.microsoftonline.com that accepts a DCR POST and returns client_id credentials at runtime. Every application that can receive Entra-issued tokens must be explicitly registered, through the Azure portal, the Microsoft Graph API, the Azure CLI, or ARM templates, by a principal holding at minimum the Application Developer role (register an application in Microsoft Entra ID).

That deliberate registration is not the end of the trust chain. It is the beginning of it. A registered application that has not been explicitly consented still receives no tokens. Consent in Entra is the authorization gate: the act that says "this application is authorized to call this API, with these permissions, under this policy." A well-named AI client with a convincing client_name and a polished client_uri gets nothing from Entra without a human trust decision in the chain. (For the full governance architecture behind this claim, see the article Why consent is the trust contract for Entra Agent ID.)

The MCP authorization specification is careful here: it states that clients SHOULD attempt DCR when the authorization server's RFC 8414 metadata includes a registration_endpoint. "Should," not "must." A well-behaved MCP client encountering an authorization server that publishes no registration_endpoint (which is what every Entra tenant presents) falls back to static registration. That fallback is the intended behavior. The friction is intentional, and its source is a governance posture, not a missing feature.

The honest tradeoff: Entra's model maximizes governance precision and eliminates runtime surprise about who can request tokens. It creates real friction for MCP clients that expect to self-register on first contact. That friction is a feature for regulated enterprise deployments. It is a genuine obstacle for open, developer-facing MCP servers where the audience is trusted developers and the stakes per registration are low. Both statements are true simultaneously.

APIM AI Gateway: the bridge, and where the gap remains

When you place Azure API Management's AI Gateway in front of your MCP server, you gain a set of controls that together approach what a governance-controlled DCR layer would look like, without implementing one. Understanding exactly what APIM provides, and what it does not, is what allows you to design the right architecture rather than assume a gap has been closed when it has not.

The first piece is discovery integration. APIM can expose the .well-known/oauth-protected-resource endpoint defined in RFC 9728, which tells DCR-capable MCP clients where to find the authorization server protecting this resource (secure access to MCP servers). When APIM points to Entra as the authorization server, the MCP client reaches Entra, discovers no registration_endpoint in Entra's RFC 8414 metadata, and falls back to static registration. The discovery flow runs correctly. The governance gate holds. APIM participates in the DCR protocol dance without becoming a DCR endpoint.

The second piece is runtime client enforcement via the validate-azure-ad-token policy. This policy accepts a <client-application-ids> block, an explicit allowlist of Entra application IDs whose tokens are valid at this gateway:

<validate-azure-ad-token tenant-id="your-entra-tenant-id"
    header-name="Authorization"
    failed-validation-httpcode="401"
    failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <client-application-ids>
        <application-id>approved-mcp-client-app-id</application-id>
    </client-application-ids>
</validate-azure-ad-token>

A client that was registered in Entra and consented (both explicit human decisions), but whose application ID is absent from this list, still cannot pass the gateway. That is two distinct human approval steps between "an AI client exists" and "that AI client can invoke your MCP server tools." This is the runtime equivalent of an enterprise approved-software list, enforced at the gateway rather than in application code.

For scenarios where Entra registration still introduces too much friction (third-party client integrations, short-lived automation, partner tooling), APIM's subscription key model is the highest-control alternative. Every MCP client consumer receives a key provisioned explicitly by an APIM administrator. No dynamic discovery. No self-registration. Full explicit provisioning per consumer, with gateway-level revocation that does not wait for a consent withdrawal to propagate through the identity layer.

The observability dimension is underweighted in most governance architecture conversations. APIM routes all MCP tool invocations through a single plane with Application Insights integration and the llm-emit-token-metric policy for per-consumer token tracking. The SOC analyst's question, "show me every client calling this server, what it consumed, and when", becomes answerable from a single observability plane. That audit trail is precisely what unrestricted DCR alone never provides.

The honest gap deserves explicit naming. Neither APIM nor Entra today offers a governance-controlled RFC 7591 registration endpoint: a /register that issues credentials only to clients that have passed a policy gate: an Entra consent check, an access package approval, or a security review workflow. APIM and Entra together approximate this behavior through a different mechanism: explicit Entra app registration as the consent prerequisite, gateway policy as the runtime enforcement layer. The interoperability friction with DCR-native MCP clients is real. The architectural slot for a "governed DCR endpoint" is currently unoccupied in the Microsoft stack.

That gap is worth naming because it is where the tooling will likely evolve. An architecture where APIM exposes an RFC 7591-compliant /register endpoint that, on receiving a DCR request, triggers an Entra app registration, initiates an admin consent workflow, and optionally assigns an access package, before returning credentials to the registering client, would close it elegantly. That architecture does not exist today as a native product feature. What exists is the layered governance model described above.

A governance stack, not a binary choice

The practical architecture decision is not "DCR or no DCR." It is: what governance controls stand between a client expressing interest and a client receiving credentials?

For open, developer-facing MCP servers where the audience is trusted developers, the data sensitivity is low, and the expected client population is diverse and changing, DCR with software statement validation and a lean consent model is appropriate. Lean does not mean absent: even here, logging registrations, validating software statements when present, and auditing active clients periodically are the minimum defensible posture.

For enterprise MCP servers that expose organizational data, internal APIs, financial workflows, or records subject to regulatory requirements, the bar is different. Every client should be named. Every registration should be a deliberate trust decision. Every token scope should be consented explicitly under a policy that your security and governance teams own.

APIM plus Entra delivers that model today. Entra's explicit registration and consent layer ensures no client receives tokens without a human decision in the chain. APIM's AI Gateway enforcement layer ensures no token-bearing client bypasses your runtime policy. The observability layer ensures that "who approved this, with which permissions, and when" remains answerable across the full client lifecycle.

CIMD metadata enriches the picture on the way in: software statements, declared grant types, client URIs. Use them where your authorization server or gateway policy can act on them. Do not treat "richer metadata at registration time" as a substitute for governance state. Those are different properties, and conflating them is the precise mistake that makes a SOC analyst's life difficult six months after a pilot launches.

DCR is useful. CIMD is useful. Neither is a trust framework. The security teams that built enterprise software approval programs did not do it for the friction. They did it because supply chain attacks are real, and the moment you stop asking "who approved this software to exist here" is the moment a well-named binary with a convincing client_name receives credentials to your organizational data.

APIM AI Gateway and Entra's explicit registration model is the closest the Microsoft stack comes today to answering that question at MCP server scale. The remaining gap is a named target. The governance floor is already in place.

References

Why consent is the trust contract for Entra Agent ID

Anton Staykov — Wed, 12 Aug 2026 11:07:00 +0000

If your AI agent can read customer mailboxes, create directory objects, or call internal APIs, your real architecture question is not "can it authenticate?" The hard question is "who authorized this, under which policy, for how long, and with which guardrails?" In Microsoft Entra, that question is answered through permissions and consent. That is why consent is not a user-experience detail. It is the trust contract.

This matters even more for agent identities. Microsoft Entra Agent ID deliberately treats agents as a special operational class, with explicit authorization controls and blocked high-risk privileges rather than unconstrained app-like power (authorization model, Graph overview for Agent ID). If your mental model is still "grant broad access once and move on," your governance will fail faster than your pilot succeeds.

In [[A-transformational-AI-agent-does-not-start-with-the-permissions-it-needs]], I argued that strong agent platforms start narrow and earn scope in context. This article is the governance layer under that claim: why consent is the control surface, how to operate it at enterprise scale, and how access packages turn theory into an auditable runtime model.

Consent is authorization, not authentication

Consent in Entra is the act that authorizes an application identity to access a protected resource with specific permissions (user and admin consent overview, permissions and consent overview). Authentication answers "who are you?" Consent answers "what are you allowed to do against this API or resource?"

That distinction sounds obvious until production pressure arrives. Teams often secure sign-in, configure Conditional Access, and then assume the authorization problem is solved. It is not. A signed-in actor without the right consent grant is still unauthorized, and a correctly consented actor can still be over-privileged if governance posture is weak (permissions and consent overview, configure user consent).

For mixed technical leadership, this is the key reframing: consent is where legal risk, security posture, and delivery velocity intersect. It is the formal boundary between "agent capability requested" and "agent capability approved."

User consent and admin consent are different risk gates

Entra supports delegated permissions where an app or agent acts on behalf of a signed-in user, and application permissions where it acts autonomously without a user context (permissions and consent overview, grant agents access). Those two modes map to different consent paths and different blast radii.

User consent is viable when non-admin users are allowed to consent to the app and permission set by tenant policy (user and admin consent overview). Admin consent is required for application permissions and for delegated permissions that are admin-restricted or otherwise outside permitted user-consent boundaries (user and admin consent overview, grant agents access).

That is not bureaucracy. That is architecture. User consent is typically scoped to the user context. Admin consent can authorize tenant-wide impact. Treating those as interchangeable is how over-privileged agents are born.

Consent policy is a leadership decision encoded in platform behavior

Most organizations do not leave consent wide open, and they should not. Entra gives administrators tenant-wide choices: disable user consent entirely, allow only verified publishers plus selected low-impact permissions, or allow broader user consent where risk tolerance supports it (configure user consent, user and admin consent overview).

If user consent is limited, Entra can route blocked requests through the admin consent workflow so business demand is visible and reviewable instead of hidden in shadow tooling (user and admin consent overview, configure admin consent workflow). This is where governance stops being a "no" function and becomes a control function.

For leadership teams, the operational takeaway is clear: consent policy is not a tactical identity setting. It is a policy expression of enterprise risk appetite. Decide it explicitly, document it, and align agent deployment patterns to it.

Consent phishing proves whether your model is real

Consent phishing is the attack pattern where users are tricked into granting OAuth permissions to malicious applications, often through convincing app names and realistic prompts (protect against consent phishing). This is not theoretical noise. It is exactly what happens when the organization treats consent as a user-interface click instead of a control plane.

Microsoft guidance is explicit: harden user consent settings, favor verified publishers, audit app permissions, investigate suspicious grants, and integrate detection and remediation workflows (protect against consent phishing). If those controls are absent, your "agent security strategy" is just language.

A mature model assumes two truths at once: legitimate agents need controlled permission growth, and adversaries will try to exploit the same consent mechanics. Governance has to handle both.

Delegated vs application permissions for agents, with protocol constructs that matter

For agent identities, delegated mode is used when the agent acts in a user context. Application mode is used when the agent acts autonomously (authorization in Agent ID, grant agents access). That split directly affects token semantics.

In delegated scenarios, effective scopes are carried in the scp claim. In app-only scenarios, effective app permissions are carried in the roles claim (token claims for agents, grant agents access). You do not need packet-level protocol traces to govern correctly, but you do need leadership alignment that these constructs define runtime authority.

The advanced nuance for Agent ID is permission inheritance at blueprint level. This is not default behavior. Entra documents that inheritance only happens when you explicitly configure inheritable permissions on the blueprint and the corresponding permissions are actually granted on the blueprint principal (inheritable permissions concept, configure inheritable permissions).

That should drive a stricter approval posture: treat blueprint consent as baseline capability setup, not as a full production access request. Keep blueprint consent narrow, and push broader or time-bound operational access through governed assignment workflows such as access packages (access packages for agent identities).

Agent ID already blocks high-risk permission paths, by design

A healthy governance discussion should also acknowledge built-in platform guardrails. Agent IDs can use delegated and application permission models, but Entra explicitly blocks a range of high-risk Graph permissions for agents and restricts role assignment options compared to unconstrained identity types (authorization in Agent ID, Agent ID Graph overview blocked permissions).

This design choice reinforces the principle of least privilege for autonomous systems. It does not remove governance responsibility, but it reduces failure modes where someone "temporarily" grants sweeping directory control and forgets to remove it.

In plain terms: the platform is already telling you the right operating model. Narrow by default. Escalate deliberately. Keep high-risk paths off the table unless there is an explicit and supported control route.

Access packages are the practical admin-consent engine for agent scale

Consent alone is necessary, but not sufficient, when you run fleets of agents. You need a repeatable, policy-owned mechanism for requesting, approving, granting, expiring, and reviewing access. For Entra Agent ID, access packages provide that mechanism (access packages for agent identities, governing agent identities).

This is why I keep connecting this to [[Access-Packages-Are-the-Control-Plane-for-Entra-Agent-ID-Permissions]]. Access packages let you operationalize consent and authorization as workflow, not as ad hoc privilege assignment. They can include directory roles, OAuth delegated and application permissions, and group memberships in one governed package (access packages for agent identities).

Crucially, policy can require one, two, or three approval stages, with explicit approver definitions and decision timeouts (approval policy settings, access package create stages). That means you can model governance depth based on data sensitivity, not gut feel.

Dynamic approvals, SoD checks, and custom logic make governance adaptive

Static approver lists are often too rigid for enterprise reality. Entra entitlement management supports dynamic approval determination through custom extensions and Logic Apps integration, so approvers can be derived through business logic at request time (dynamic approval, Logic Apps integration).

Separation-of-duties controls let you mark access packages or groups as incompatible, preventing users or identities with one assignment from requesting conflicting assignments (SoD checks). This is the difference between "we approved safely once" and "we remain safe over time."

If you need one sentence for the board slide, use this: access packages are not just an approval screen. They are a programmable authorization lifecycle with governance state.

A practical operating model for mixed technical leadership

If you lead a platform team, security team, or product portfolio touching agent identities, this model is battle-tested and aligned to Microsoft guidance:

Start with narrow required access on blueprints and explicit inheritable-permission design (inheritance is opt-in, not automatic), so admins can review baseline intent clearly and avoid turning blueprint consent into broad standing access (inheritable permissions concept, configure inheritable permissions).
Set tenant consent policy intentionally (usually verified-publisher plus low-risk where possible), and force higher-risk asks through admin review paths (configure user consent, user and admin consent overview).
Route runtime growth through access packages instead of direct permanent grants, including approver stages, SoD, and expiry settings (access packages for agent identities, approval policy, SoD checks).
Treat sponsor and owner accountability as first-class controls, because governance is not complete if no human is accountable for extension and renewal decisions (governing agent identities).
Assume consent abuse attempts and instrument for response, including consent-phishing hardening and suspicious-grant investigation workflows (protect against consent phishing).

This operating model gives engineering enough autonomy to ship and iterate, while preserving the control evidence leadership needs for audit and risk committees.

The core decision

You can run agents on standing privilege and hope nothing goes wrong. Many teams do exactly that during pilots. It looks fast right until the first real governance review.

Or you can run agents on governed consent, with policy-owned approval paths, explicit token authority constructs, and time-bound assignment lifecycle. That model scales beyond demos because it aligns with how Entra is designed to authorize applications and agents (permissions and consent overview, authorization in Agent ID, access packages for agent identities).

That is the underrated shift in enterprise agent architecture right now: the winning platform is not the one with the most tools. It is the one where consent remains the trust contract, even as agent capability grows.

References

From JWT-SVID to Entra Agent ID: a working SPIFFE PoC

Anton Staykov — Thu, 06 Aug 2026 11:19:00 +0000

The architecture diagram was the easy part.

In Your SPIFFE workload can authenticate as an Entra Agent ID, but mind the trust gap, I argued that SPIFFE and Microsoft Entra Agent ID belong on opposite sides of a narrow trust contract. SPIRE proves which workload is running. Entra decides which governed agent identity that workload may use. A federated identity credential connects those statements through an exact issuer, subject, and audience match, which is how Microsoft Entra workload identity federation validates an external JWT.

That article described the architecture and its trust gap. This one runs it.

The agentid-spiffe proof of concept deploys a complete agent loop with SPIRE, public OIDC discovery, Microsoft Entra Agent ID, and a downstream Microsoft MCP Server for enterprise call. The interesting result is not the chat interface or the model. It is the moment a JWT-SVID issued to one attested process becomes the client assertion for an Agent Identity Blueprint, without a client secret or certificate copied into the workload.

This is a conceptual walkthrough with selected configuration and code. It is deliberately not a SPIRE deployment guide. Follow the repository README to run the sample. Here, we are going to trace the identity as it changes hands.

Five SPIFFE concepts in one minute

A trust domain is the administrative and cryptographic boundary within which SPIFFE identities are issued. Its name forms the authority portion of every SPIFFE ID. The PoC uses poc.local, so its workload identity begins with spiffe://poc.local/. SPIFFE defines that URI as the stable name of a workload, independent of an IP address, host name, or cloud provider account (SPIFFE concepts).

The SPIRE Server is the authority for that trust domain. It stores registration entries, evaluates attestation results, and signs the identity documents issued inside the domain. The SPIRE Agent runs near workloads, attests to the server as a node, exposes the local Workload API, and performs workload attestation before returning identity documents to a process (SPIRE concepts).

Workload attestation is the decision that connects runtime evidence to a registered SPIFFE ID. In this sample, the SPIRE Server registers a Unix selector for a process running as UID 0. When the FastAPI process calls the local Workload API, the SPIRE Agent evaluates that evidence and returns the identity registered for the matching selector. SPIRE documents selectors as the attested properties used to match a workload to a registration entry (registering workloads).

The returned identity can take two common forms. An X.509-SVID is a certificate suited to mutual TLS. A JWT-SVID is a signed bearer token whose sub is the workload's SPIFFE ID and whose aud names the intended recipient (JWT-SVID specification). This PoC needs the JWT form because Microsoft Entra accepts an external JWT as the client assertion in its federated client credential flow.

That is all the SPIFFE theory required for this walkthrough. The rest is the handoff.

The components in play

The PoC places several processes in one Azure Container App image so the identity path is easy to inspect. That packaging is a lab convenience, not an architectural recommendation (repository architecture).

Inside the container, five components matter:

The SPIRE Server owns the poc.local trust domain and signs JWT-SVIDs.
The SPIRE Agent exposes a Unix socket implementing the Workload API.
The SPIRE OIDC Discovery Provider publishes the JWT signing keys.
FastAPI retrieves the JWT-SVID and performs the Entra token exchanges.
The browser SPA supplies an incoming user token when the sample runs in user-context mode.

Outside the container, Microsoft Entra holds the agent identity blueprint, its blueprint principal, the child agent identity, the federated identity credential, and the delegated grants. The final Agent ID token is passed to the Microsoft MCP Server for enterprise. The model call proves that the token is usable, but it is downstream of the identity mechanism we care about.

SPIFFE workload plane                     Microsoft Entra control plane

+---------------------------+            +-----------------------------+
| FastAPI agent workload    |            | Agent Identity Blueprint    |
+---------+-----------------+            +-------------------+---------+
          |                                                  |
          | runtime evidence                                 |
          v                                                  |
+---------+-----------+                                      | Federated Identity
| SPIRE Agent         |                                      | Credential
| Workload API        |                                      |
+-------+-------------+                                      |
        | attestation                                        |
        v                                                    |
+-------+-----------------+      signing keys       +--------+--------+
| SPIRE Server            |------------------------>| OIDC metadata   |
| issues JWT-SVID         |                         | and public JWKS |
+-----------+-------------+                         +-------+---------+
            |                                               ^
            | short-lived JWT-SVID                          |
            v                                               | validates
+-----------+-------------+  JWT-SVID + fmi_path            |
| FastAPI agent workload  |-------------------------------->|
+-------+-----------------+                                 |
        ^                                                   |
        | T1 exchange token                                 |
        +---------------------------------------------------+
        |
        | T1 as child assertion
        v
+-------------+-------------+                +-----------------------------+
| Child agent identity      |--------------->| Downstream MCP resource     |
| requests resource token   |    Agent ID    | validates Entra token       |
+---------------------------+    token       +-----------------------------+

The diagram contains two identity planes. The SPIFFE plane ends when the workload receives its JWT-SVID. The Entra plane begins when that JWT is presented as the blueprint's client assertion.

How the process becomes a SPIFFE workload

The container entrypoint starts the SPIRE Server, creates a join token for the co-located agent, and registers one workload entry (entrypoint source):

spire-server entry create \
  -parentID spiffe://poc.local/agent/node1 \
  -spiffeID spiffe://poc.local/agent/identity-1 \
  -selector unix:uid:0

Read that registration from right to left. A process matching unix:uid:0, attested through the registered parent agent, receives spiffe://poc.local/agent/identity-1 as its workload identity. The SPIFFE ID is not generated from the process name or container name. It is the explicit result of registration policy and attested selectors, which is the model SPIRE uses to issue identities through its Workload API (SPIRE workload registration).

The selector is intentionally broad because every process in the image runs in the same lab boundary. A production deployment would use workload and node attestors that express the real platform boundary. That decision is outside this PoC. We only need a reliably attested process from which to request the JWT-SVID.

The server configuration then defines the JWT issuer and signing profile (SPIRE server configuration in the PoC):

server {
    trust_domain = "poc.local"
    jwt_issuer = "__OIDC_ISSUER_URL__"
    jwt_key_type = "rsa-2048"
    default_jwt_svid_ttl = "10m"
}

trust_domain controls the SPIFFE ID namespace. jwt_issuer becomes the JWT-SVID iss claim. jwt_key_type makes SPIRE sign the assertion with RSA so that the token uses RS256. These values are related, but only the issuer crosses directly into the Entra configuration.

And this is where the most important interoperability detail appears.

The issuer is a public protocol surface, not a string

It is tempting to treat the federated identity credential's issuer as an identifier. Configure the same URL in SPIRE and Entra, make the strings match, and move on.

That is not enough.

Microsoft Entra documents two requirements that make the issuer an operational endpoint. First, RS256 is the supported signing algorithm for workload identity federation assertions. Other algorithms might work, but Microsoft does not test them. A robust implementation therefore needs an RS256-signed JWT, which is why this PoC explicitly configures jwt_key_type = "rsa-2048" (supported signing algorithms and issuers).

Second, the issuer must be a publicly reachable HTTPS URL that follows OIDC discovery. Microsoft Entra uses the configured issuer to retrieve the metadata and signing keys needed to validate the external token (configure trust with another identity provider). For the issuer used by this PoC, the primary discovery URL is formed by appending /.well-known/openid-configuration:

Issuer
https://<container-app-host>/spiffe-oidc

Discovery document
https://<container-app-host>/spiffe-oidc/.well-known/openid-configuration

The discovery document points Entra to the public key set:

{
  "issuer": "https://<container-app-host>/spiffe-oidc",
  "jwks_uri": "https://<container-app-host>/spiffe-oidc/keys",
  "subject_types_supported": ["public"]
}

Entra follows jwks_uri, finds the public key whose kid matches the JWT-SVID header, and uses that key to verify the RS256 signature. The private signing key remains inside SPIRE. OIDC discovery publishes only the public half required by verifiers, following the standard discovery and JWKS model (OpenID Connect Discovery 1.0).

This is why an exact iss match can still fail. The URL might be spelled correctly while the discovery document is missing, inaccessible, malformed, or pointing at a JWKS that does not contain the active signing key. In that state, Entra knows where the assertion claims to come from but cannot cryptographically prove that the issuer signed it.

The sample runs SPIRE's OIDC Discovery Provider locally, then proxies its metadata and key set through the Container App's public HTTPS origin (OIDC proxy implementation). The proxy rewrites issuer and jwks_uri to their public values, removes an empty authorization endpoint, populates subject_types_supported, and adds "use": "sig" to each published key for compatibility. It exposes both the OpenID Connect discovery path shown above and the RFC 8414 path form for an issuer containing a path:

https://<container-app-host>/.well-known/openid-configuration/spiffe-oidc

Both documents describe the same issuer and point to the same JWKS. That extra route avoids relying on ambiguous discovery behavior when the issuer itself contains /spiffe-oidc.

The OIDC endpoint is not incidental web plumbing. It is part of the credential chain. If it disappears or publishes the wrong key, the JWT-SVID stops being a credential Entra can validate.

The federated identity credential binds one workload to the blueprint

Once the public issuer works, the post-deployment configuration creates a federated identity credential on the agent identity blueprint application. It does not create the credential on the child agent identity (FIC configuration source).

The effective object is small:

{
  "name": "spire-jwt-svid-blueprint",
  "issuer": "https://<container-app-host>/spiffe-oidc",
  "subject": "spiffe://poc.local/agent/identity-1",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

Here is a decoded JWT-SVID captured during one of the PoC runs. The signature is omitted, but the header and payload are unchanged:

{
  "alg": "RS256",
  "kid": "KNd3DSGQAvCP1U2rHUd3rBzf9oX1y7BG",
  "typ": "JWT"
}.{
  "aud": [
    "api://AzureADTokenExchange"
  ],
  "exp": 1785157382,
  "iat": 1785156782,
  "iss": "https://spiffe.proudhill-d482409c.westeurope.azurecontainerapps.io/spiffe-oidc",
  "sub": "spiffe://poc.local/agent/identity-1"
}.[Signature]

The header says that SPIRE signed the assertion with RS256 and identifies the public verification key through kid. The payload names Entra's token exchange as the only audience, carries a ten-minute validity window, exposes the public OIDC issuer, and uses the registered SPIFFE ID as its subject. Entra retrieves the issuer's JWKS, selects KNd3DSGQAvCP1U2rHUd3rBzf9oX1y7BG, verifies the omitted signature, and then evaluates the three FIC claim matches (workload identity federation mechanics).

Those three trust properties map directly to the incoming JWT-SVID:

JWT-SVID iss  == FIC issuer
JWT-SVID sub  == FIC subject
JWT-SVID aud  == FIC audiences[0]

Microsoft Entra compares those values exactly and case-sensitively when evaluating a standard federated identity credential (federated identity credential matching). The FIC therefore says something precise: a token from this public issuer, for this one SPIFFE workload, minted specifically for Azure AD token exchange, may authenticate this blueprint.

It does not grant the workload Microsoft Graph permissions. It does not authorize the model to use an MCP tool. It only replaces the blueprint's stored client secret or certificate with a short-lived external assertion. Authorization remains attached to the child agent identity and the downstream resource, consistent with the Agent ID identity and authorization model.

The application requests the JWT-SVID only when MSAL needs it

The FastAPI application opens the local SPIRE Workload API through the SPIRE Agent's Unix socket. Its assertion provider asks for one JWT-SVID with api://AzureADTokenExchange as the audience (backend source):

class SpiffeJwtProvider:
    def __call__(self, ctx=None) -> str:
        svid = self._ensure_source().fetch_svid(
            audience={self._audience}
        )
        return svid.token

That audience matters. The JWT-SVID specification recommends a single audience because a JWT-SVID is a bearer token and every listed audience becomes a potential recipient. This token exists for one purpose: presentation to Entra's workload identity federation endpoint.

The provider is passed to MSAL as a callable client assertion rather than as a static token:

blueprint_app = msal.ConfidentialClientApplication(
    BLUEPRINT_CLIENT_ID,
    client_credential={"client_assertion": _jwt_svid_provider},
    authority=AUTHORITY,
)

MSAL can invoke a callable assertion provider when it needs a fresh credential, which fits a short-lived SVID better than capturing one token at process startup (MSAL Python confidential client application). SPIRE remains responsible for issuing the workload credential. MSAL remains responsible for Entra token acquisition and caching.

`fmi_path` turns blueprint authentication into one agent identity

The first Entra request authenticates the blueprint with the JWT-SVID and asks for an exchange token scoped to one child agent identity:

result = blueprint_app.acquire_token_for_client(
    ["api://AzureADTokenExchange/.default"],
    fmi_path=agent_app_id,
)

The fmi_path value is the child agent identity's client ID. Microsoft documents that parameter as the instruction telling Entra which agent identity the blueprint is acting on behalf of (request a token for the agent identity blueprint). The result is T1, an exchange token bound to the blueprint-to-child path.

The child agent identity has no independent client secret, certificate, or FIC. The application creates a second MSAL confidential client for the child and supplies T1 through another assertion callback:

def assertion_cb(ctx=None) -> str:
    result = blueprint_app.acquire_token_for_client(
        ["api://AzureADTokenExchange/.default"],
        fmi_path=agent_app_id,
    )
    return result["access_token"]

agent_app = msal.ConfidentialClientApplication(
    agent_app_id,
    client_credential={"client_assertion": assertion_cb},
    authority=AUTHORITY,
)

From there, the flow can branch. In app-only mode, the child requests a resource token using its application permissions. In the PoC's user-context mode, it combines T1 with the incoming user's access token in an on-behalf-of exchange. Microsoft documents that the second request switches client_id from the blueprint to the child agent identity and presents both the blueprint exchange token and user assertion (Agent ID OBO protocol).

The JWT-SVID has already done its job before that branch. It authenticated the blueprint. T1 then authenticated the child agent identity. The final access token is scoped to the downstream resource and represents either the autonomous agent or the agent acting in the user's context, depending on the selected flow (authenticate and acquire tokens for autonomous agents).

That separation is the reason this is more than generic workload federation. The external workload does not become an ordinary app registration. It enters a blueprint-controlled path and emerges as a governed child agent identity.

What the PoC proves

The sample proves four useful things.

First, a JWT-SVID can serve as the real client assertion for an Entra Agent ID blueprint. Microsoft lists SPIFFE and SPIRE as a supported workload identity federation scenario, and Agent ID supports direct workload identity exchange for third-party agent platforms (supported workload identity federation scenarios, third-party Agent ID integration patterns).

Second, the SPIFFE ID maps cleanly into the FIC subject. The workload identity spiffe://poc.local/agent/identity-1 remains visible at the trust boundary instead of being translated into an unrelated shared secret.

Third, the public issuer surface is as important as the token. Federation succeeds only when the JWT iss, FIC issuer, discovery document issuer, discovery URL, JWKS location, active kid, and RS256 signature all describe the same cryptographic authority. Microsoft Entra retrieves the external keys through that OIDC issuer contract before accepting the assertion (workload identity federation mechanics).

Fourth, the identity that calls the downstream API is still the child agent identity. SPIRE authenticates the workload to the blueprint. It does not bypass Agent ID's parent-child token flow, consent, or downstream authorization model (agent identities).

What the PoC deliberately does not prove

The repository is unusually clear about its shortcuts, and that clarity matters.

SPIRE state is ephemeral. Every Container App start deletes the server and agent data, regenerating the CA material, JWT signing key, and JWT kid. Microsoft Entra can retain previously retrieved issuer metadata and keys, so exchanges can fail after a restart until its view refreshes (repository warning). This is the loudest reason not to mistake the sample for a production SPIRE topology.

The agent uses a join token and insecure_bootstrap = true, while the server and agent are co-located with the workload. Those choices remove infrastructure that would distract from the exchange, but they are explicitly marked as PoC-only in the agent configuration.

The backend also logs the full JWT-SVID to simplify troubleshooting while the FIC is being wired up (logging code). Do not carry that behavior into production. A JWT-SVID is a bearer credential susceptible to replay during its validity window, so it must not enter application logs, traces, prompts, or tool output (JWT-SVID replay considerations).

None of those shortcuts invalidate the demonstrated identity exchange. They define its boundary. The sample proves that a correctly issued JWT-SVID, signed with RS256 and backed by public OIDC discovery, can authenticate an Agent ID blueprint. It does not prove that one ephemeral container is how an organization should operate SPIRE.

The trust contract is now executable

The previous article ended with two control planes and one narrow trust contract. The PoC turns that sentence into running code.

SPIRE attests the FastAPI process and issues spiffe://poc.local/agent/identity-1 a short-lived JWT-SVID. The OIDC discovery endpoint makes the active RSA public key available at a predictable public URL. The federated identity credential authorizes one exact issuer, SPIFFE ID, and audience to authenticate the blueprint. fmi_path narrows the resulting T1 token to one child agent identity. That child obtains the final resource token under its own authorization boundary.

No shared client secret crosses the container boundary. No X.509 certificate is copied into the agent. No custom token validator is added to Entra. The bridge uses the SPIFFE JWT identity format, standard OIDC discovery, Entra workload identity federation, and Agent ID's documented blueprint exchange (workload identity federation, Agent ID token acquisition).

The issuer configuration is the hinge. It must be exact, public, standards-shaped, and cryptographically aligned with the JWT in flight. Get that right, and the SPIFFE workload can enter Entra as a governed agent identity without ever owning a long-lived Entra credential.

That is the result this PoC was built to isolate.

DEV Community: Anton Staykov

The AI agent kill switch is a procedure, not a feature

The stop objective determines the control

Token revocation changes authorization, not execution

Request boundaries must leave no accepted bypass

Local effects require host and network enforcement

Independent authority must keep the stop latched

Acceptance requires coverage, timing and persistence

Re-entry requires independent clearance

References

To passkey or not to passkey? Microsoft Entra has changed the question

A customer needed one working phone, not a passwordless programme

The recent Entra changes make this a different discussion

Authenticator is an application, not an authentication method

Same-device is the design choice that removes the detour

A permissive worker profile is a deliberate trust decision

Bootstrap registration before you enforce the credential

Automate the surrounding work, not the user's private key

References

Agent-to-agent authorization with Entra Agent ID on AWS AgentCore

Version 3 makes agent-to-agent authorization the point

A2A standardizes the message, not the trust decision

Separate blueprints make three workload trust roots visible

Blueprint 2 is an API surface, not just Agent 2's credential holder

The delegated path composes client consent, user assignment, and caller identity

The autonomous path receives an app role and no inherited tools

Authorization must fail before the model gets a vote

References

Encryption in transit is not end-to-end encryption: block unsanctioned GenAI access

Encryption in transit is not end-to-end encryption

True end-to-end encryption protects the payload from the gateway

The gateway is the control plane, not just a door

The trust boundary is the thing that matters

Why the GenAI risk is different

Strong AI governance already has an identity plane

The real answer is not a policy slogan. It is a system design rule

And that means the governance question is not about the browser. It is about the trust contract

References

How an AWS-hosted Entra Agent ID drops the client secret

The client secret was never the identity

What version 2.0 changes

Configure AWS to attest to the workload

Configure Entra to trust one AWS role

The most important code is in the MSAL constructors

The blueprint confidential client application delegates its credential to AWS STS

The agent client delegates its assertion to the blueprint client

Construct once, refresh through the callbacks

Assertion delegation is not user delegation

Exchange the AWS assertion for the blueprint token

Continue with the Agent ID token exchange

What became safer, and what did not

Failure modes worth testing

Change the audience

Run under another IAM role

Point to another AWS issuer

Request a permission the agent does not have

Remove sts:GetWebIdentityToken

The configuration is the architecture

References

Your API gateway is not an identity provider, and promoting it to one is a liability

The words I use are OAuth words

The gateway's job is governance, not authorization

A plausible execution path

In the ideal world, one authorization server sees all seven token requests

The real world runs four authorization servers, not three

There are two places inside the gateway where Bob changes identity

Four policy engines is a liability, and it should be called one

RFC 8693 does not fix a broken trust anchor

References

AI agents need an authorization domain beyond OAuth

OAuth proves a grant, not the meaning of an agent transaction

Fine-grained policy gives the transaction its business meaning

Static policy needs bounded intelligent judgment for changing context

A proposed decision contract must bind decisions to the proposed effect

Delegation does not erase the human authority boundary

Start with transactions that have a reversible boundary

Record observed facts, not an invented provenance story

Do not make the authorization server carry the whole system

References

Authorization options for your AI agents with Entra Agent ID

Remove `sts:GetWebIdentityToken`

`fmi_path` turns blueprint authentication into one agent identity