Compare commits

...

3 Commits

Author SHA1 Message Date
chetantoshniwal ac35a5e061 Merge branch 'main' into sreagent/docs-identifier-guidance-20260614 2026-06-28 19:03:57 -07:00
Evan Mattson c2ee27ee67 Merge branch 'main' into sreagent/docs-identifier-guidance-20260614 2026-06-18 10:39:46 +09:00
Azure SRE Agent 43aaf58821 [Generated by SRE Agent] Clarify identifier security guidance
Co-authored-by: Azure SRE Agent <noreply@microsoft.com>
2026-06-14 06:27:55 +00:00
3 changed files with 16 additions and 0 deletions
+6
View File
@@ -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
+6
View File
@@ -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.
@@ -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: