Project memory poisoning happens when an attacker writes malicious instructions into persistent memory used by an AI agent. The payload survives session boundaries and can influence later actions even after the original malicious skill or prompt is removed.
Expanded Definition
Project memory poisoning is a persistence attack against an AI agent’s memory layer, where malicious instructions are written into retained context and later re-used as if they were trustworthy project knowledge. Unlike a one-off prompt injection, the payload survives session boundaries and can continue shaping tool use, task planning, or response behavior after the original source is gone.
In NHI security, this matters because the memory store becomes part of the agent’s trusted operating environment, not just a passive note buffer. Definitions vary across vendors because some systems treat memory as a retrieval index, while others use it as a long-lived state engine. Either way, the security question is the same: who can write, validate, and expire the content that future agent runs will consume? OWASP’s OWASP Top 10 for Agentic Applications 2026 is a useful reference for thinking about persistent-agent attack paths, while NHI governance must treat memory as an access-controlled asset.
The most common misapplication is assuming that deleting the malicious prompt or skill eliminates the risk, which occurs when the poisoned instruction has already been persisted into shared project memory.
Examples and Use Cases
Implementing project memory rigorously often introduces more review overhead and tighter write controls, requiring organisations to weigh agent adaptability against the cost of memory validation.
- An attacker plants a “helpful” preference in team memory so the agent later prioritises exfiltration-prone tools during routine workflow automation.
- A poisoned project note tells the agent to trust a fake internal endpoint, causing later tasks to route secrets or API keys to an attacker-controlled service.
- A compromised integration writes a false approval rule into memory, and the agent keeps honoring it even after the integration token is revoked.
- Security teams use a quarantined memory review process to detect stale or adversarial instructions before the agent can reuse them in production.
The Ultimate Guide to NHIs is relevant here because persistent memory should be governed with the same discipline as other non-human identity assets, especially where long-lived credentials, workflow permissions, and trust boundaries overlap. SPIFFE-style identity principles and the OWASP agentic guidance both reinforce the need to separate authenticated write paths from routine agent consumption, even when the memory content looks internal and benign.
Why It Matters in NHI Security
Project memory poisoning turns a temporary compromise into a durable control failure. Once malicious content is stored, it can steer future agent actions without any active attacker present, which makes incident containment slower and attribution harder. That is especially dangerous when the agent can invoke tools, handle secrets, or act on behalf of a service account. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is exactly why poisoned memory should never be allowed to influence secret handling or approval logic.
This risk also intersects with NHI governance because memory may become the hidden path by which excessive privilege is exercised, even after the original access route is removed. The Ultimate Guide to NHIs highlights how widespread NHI exposure and weak lifecycle controls create conditions where persistence attacks can linger unnoticed. Organisations that rely on agent memory without provenance checks, expiration rules, and write authorization are effectively trusting unvetted instructions as policy. Practitioners typically encounter the operational impact only after an agent repeats a bad action, at which point project memory poisoning becomes impossible to ignore and urgent to remediate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | N/A | Covers agent memory abuse and persistent prompt-injection attack paths. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses governance of secrets and trust boundaries in NHI workflows. |
| NIST CSF 2.0 | PR.AC-3 | Aligns with access enforcement for systems that store and reuse trusted state. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous validation of trust in reused context and state. |
| NIST AI RMF | Addresses harmful persistent model behavior and lifecycle risk management. |
Re-authenticate high-impact agent actions even when they are driven by stored memory.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
