If you didn’t allow it, you wouldn’t be able to change models in the same conversation, as key parts of the context would be lost.
Wouldn’t surprise me if the providers just remove that ability and lock the model once the conversation starts.
Wouldn’t surprise me if the providers just remove that ability and lock the model once the conversation starts.
Sucks.
This is only required if you want users to be able to share things with everyone and you are going for the simplest implementation.
If not you could try to keep a record of keys associated with a user, then when a new request comes in look through to see if the user has a valid key to decrypt the COT.
For explicit shares, just add the key used in that one conversation to the users valid keys. For global shares use the global keys. But that's adding more complexity to the system.
LLMs briefly seemed like this too, after subscriptions made the SOTA models too cheap to meter, but before they walked back on that and introduced quotas...
1. The down side is that it cannot be used across the clients even for the same user
2. Using the same encryption key was a bad choice here, a per user key would have solved this issue for sure.
> a per user key would have solved this issue for sure
It would have helped with PII leakage, but not with plain-text trace extraction attacks, right?
The compliance rules at times are outdated and people skirt around them by following the worded rule instead of the intent.
The fix is to either have per-user or per-session keys for encrypting reasoning traces, or write the user ID / account ID and maybe also session ID into the plaintext of the reasoning trace _then check that that matches the ones in the HTTP cookies when decrypting the traces_.