Run each agent session in an isolated context: separate memory space, separate permission set, separate credential store. When a task ends, wipe the agent's working memory — credentials, retrieved data, conversation history — before the next task or session begins.

If an agent uses a vector database or long-term memory store, segment it by user and by task. One user's session should never have read or write access to another user's memory entries. Tag every memory entry with the session ID, user ID, and task that created it, and enforce access control on retrieval.

Directly eliminates Scenario 02 (memory-based escalation — the IT admin SSH credentials persisting into the next user's session). Also prevents data leakage between sessions: an agent that retrieved sensitive data for User A cannot expose it to User B if memory is properly isolated.

Memory isolation doesn't fix un-scoped delegation (Scenario 01) or cross-agent trust exploitation (Scenario 03). It only addresses the persistence of credentials and data across session boundaries. You still need MIT 01 and MIT 03 for those attack paths.

For shared agents (one agent deployment serving many users), this is a hard architectural requirement — not just a configuration option. If the underlying infrastructure doesn't support per-session memory isolation, shared agents should not be deployed with access to sensitive credentials or data.