Preconditions
Related command
az login --
workload identity
Resource Provider
MSAL and ESTS provide
Description of Feature or Work Requested
the goal is to allow customers to better control what agents can do and demonstrate this during Build (it is not clear in which session - potentially keynote). For example, prevent an agent from accessing secrets (this is aligned with one of the cli issue we have seen from customers asking for a read-only mode).
The short term implementation relies on copilot cli to set an environment variable COPILOT_AGENT_SESSION_ID that will be passed to MSAL when acquiring the token. The work has already been done with office (workiq) so we are not expecting implementation surprises at this point. Also note that this is only scoped to user identities (workload identities are not in scope for Build).
I see few of challenges:
We need to do a release (preview?) for May 15 so that folks can validate the end to end with MSIT tenant.
This new version should be consumable by Azure MCP therefore we need to coordinate with them about timeline and versions.
Considering the short delay (5/15 is in 2 weeks + 1 day), I'd like to see what we need to reprioritize so we can meet the deadlines.
Overview
Enable Azure CLI to support agentic sessions by tagging authentication requests with an agent-specific session context. This allows downstream systems (ESTS, RBAC, Resource Providers) to differentiate between human and agent-initiated actions using the same user identity.
Why
Today, Azure CLI uses user identity for all operations, with no way to distinguish:
Human usage
Agent / Copilot / automation usage
This limits:
Policy control (e.g., restricting LLM access to sensitive operations)
Security and auditing for agent-driven workflows
This feature introduces a lightweight signal to unlock policy-aware agent scenarios without changing the identity model.
What CLI Needs to Do
Azure CLI acts as the entry point for agent context propagation.
- Session Creation
Generate a unique session ID for agent flows
Store in env var (e.g. COPILOT_AGENT_SESSION_ID)
2. Session Propagation
Ensure session ID flows across CLI and all child processes
3. MSAL Integration
When acquiring a token:
Pass session ID as query parameter (client_session)
Pass session ID in claims
4. Token Handling
Ensure agent session participates in token caching
Avoid mixing agent and user tokens
How It Works (High Level)
Agent / Copilot /Azure MCP
↓
Azure CLI (generate session)
↓
MSAL request (query + claim)
↓
ESTS issues token (with agent marker)
↓
RBAC / RP enforce policies
Benefits (for CLI)
Enables secure agent & Copilot scenarios
Supports policy differentiation (human vs agent)
Keeps existing auth model unchanged (non-breaking)
Aligns with Build / MCP / AI-first direction
Notes / Limitations
Current approach is caller-asserted (not strongly enforced)
Based on env var propagation (can be spoofed)
Future improvements may include:
process tree tracking
trusted execution context
Minimum API Version Required
MSAL and ESTS provide
Swagger PR link / SDK link
MSAL and ESTS provide
Request Example
No response
Target Date
2026-5-15
PM Contact
Scott Addie
Engineer Contact
Nikhil Reddy Boreddy, Iulian Cociug, Ashock
Additional context
No response
Preconditions
Related command
az login --
workload identity
Resource Provider
MSAL and ESTS provide
Description of Feature or Work Requested
the goal is to allow customers to better control what agents can do and demonstrate this during Build (it is not clear in which session - potentially keynote). For example, prevent an agent from accessing secrets (this is aligned with one of the cli issue we have seen from customers asking for a read-only mode).
The short term implementation relies on copilot cli to set an environment variable COPILOT_AGENT_SESSION_ID that will be passed to MSAL when acquiring the token. The work has already been done with office (workiq) so we are not expecting implementation surprises at this point. Also note that this is only scoped to user identities (workload identities are not in scope for Build).
I see few of challenges:
We need to do a release (preview?) for May 15 so that folks can validate the end to end with MSIT tenant.
This new version should be consumable by Azure MCP therefore we need to coordinate with them about timeline and versions.
Considering the short delay (5/15 is in 2 weeks + 1 day), I'd like to see what we need to reprioritize so we can meet the deadlines.
Overview
Enable Azure CLI to support agentic sessions by tagging authentication requests with an agent-specific session context. This allows downstream systems (ESTS, RBAC, Resource Providers) to differentiate between human and agent-initiated actions using the same user identity.
Why
Today, Azure CLI uses user identity for all operations, with no way to distinguish:
Human usage
Agent / Copilot / automation usage
This limits:
Policy control (e.g., restricting LLM access to sensitive operations)
Security and auditing for agent-driven workflows
This feature introduces a lightweight signal to unlock policy-aware agent scenarios without changing the identity model.
What CLI Needs to Do
Azure CLI acts as the entry point for agent context propagation.
Generate a unique session ID for agent flows
Store in env var (e.g. COPILOT_AGENT_SESSION_ID)
2. Session Propagation
Ensure session ID flows across CLI and all child processes
3. MSAL Integration
When acquiring a token:
Pass session ID as query parameter (client_session)
Pass session ID in claims
4. Token Handling
Ensure agent session participates in token caching
Avoid mixing agent and user tokens
How It Works (High Level)
Agent / Copilot /Azure MCP
↓
Azure CLI (generate session)
↓
MSAL request (query + claim)
↓
ESTS issues token (with agent marker)
↓
RBAC / RP enforce policies
Benefits (for CLI)
Enables secure agent & Copilot scenarios
Supports policy differentiation (human vs agent)
Keeps existing auth model unchanged (non-breaking)
Aligns with Build / MCP / AI-first direction
Notes / Limitations
Current approach is caller-asserted (not strongly enforced)
Based on env var propagation (can be spoofed)
Future improvements may include:
process tree tracking
trusted execution context
Minimum API Version Required
MSAL and ESTS provide
Swagger PR link / SDK link
MSAL and ESTS provide
Request Example
No response
Target Date
2026-5-15
PM Contact
Scott Addie
Engineer Contact
Nikhil Reddy Boreddy, Iulian Cociug, Ashock
Additional context
No response