diff --git a/dotnet/samples/02-agents/AGUI/README.md b/dotnet/samples/02-agents/AGUI/README.md
index 77a58b3198c..c02902b3e6b 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 4bdfa9221e9..0f73d0fb423 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 68850bea640..2cc2cd90875 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: