microsoft / microsoft/agent-framework

.NET: Avoid IHttpContextAccessor dependency for claims-based agent isolation

Open
#7,701 0 comments 0 reactions 1 assignee View on GitHub

@rogerbarreto is already working on this.

Since Aug 18, 2026.

.NET
Dominant language
Python
Stars
13.6k
Forks
2.3k
Avg merge
2d 45m
Merged PRs (30d)
358

Description

## Problem

The ASP.NET Core claims-based session isolation implementation depends on `IHttpContextAccessor`:

- `ClaimsIdentityAgentIsolationKeyProvider` reads `HttpContext.User` through the accessor.
- `UseClaimsBasedAgentIsolation()` resolves the accessor with `GetRequiredService()`.
- Applications must therefore call `services.AddHttpContextAccessor()` or session-store resolution fails at runtime.

This introduces an ambient `HttpContext` dependency into the hosting infrastructure. ASP.NET Core guidance recommends avoiding `IHttpContextAccessor` when request data can instead be passed explicitly because it relies on `AsyncLocal`, complicates testing, and creates a dependency on ambient state.

Registering `IHttpContextAccessor` inside `UseClaimsBasedAgentIsolation()` would remove the extra application setup, but it wouldn't address the underlying ambient-context dependency.

## Requested investigation

Can claims-based agent isolation receive the authenticated principal or resolved isolation key explicitly from the protocol request pipeline instead of reading it through `IHttpContextAccessor`?

The design should ideally:

- Avoid requiring `AddHttpContextAccessor()` for claims-based isolation.
- Avoid introducing another ambient-context abstraction with the same characteristics.
- Continue to isolate session and task stores consistently across the ASP.NET Core protocol integrations.
- Preserve a viable path for non-HTTP hosts and custom `AgentIsolationKeyProvider` implementations.
- Define expected behavior when agent execution continues outside the original HTTP request.

If explicit propagation isn't practical with the current `AgentIsolationKeyProvider` and store contracts, it would be useful to document the constraint and evaluate whether those contracts should carry request or execution context.

## Current API

```csharp
builder.Services.AddHttpContextAccessor();
builder.Services.UseClaimsBasedAgentIsolation();
```

Relevant source:

- `dotnet/src/Microsoft.Agents.AI.Hosting.AspNetCore/ClaimsIdentityAgentIsolationKeyProvider.cs`
- `dotnet/src/Microsoft.Agents.AI.Hosting.AspNetCore/ServiceCollectionExtensions.cs`
- `dotnet/src/Microsoft.Agents.AI.Hosting/AgentIsolationKeyProvider.cs`

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.