# Agent Memory Hook Package Installation

- **Severity:** Medium
- **Signature ID:** `7b3f1c2e-9d84-4a5f-b6c1-2e8a4f0d51c7`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise), AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** LLM03 (Supply Chain)

## Summary

This rule watches for command lines that install packages or write config files aimed at giving Claude Code, Codex, or Grok persistent memory or hook-based behavior. It flags the installation step itself, not proof that memory was actually written or agent behavior was actually changed.

## How the attack works

An agent, or a process it spawned, runs a command that either installs an npm-ecosystem package whose name references one of these coding-assistant platforms together with a memory/context-compression feature, or writes to a known agent config/hook location (like ~/.claude/settings.json, ~/.claude/hooks, ~/.codex/config.toml, ~/.config/grok) while the same command line contains a memory/compaction/persistence keyword. This pattern matters because agent hooks and memory plugins can be used to make an agent retain attacker-influenced context or run attacker-supplied code on every future session. The rule requires three independent matching tokens in one command line, so ordinary package installs or generic script execution won't trigger it.

## Why it matters

If real, this step can let an attacker embed a persistent hook or memory module into a developer's AI coding assistant, giving them a foothold that survives across sessions and could influence or exfiltrate future agent activity. The rule only confirms the installation command was run — it does not confirm the hook was actually registered or that agent memory was actually altered.

## What you can do

- Review any flagged installation commands manually to confirm whether the package or config change was intentional and authored by a known developer.
- Maintain an allowlist of approved memory/hook packages and config changes for your agent tooling, and treat unlisted ones as suspicious.
- Restrict write access to agent config directories (~/.claude, ~/.codex, ~/.config/grok) to trusted provisioning processes only.
- Audit installed hook/memory packages periodically to catch ones that slipped in outside of your normal onboarding or CI process.

## Known benign look-alikes

- Developer intentionally installing a memory or context MCP server / hook package for their own agent setup (e.g. an internally authored session-memory hook).
- Dotfile or machine-provisioning scripts that copy a hooks file or settings.json into ~/.claude, ~/.codex or ~/.config/grok during onboarding.
- CI images that install agent tooling whose package name legitimately contains "context" or "memory" (context7-style docs servers, memory-bank plugins).
- Backup or migration one-liners that cp/mv an existing agent settings.json while a memory-related package name happens to be on the same command line.
- Security research replaying the described npm package inside a sandbox.

## References

- https://attack.mitre.org/techniques/T1195/002/
- https://attack.mitre.org/techniques/T1546/

---
Source: https://www.netzilo.com/threats/agent-memory-hook-package-install