Screen and policy-check agent memory operations

Screen and Policy-Check Agent Memory Operations

Summary

Agent memory reads and writes should be treated as policy-relevant operations. Screening memory content for prompt injection, protected-key tampering, secret leakage, anomalous size, and unexpected churn can reduce the chance that durable context steers future privileged tool use.

What It Covers

• Persistent chat histories, task scratchpads, vector stores, RAG indexes, profile memory, and long-running workflow state.
• Agent frameworks where memory content can influence file edits, shell commands, repository actions, network calls, credential selection, or external publication.
• Memory imported from untrusted or semi-trusted sources such as tool output, issue comments, documents, web pages, logs, or other agents.
• Local agent control planes that need auditable boundaries around what context is persisted, reused, redacted, quarantined, or blocked.

Why It Matters

Memory can outlive the interaction that created it. If an attacker or compromised integration can plant instructions, fake policy state, or secrets into a durable memory store, the agent may later treat that content as trusted context. That turns ordinary prompt injection into a longer-lived control surface for workflows with real files, credentials, network access, and side effects.

Control Logic

• Route memory writes through detectors for prompt-injection markers, protected-key changes, secret or token patterns, unusual size, and rapid churn.
• Route memory reads through policy checks before high-impact actions, especially when memory influences tools, credentials, shells, or external messages.
• Keep immutable or protected memory keys for identity, role, authorization, and operator policy separate from untrusted conversational context.
• Emit structured events for memory allow, redact, quarantine, block, snapshot, and rollback decisions.
• Bind memory events to explicit user, workspace, task, container, and credential scopes.
• Require human review or tighter sandboxing when old or newly imported memory is about to influence destructive or external side-effecting actions.

Armorer Applicability

Armorer could help reduce this class of risk by giving operators a local place to see and enforce memory boundaries alongside Docker isolation, credential scope, runtime activity, and approval policy. A profile could make persistent memory explicit, restrict the files and secrets a memory-backed run can reach, monitor unusual tool or file activity after memory reads, and surface health-check warnings when memory policy is absent.

This control does not claim Armorer would prevent every memory-poisoning issue. It would make durable context easier to constrain, observe, and audit before it can drive privileged actions.

Source

• OWASP Agent Memory Guard source repository
• Explicit conversation scoping for agent memory

Open Questions

• Which Armorer-managed agent profiles should require a memory policy before enabling persistent memory?
• Should memory read events be included in the same action timeline as tool calls and credential use?
• How can local monitoring capture enough context for audit without storing sensitive memory contents unnecessarily?