On November 2, 2026, Anthropic launched message threads in public beta. An agent can send its conversation once, then submit new messages with the previous response ID. The API reconstructs the history for the model. This reduces repeated uploads in long sessions; it does not reduce the conversation the model reads or automatically lower token usage.
For a service handling several customers, a failed continuation can lead to another upload of private history. Before resending it, verify the destination workspace and the identity making the request. Stop if the credentials no longer match the conversation's owner.
This guide proposes an application policy for that boundary. We have not tested a live integration or demonstrated a vulnerability in Anthropic's service.
Approve the storage behavior first#
Anthropic's data-retention reference lists message threads as ineligible for Zero Data Retention and HIPAA-ready use. Thread contents remain in memory, encrypted with a server-managed key, without durable storage, and are deleted within one hour of last use. Other eligible API features keep their own eligibility.
Keep that deletion deadline separate from the five-minute inactivity expiry described in the launch announcement. An unusable thread is not evidence that every copy of the conversation has been deleted. Your application's transcript, logs, and tool records need their own retention rules.
For a rollout, record the permitted data classes and provider path beside the integration approval. Reject thread use for a workflow whose requirements exclude this storage. Do the check where requests are constructed so a new caller cannot enable the feature merely by changing an SDK option.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Bind the conversation before sending it#
The thread recovery contract gives thread_not_found several possible causes, including expiry and a different organization, workspace, or creating identity. The error does not identify the cause. The SDK helper can replay the full history in a new create request automatically.
Check whether credentials or routing can change while a helper still holds a conversation. Shared clients, background queues, failover routing, and credential refresh all need review. Keep the binding immutable for that conversation. Check it before calling a helper that may resend history internally; a handler that runs only after the helper returns can be too late.
On the direct Claude API, authentication rules require anthropic-workspace-id on each request when the API key is not workspace-scoped. Personal and service-account keys act as those identities; legacy workspace keys have different ownership semantics. Obtain identity and workspace mappings from trusted configuration, not a model-generated tool argument or an unverified user label.
The following is an illustrative record in your application's database. These are invented identifiers and application fields, not Claude API parameters. Keep secrets in the credential store; save only a reference here.
Code source: illustrative
{
"conversation_id": "example-conversation-42",
"tenant_id": "example-customer-a",
"provider_binding": {
"endpoint": "https://api.anthropic.com",
"organization_id": "example-org-a",
"workspace_id": "example-workspace-a",
"principal_id": "example-service-account-a",
"credential_ref": "secret-store/agents/customer-a"
},
"policy_revision": "example-policy-7",
"transcript_ref": "private-store/conversations/42",
"last_response_id": "example-response-id",
"pending_operation_id": null
}
Authorize access to this record before loading its transcript. Compare its provider binding with the credentials actually resolved for the outgoing request, including any gateway's downstream routing. A matching secret-store path is insufficient if someone replaced its value with a different account's key.
Credential rotation needs a documented decision. Confirm the replacement's principal and workspace before using the existing conversation. If that identity cannot be established, stop and investigate. Moving to another account or provider should require a separately approved transfer with a recorded destination and allowed history.
Decide whether recovery may send history#
For explicit recovery, inspect error.details.error_code; an unrelated 404 does not establish a thread failure. Create requests use thread.type: "create"; continuation uses thread.type: "continue" and previous_message_id. Send message-threads-2026-08-12. The reference requires system and tools only at creation and matching fixed fields on later turns.
Use the table below as a recommended application policy. It adds checks around API recovery; it is not a list of protections Anthropic applies on your behalf.
| Condition at recovery | Recommended decision |
|---|---|
| Binding matches; access and data policy remain valid | Recover from the authorized stored history; keep a record of the decision. |
| Workspace, principal, tenant, or destination differs | Stop before transmitting history. Resolve routing or approve a separate migration. |
| Credential reference matches but resolved identity is unknown | Hold recovery until the credential owner can establish the identity. |
| User lost access to this conversation | Deny transcript loading and further requests, even if the service credential still works. |
| Approved tool definitions or policy changed | Build a newly reviewed configuration; do not silently preserve outdated authority. |
| Earlier consequential action has an uncertain outcome | Reconcile the action before allowing another attempt. |
Take a hypothetical support service that reuses a mutable API client for two customer queues. Queue B changes the workspace header while queue A retains a transcript. The acceptance condition is that A's next request fails the application's binding check before any network transmission. This is a scenario to test with synthetic data, not an observed product defect.
Use a client and conversation lifecycle that makes such mixing difficult. Serialize changes to the conversation record and its active request, or use an equivalent concurrency control. A check performed against configuration that another worker can replace immediately afterward does not protect the outgoing request.
Check tool effects separately#
For client tools, the application executes the requested action and returns a tool_result linked to its tool_use_id. Anthropic's tool-call handling guide explains that exchange. Use current authorization at execution time, including resource ownership and any required human approval.
Consider a document-delivery tool that sent a report before the connection failed. Keep the destination's operation ID and result outside the model conversation. If recovery produces another delivery request, compare it with that record. Use the destination's documented idempotency mechanism where available. Where the effect remains unknown, require reconciliation instead of assuming the failed response means nothing happened.
Our MCP cancellation guide covers this uncertain-outcome decision for server-owned tasks. The MCP security baseline covers authorization at the service boundary. Neither a restored transcript nor an old tool definition grants continuing permission to act.
Verify the boundary before rollout#
Use synthetic conversations and tools that cannot send real messages or modify production data. Record expected and observed outcomes separately:
- Change the test workspace while retaining the original conversation. Confirm that the application sends no history under the replacement binding.
- Rotate the credential reference to a different test principal. Confirm that the resolved identity check catches the change.
- Remove a test user's conversation access while leaving the service account active. Confirm that transcript loading and recovery stop.
- Let a disposable thread expire under an unchanged binding. Confirm that ordinary recovery preserves the intended conversation without widening access.
- Simulate an uncertain tool result. Confirm that another consequential action waits for destination reconciliation.
Retain the decision, configuration revision, internal conversation ID, and destination operation evidence. Avoid copying private history into every diagnostic log. If definitions change during recovery, use a reviewed snapshot as described in the MCP tool-list pinning guide.
Keep the rollout blocked if a workspace change can send the old transcript before your application checks it.
Frequently asked questions
- Should a thread error trigger a retry with another account?
No. First compare the request's destination, workspace, and identity with the conversation's saved binding. Moving history to another account is a separate data-transfer decision. A successful request with that account would not prove that the transfer was authorized.
- Does replaying a conversation authorize another tool action?
No. Check current resource permissions and any required approval at the service performing the action. If an earlier action has an uncertain outcome, reconcile its destination record before retrying it.
