A Backend for Frontend pattern limits browsers from reusing a Microsoft Foundry Responses conversation identifier. Instead of sending a raw provider response ID, the browser receives a signed continuation token bound to the authenticated user's subject, the upstream mode, and the agent endpoint. The BFF signs this with HMAC-SHA256 and rejects a raw previous_response_id or agent_session_id sent by the browser. Tokens are issued only after a response completes, not just when visible text streams in. A local offline test run covering the continuation and Responses modules passed 51 tests, with seven telemetry tests deselected. The example comes from a banking-assistant prototype that extends Microsoft's public banking-assistant sample.
Table of contents
A response identifier is not proof of ownershipWhere Agent Framework, Foundry, and the BFF fitLet the BFF issue the continuationWhat the signature checksWait until the response really finishesWhat the tests demonstrateThe trade-off: permission to continue, not a checkpointImplementation and referencesQuestions this post answers
How do I prevent one user from continuing another user's conversation when using previous_response_id in Microsoft Foundry's Responses API?
Issue a signed continuation token from a Backend for Frontend instead of exposing the raw previous_response_id to the browser. The token is signed with HMAC-SHA256 and binds the response identifier to the authenticated user's subject, the upstream mode (local or Foundry), and the configured agent endpoint, so a token copied by another user fails validation. Developers securing multi-turn AI agent chat can track patterns like this BFF token design on daily.dev.
What should a BFF do if an SSE stream ends without a clear completion signal before issuing a conversation continuation token?
It should not issue a new continuation token. If iteration ends normally with a successful HTTP status but no confirmed completion, the BFF emits a CONTINUATION_UNAVAILABLE event with allow_retry set to false. Transport exceptions or non-success HTTP responses also skip that control event entirely, avoiding a token tied to an uncertain or unfinished response. Teams building streaming agent backends can follow practical reliability patterns like this on daily.dev.
Why shouldn't I rely on Base64URL encoding alone to protect a provider's response identifier in a conversation token?
Base64URL encoding is not encryption, so the response identifier inside the token is not secret, and provider output may expose identifiers elsewhere anyway. The actual protection comes from refusing to accept any raw identifier as sufficient authority from the browser, requiring a valid HMAC-SHA256 signature tied to the user and destination instead. Engineers hardening token-based API auth can keep up with these design trade-offs on daily.dev.