AI context portability is becoming a core identity governance issue

At a glance

What this is: This is an analysis of how local AI session state breaks portability, continuity, and shared context across tools, devices, and model providers.

Why it matters: It matters because AI context is becoming part of the identity and access surface, and IAM teams need patterns that preserve governance when agents, humans, and workflows move between tools.

By the numbers:

• MiniMax M2.5 costs 20x less than Claude Opus for some use cases, showing how routing choices affect operating cost.

👉 Read WorkOS's guide to preserving AI context across devices and providers

Context

AI context portability is the ability to move conversation history, project knowledge, and workflow state between tools and devices without losing continuity. In this article, the problem is not model quality but custody of context: when the state lives inside one client on one machine, governance disappears the moment the environment changes.

That creates a familiar identity governance problem in a new form. If knowledge, task state, and operational instructions are trapped inside a tool, the organisation cannot review, version, recover, or reuse them reliably. Externalising that context into files, repos, and connected systems turns AI usage from fragile session memory into something closer to managed identity infrastructure.

The starting point described here is practical rather than theoretical. The article argues for durable, agent-agnostic storage across Obsidian, Linear, git, and MCP-connected services, which is typical of where serious AI usage is heading, even if many teams are still relying on local session state today.

Key questions

Q: How should teams preserve AI context across devices and model providers?

A: Store project knowledge, task state, and agent instructions in durable systems such as markdown files, git repos, and governed task platforms instead of keeping them inside chat sessions. Then connect tools to that shared state through controlled integrations so a device change or provider outage does not erase the working context.

Q: Why does local AI session state create governance risk?

A: Local session state is risky because it is not portable, not reviewable, and not recoverable across tools or devices. That makes it hard to audit what the AI knew, what it changed, and who could access the context, which turns convenience into an unmanaged control gap.

Q: What do security teams get wrong about AI memory and context?

A: Teams often assume built-in memory is equivalent to managed knowledge, but it is usually just product-specific storage. The mistake is relying on vendor-held session data for persistent work instead of creating a governed source of truth that can survive outages, migrations, and tool changes.

Q: What should organisations do when AI workflows depend on multiple tools?

A: Define one source of truth for context, then allow each tool to read and write only through approved connectors. That reduces drift between agents, keeps task state aligned, and prevents a single client from becoming the hidden owner of the organisation's AI working memory.

Technical breakdown

Local session state and the portability problem

Most AI tools treat session state as client-local storage, which means the working context is tied to one application instance on one device. That model is fine for short-lived chat, but it fails for persistent work because the same context cannot be reloaded by another tool, audited independently, or recovered after a provider outage. The deeper technical issue is that session memory is not an interoperability layer. It is a product-specific cache, so continuity depends on one vendor's storage design instead of on a shared source of truth.

Practical implication: Treat local session history as disposable interaction data, not as an operational system of record.

Externalised context through markdown, git, and MCP

The article's core mechanism is to move context into plain text files, version-controlled repositories, and MCP-accessible systems. Markdown in git gives history, portability, and rollback. An Obsidian vault gives linked knowledge that is still just files on disk. MCP then exposes those stores to agents without forcing the context to live inside the model client. This is a structural shift from embedded memory to governed context: the AI reads and writes to data you control, rather than owning the data itself.

Practical implication: Build AI workflows around durable files, repos, and controlled connectors so context survives client changes and outages.

Model routing and provider failover

Once context is externalised, the model layer becomes interchangeable. Routing layers such as OpenRouter let a workflow fail over across multiple providers or model families without moving the underlying project state. Technically, this decouples state from inference. That separation matters because the model can change, fail, or become too expensive while the same source data and task records remain intact. The article's point is not that routing solves governance, but that routing only becomes safe once the context is already external and portable.

Practical implication: Separate model selection from context storage so provider outages do not become business continuity failures.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context portability is now an identity governance problem, not just a productivity preference. When AI work depends on local session state, the organisation has no durable control over what was seen, edited, or carried forward. That creates a governance gap across auditability, recoverability, and delegation because the context is trapped inside a single client. Practitioners should treat context as a managed asset, not a chat transcript.

Externalised context creates a new control plane for non-human identity. Once Obsidian, Linear, git, and MCP-connected systems become the source of truth, the governance question shifts from preserving a conversation to controlling who and what can read, write, and reuse operational context. This aligns closely with OWASP-NHI and zero-trust thinking because access is now distributed across tools, repos, and connectors. The implication is that AI systems are only as governable as the stores they depend on.

Named concept: context custody debt. The article exposes a recurring failure mode where teams accumulate knowledge inside vendor-held session state that cannot be exported, reviewed, or reused elsewhere. That debt grows each time a team treats conversational memory as persistent infrastructure. The practitioner takeaway is simple: if the context cannot be moved, versioned, and recovered, it is already a governance liability.

Multi-agent work makes shared state more important than model quality. The article shows why one agent researching while another implements is only safe when both draw from the same governed source of truth. That is an operational pattern, not a feature request. For identity teams, the lesson is that composable AI requires composable context, otherwise access decisions, task state, and knowledge drift apart.

Provider switching changes the risk profile of AI operations. Routing across multiple models can improve resilience, but it also creates more places where secrets, context, and tool permissions must be controlled. In practice, this means the governance programme has to look beyond the model and inspect the connected stores, API keys, and workflow boundaries that make failover possible. Practitioners should govern the full AI execution path, not just the client interface.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For context on related identity exposure patterns, see LLMjacking: How Attackers Hijack AI Using Compromised NHIs for how exposed credentials can be abused fast.

What this signals

Context custody debt: organisations that keep AI working state inside vendor clients accumulate a hidden dependency that becomes visible only during migration, outage, or provider switching. The governance response is to treat context stores as first-class identity assets, with access boundaries, version history, and recovery paths built in from the start.

The rise of externalised AI context also pushes IAM teams toward policy for connectors, not just users. Once agents can read and write to repositories, task systems, and note stores, the control question becomes whether those paths are scoped, logged, and revocable in the same way as any other privileged integration. That is where zero standing privilege thinking starts to matter for AI workflows.

For practitioners

• Move operational context into durable files and repos Store project notes, decisions, and instructions in markdown files under version control so they can be reused across tools and restored after outages. Use git history as the record of changes instead of depending on chat history.
• Treat MCP connections as governed access paths Review every MCP server as a connector with read and write authority over context stores, then scope permissions to the minimum needed for the task. Preserve separate access boundaries for notes, tickets, and code.
• Separate model choice from source-of-truth storage Keep task state, knowledge, and automation inputs in systems you control, then let routing layers or different clients consume that state. This avoids tying continuity to a single provider or device.
• Create a dedicated skills repository for agent-built tools Keep custom scripts, workflows, and agent skills in a private repository so they can be reviewed, reused, and rolled back independently of any single AI client. That repository should be the operational memory for reusable automation.

Key takeaways

• AI session memory becomes a governance liability when it is trapped inside one client or device.
• Externalising context into files, repos, and governed integrations creates portability, auditability, and recovery.
• IAM teams should manage AI connectors and source-of-truth stores as part of the identity control plane.

Key terms

• Context portability: Context portability is the ability to move AI working state across devices, tools, and model providers without losing continuity. In practice, it means notes, tasks, and instructions live in durable systems rather than in one client’s session memory, so work can resume under different tools with the same operational context.
• Source of truth: A source of truth is the authoritative store that holds the current, trusted version of project state or operational knowledge. For AI workflows, it should be a controlled system such as a repository, task platform, or note vault that agents can read and update through governed access paths.
• MCP connector: An MCP connector is a protocol-based integration that lets an AI agent access external tools and data sources. It matters for governance because the connector becomes an access path into files, tickets, or knowledge stores, which means permissions, logging, and revocation need to be managed deliberately.
• Context custody debt: Context custody debt is the accumulation of risk created when organisations keep AI memory inside vendor-held sessions that cannot be exported, versioned, or recovered. The debt shows up during outages, migrations, or team handoffs, when the missing context becomes a productivity loss and a control failure.

Deepen your knowledge

AI context portability and governed connector design are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building reusable AI workflows across devices and providers, it is worth exploring.

This post draws on content published by WorkOS: How to preserve your AI context across devices, outages, and model providers. Read the original.