TwinEthosRequest access

Control

Cached AI responses or per-user AI state not scoped to the requester

Every cache that stores model responses, prompts, embeddings, or per-user session state is keyed by the requesting user or tenant, and every cache read is checked against the requester before it is served.

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Family: AI controls are not preserved under cost, latency, or model-change pressure · control id cond.ai-response-cache-not-scoped-to-requester

Reach

1items this one guard addresses
0jurisdictions where binding law on it is in force
0more where it is enacted, not yet applying
0standards and frameworks on the same control

The guard to add

Key every cache of model responses, embeddings, or session state by tenant and user, and check the stored owner against the requester on each read before serving it.

In the cache layer in front of the model call or the conversation store, build every key from the tenant id and user id plus the content digest, so identical prompts from different users never share an entry, and store the owner id with each entry. On read, compare the stored owner with the authenticated requester and treat a mismatch as a miss (or a 404 for history). Do not install a process-wide LLM cache (LangChain set_llm_cache, @lru_cache on a function whose output carries user data) for user-specific answers; a shared cache is acceptable only for content derived from non-personal inputs that every user receives alike.

Where it goes: 1 application source code, 2 data models, 9 AI output handling.

What reviewers look for: cache keys built like f"{tenant_id}:{user_id}:{digest}" rather than hash(prompt) alone or a semantic_cache.lookup(query) shared by all users; an owner == current_user.id check before a cached reply or session history is returned; no global set_llm_cache(InMemoryCache()), RedisCache, RedisSemanticCache, or @lru_cache serving personalized output.

Example (Python + redis-py), before:

key = 'resp:' + hashlib.sha256(prompt.encode()).hexdigest()
if (cached := r.get(key)) is not None:
    return {'reply': cached.decode()}
reply = ask_model(user, prompt)
r.set(key, reply, ex=3600)

After:

digest = hashlib.sha256(prompt.encode()).hexdigest()
key = f'resp:{user.tenant_id}:{user.id}:{digest}'
if (cached := r.get(key)) is not None:
    return {'reply': cached.decode()}
reply = ask_model(user, prompt)
r.set(key, reply, ex=3600)

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.

Every rule this guard addresses

TwinEthos recommendation (not law) (1)

Related incidents

  • Prompt caches shared across all users at several LLM API providers (2024-09; confirmed). Stanford researchers auditing LLM APIs by timing measurements in September–October 2024 report prompt-cache sharing across all users at seven providers, creating a timing side channel that could leak information about other users' prompts. They report disclosing to providers in October 2024 and that at least five mitigated, e.g. by scoping caches per organization. The paper reports a vulnerability, not observed exploitation. Source: Gu et al., 'Auditing Prompt Caching in Language Model APIs' (original researchers) · evidence grade: primary · cited by Scope every AI response and session cache to the requesting user or tenant
  • ChatGPT cache bug exposed other users' chat titles and payment details (2023-03-20; disclosed by the operator). OpenAI reports that a server change on March 20, 2023 triggered a bug in the redis-py client, so its user-information cache returned other users' data: some users saw another active user's chat-history titles, and payment details (name, email, address, card type, last four digits, expiry; not full card numbers) of 1.2% of ChatGPT Plus subscribers active in a nine-hour window may have been exposed. OpenAI's remediation added checks that data returned by the cache matches the requesting user. Source: OpenAI (operator postmortem, 2023-03-24) · evidence grade: primary · cited by Scope every AI response and session cache to the requesting user or tenant