Agent Memory Errors Handbook: Cases 76–80
This installment is part of the Agent Memory Errors: 100 Cases Handbook series.
Case 76: Cross-session & User Identity Errors — Impersonation Via Session Hijacking
Scenario
The user’s session token is passed through URL parameters (rather than Cookie/Header). The user shares a link containing the token on social media. An attacker clicks the link and obtains the user’s session identity.
Error Manifestation
The attacker talks with the Agent as the user, views all the user’s historical memories, and even performs sensitive operations through the Agent (e.g., “Delete all my data”).
Solution
- Never pass session tokens through URLs; use HttpOnly Cookie or Authorization Header
- Implement device fingerprint binding: bind sessions to device fingerprints; require re-authentication when device changes are detected
- Perform dual confirmation for sensitive operations: even if the session is valid, require password re-entry for delete, transfer, and similar operations
Principle
Leakage of session identifiers equals leakage of identity. URLs are the most easily leaked medium (browser history, shared links, Referrer headers). Secure session management is the foundation of identity security.
Case 77: Cross-session & User Identity Errors — User Deletion Memory Residual
Scenario
The user exercises the right to be forgotten and requests account deletion. The system deletes the record in the user table, but the Agent’s long-term memory library (vector database) still retains a large number of that user’s memory vectors. Because the memory library has no cascade deletion mechanism, this data becomes “orphan memory.”
Error Manifestation
Months later, other users’ queries accidentally retrieve these orphan memories (because they are similar in vector space to new queries), containing the deleted user’s personal information.
Solution
- Establish a “user-memory” foreign key relationship: trigger cascade deletion when deleting users, cleaning all associated memories
- Implement memory ownership tags: tag each memory with its owner user ID, regularly scan and clean memories with invalid user IDs
- Perform memory audit after user deletion: sample check whether any data from that user remains
Principle
Regulations like GDPR require thorough deletion of user data. If memories in the vector database are not strongly associated with user identity, deletion operations are prone to omissions, causing compliance risks.
Case 78: Cross-session & User Identity Errors — Profile Merge Conflict Resolution Failure
Scenario
The user merges two accounts (work and personal) through the account merge feature. The two accounts respectively have “preferred language: English” and “preferred language: Chinese” settings. The merge system does not define a conflict resolution strategy and randomly keeps one of them.
Error Manifestation
The user expects to retain both preferences (English for work, Chinese for personal), but after merging can only use one language and doesn’t know when it was modified.
Solution
- Perform “scenario-based retention” during account merging: ask the user about preference settings in different scenarios rather than simple either/or
- Retain historical preference records: the merged profile contains “settings from source A” and “settings from source B,” allowing users to switch
- Use “most recent use first”: in conflicts keep the most recently updated setting, but notify the user of the conflict
Principle
User profile merging is not simple record concatenation but conflict resolution. Merging without clear strategies leads to silent data loss, changing user preferences without their knowledge.
Case 79: Cross-session & User Identity Errors — Session Affinity Break Load Balancer
Scenario
There is a load balancer in front of the Agent cluster configured with session affinity: requests from the same user are routed to the same instance. But one instance fails, and the load balancer routes the request to another instance. The new instance lacks the user’s session state (stored in the failed instance’s memory).
Error Manifestation
The Agent suddenly “amnesiac”; the user feels confused “Weren’t we just talking about XX?” and the experience is severely damaged.
Solution
- Store session state in shared storage (Redis/database), making instances stateless so any instance can handle any session
- Perform “state migration” when instances fail: migrate session state from the failed instance to the new instance
- Load balancer uses “sticky cookie”: even when instances change, session can be restored through central storage
Principle
Scalability and reliability of stateful services are limited by where state is stored. Stateless architecture with external state storage is best practice for distributed systems.
Case 80: Cross-session & User Identity Errors — Anonymous User Tracking Ethics Violation
Scenario
The Agent builds “device fingerprint + behavior pattern” memory profiles for anonymous users (not logged in) for personalized recommendations. Through long-term tracking, the system can highly accurately identify the same anonymous user (e.g., “User of Chrome 120, 1920x1080 resolution, who browses tech before finance”).
Error Manifestation
Attackers or third parties correlate these anonymous profiles with real identities through data association (e.g., after a user logs in somewhere, the system can associate pre- and post-login behavior), achieving de-anonymization.
Solution
- Set strict limits on anonymous user tracking: only record session-level information, do not build cross-session long-term profiles
- Regularly reset anonymous user identifiers (e.g., reset after each browser close)
- Implement differential privacy: inject noise into anonymous user data to prevent precise identification
Principle
De-anonymization research shows that sufficiently multi-dimensional behavior data can uniquely identify individuals. Being anonymous should not just mean “not recording names”; it should ensure identity cannot be inferred from the data.
Source: Agent Search