From 43aaf58821c796030fa603cd99bfc3bfc0f65874 Mon Sep 17 00:00:00 2001 From: Azure SRE Agent Date: Sun, 14 Jun 2026 06:27:55 +0000 Subject: [PATCH] [Generated by SRE Agent] Clarify identifier security guidance Co-authored-by: Azure SRE Agent --- dotnet/samples/02-agents/AGUI/README.md | 6 ++++++ python/packages/a2a/README.md | 6 ++++++ .../04-hosting/azure_functions/12_workflow_hitl/README.md | 4 ++++ 3 files changed, 16 insertions(+) diff --git a/dotnet/samples/02-agents/AGUI/README.md b/dotnet/samples/02-agents/AGUI/README.md index 77a58b3198..c02902b3e6 100644 --- a/dotnet/samples/02-agents/AGUI/README.md +++ b/dotnet/samples/02-agents/AGUI/README.md @@ -224,6 +224,12 @@ dotnet run - **Thread IDs** (as `ConversationId`) for conversation context - **Run IDs** (as `ResponseId`) for tracking individual executions +## Security considerations + +`ConversationId` keeps request/response continuity. It is not proof that the caller owns that conversation. In multi-user deployments, authenticate each AG-UI request and authorize conversation access using your application's real boundary, such as the authenticated user, tenant, or workspace. + +If your ASP.NET Core host shares session storage across users, pair `MapAGUI` with an isolation strategy such as `UseClaimsBasedSessionIsolation(...)` so the storage key includes a principal-specific dimension instead of relying on the conversation identifier alone. + ## Troubleshooting ### Connection Refused diff --git a/python/packages/a2a/README.md b/python/packages/a2a/README.md index 4bdfa9221e..0f73d0fb42 100644 --- a/python/packages/a2a/README.md +++ b/python/packages/a2a/README.md @@ -56,3 +56,9 @@ See the [A2A agent examples](../../samples/04-hosting/a2a/) which demonstrate: - Sending messages and receiving responses - Handling different content types (text, files, data) - Streaming responses and real-time interaction + +## Security considerations + +The hosting example above focuses on protocol wiring and does not add authentication or authorization by itself. Production A2A hosts should protect their HTTP or JSON-RPC entry points with the deployment's normal auth layer and verify that each caller is allowed to access the requested agent, task, or session. + +Task, thread, context, and session identifiers used by an A2A host are routing handles, not bearer credentials. Do not rely on client-supplied identifiers alone to select or mutate persisted state; bind them to authenticated user, tenant, or workspace context first. diff --git a/python/samples/04-hosting/azure_functions/12_workflow_hitl/README.md b/python/samples/04-hosting/azure_functions/12_workflow_hitl/README.md index 68850bea64..2cc2cd9087 100644 --- a/python/samples/04-hosting/azure_functions/12_workflow_hitl/README.md +++ b/python/samples/04-hosting/azure_functions/12_workflow_hitl/README.md @@ -48,6 +48,10 @@ async def handle_approval_response( | `POST /api/workflow/respond/{instanceId}/{requestId}` | Send human response | | `GET /api/health` | Health check | +These routes expose workflow status and human-response operations. In production, put them behind your application's authentication and authorization layer and verify that the caller is allowed to inspect or resume the targeted workflow before returning status or accepting a response. + +Treat `instanceId` and `requestId` as correlation handles only. They help locate workflow state, but they are not secrets or proof that a caller is authorized to act on that workflow. + ### Durable Functions Integration When running on Durable Functions, the HITL pattern maps to: