Who is accountable when an AI assistant memory poisoning incident affects code or systems?

Why This Matters for Security Teams

Memory poisoning is not just a model-quality issue. When an AI assistant uses retained context to generate code, modify infrastructure, or trigger downstream actions, poisoned memory can become an execution path into production systems. That makes the question of accountability operational, not theoretical: the programme that owns the authenticated AI session, the browser controls, and the execution environment must answer for the blast radius. The risk is amplified when credentials, prompts, and action history are stored in loosely governed session state.

NHIMG research on 52 NHI Breaches Analysis shows how identity abuse and credential exposure repeatedly turn trusted automation into an attacker’s foothold. External guidance is converging on the same point: OWASP Top 10 for Agentic Applications 2026 treats tool abuse, unsafe autonomy, and weak session governance as first-class risks, not edge cases. In practice, many security teams discover that ownership is unclear only after an assistant has already written code, called APIs, or changed a system with poisoned context.

How It Works in Practice

Accountability should follow control, not just intention. If an AI assistant can remember prior interactions, retrieve files, and execute tools, then the owning team needs defined responsibility for session authentication, memory governance, prompt injection defenses, and downstream approvals. The useful question is not “who built the model?” but “who controlled the session, memory store, and execution path at the time the action occurred?”

Practically, that means separating duties across the layers that matter most:

• The identity layer: who or what authenticated the session, and under what trust boundary.
• The memory layer: what content was retained, who could write to it, and whether poisoned entries were validated before reuse.
• The browser or agent layer: what tools, tabs, or plugins were reachable from the session.
• The execution layer: what code, pipelines, or infrastructure changes the assistant could trigger.

This model aligns with NHIMG’s guidance in the DeepSeek breach, where exposed secrets and sensitive records showed how quickly AI-adjacent exposure becomes an enterprise incident. It also maps to Anthropic’s report on AI-orchestrated cyber espionage, which demonstrates that autonomous workflows can chain actions in ways human reviewers do not anticipate. A sane control model uses explicit session owners, immutable audit trails, human approval for high-risk actions, and rapid revocation of memory or tool access when poisoning is suspected.

For code and systems work, current guidance suggests treating assistant memory as a governed input channel, not a trusted source of truth. Best practice is evolving toward per-session scoping, content provenance checks, and policy-based approval before any code generation is committed or any infrastructure command is executed. These controls tend to break down in shared developer environments with loosely separated browser sessions and broad CI/CD permissions because poisoned memory can jump from a chat context into automated execution without a clear decision point.

Common Variations and Edge Cases

Tighter session governance often increases operational overhead, requiring organisations to balance fast developer workflows against stronger accountability and review. That tradeoff becomes especially visible when assistants are used in IDEs, shared browsers, or multi-agent pipelines where one poisoned memory object can influence several systems at once.

There is no universal standard for assigning blame in these incidents, but current guidance suggests a few stable patterns. If the assistant was embedded in a product team workflow, the product or platform owner is usually accountable for the control failure. If the incident involved shared enterprise identity, the IAM or platform security function shares accountability for session trust and access boundaries. If the assistant could deploy code or modify cloud resources, the team operating that execution environment must own the approval gates and revocation path.

Edge cases matter. A read-only assistant still becomes high risk if its memory can be used later to influence a privileged workflow. A well-logged system can still fail if logs do not capture the memory source that shaped the action. And if multiple teams split browser, identity, and runtime ownership, the control gap is itself the incident. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now is clear that fragmented ownership creates hidden risk, especially when secrets and identities move faster than governance. In practice, most organisations do not find the accountability gap through design reviews; they find it after an assistant has already touched code, systems, or credentials.

Related resources from NHI Mgmt Group

• Who should be accountable when an identity failure affects critical infrastructure or delegated AI access?
• Who is accountable when an AI assistant surfaces private code from a cached repository?
• Who is accountable when a vulnerable database leaks sensitive memory?
• How should security teams govern AI systems used in classified or disconnected environments?