Your memory layer needs a frequency detector

Most discussions of memory security focus on what gets in. A poisoned document, an adversarial prompt, a false claim inserted into a retrieval pipeline. The threat model is about the quality of individual writes.

There's a second threat model that doesn't get the same attention: volume and repetition from a single source. An attacker who can't win with one false claim can try to build apparent consensus by filing the same claim across multiple sessions. The memory layer sees what looks like independent corroboration — multiple entries asserting the same thing — when it's actually one source echoing itself.

OWASP's ASI06 analysis names this the repeated-reinforcement pattern, and it's worth understanding why it works so well.

Why repetition is dangerous in memory systems

Memory retrieval systems are, by design, biased toward frequently retrieved content. An entry that appears in more searches, gets referenced more often, and accumulates more connections is structurally more significant than one that was filed once and never retrieved again. This is a feature, not a bug — it's how the system surfaces what's actually load-bearing in the knowledge graph.

The repeated-reinforcement attack exploits this bias deliberately. The attacker doesn't need to change the node_kind, forge a human owner, or bypass authentication. They only need the same agent to file semantically similar claims to the same domain multiple times. Each filing reinforces the others. The claim becomes structurally significant through repetition rather than through legitimacy.

The graph looks coherent from the inside. Multiple nodes assert the same thing. They're well-connected to each other. Trust scores look reasonable because connected nodes agree. The corruption is in the frequency distribution, not in any single node.

The signal is already in the data

This is the part that's easy to miss: the audit log already captures everything needed to detect this pattern.

Every write to Recordari is logged with full attribution — which API key made the call, which workspace owner that key belongs to, the timestamp, the domain. The audit log records remember() calls the same way it records any other operation. There's no additional instrumentation needed.

The anomaly looks like this: a single owner_id filing N nodes in domain Y within a time window Z, where the content of those nodes is semantically similar to each other. That's a specific, queryable signal. It's distinct from high write volume — an agent processing a large dataset might file many nodes legitimately. What's anomalous is the combination of same source, same domain, semantically similar content, compressed time window.

This is one of the signals the Recordari admin drift report is designed to surface. The framing is behavioral: not "this node looks wrong" but "this agent is acting strangely." The distinction matters for response. A single bad node is a data quality problem. An agent filing bad data repeatedly is an agent you need to stop.

Two signals, not one

Monitoring agent behavior in memory requires watching for both ends of the frequency distribution.

The passive signal is silence: an agent that has been writing regularly to a domain and has suddenly stopped. This can mean the agent is stuck, the integration broke, or — more concerning — the agent completed a manipulation and went quiet. A key that goes from regular writes to zero is worth investigating.

The active signal is anomalous frequency: an agent writing at unusual rate or with unusual repetition. The threshold isn't absolute — some workflows legitimately produce high write volume. The relevant comparison is against that agent's own baseline. A key that writes twice a day, every day, and then files forty nodes in an hour to the same domain is behaving differently. That change in pattern is the signal.

Together these give a workspace owner a behavioral view of what their agents are actually doing in memory — not just what got written, but whether the pattern of writing makes sense. Post-incident forensics is still possible with just the audit log. The drift report makes behavioral anomalies visible before the incident.

What this doesn't catch

Write frequency can't tell you whether an individual node is true or false. A high-frequency anomaly is a reason to investigate; it isn't itself evidence of poisoning. The response to a flagged pattern should be human review, not automatic quarantine.

And the inverse doesn't hold either: a slow, patient attacker who files one false claim per week will not trigger a frequency anomaly. The repeated-reinforcement signal is effective against the bulk-and-persist attack pattern. Targeted, low-volume manipulation requires different mitigations — primarily write validation and provenance tracking, which are complementary layers, not substitutes.

The frequency detector is one instrument in the audit toolkit. It's the one most likely to catch an automated attack that's moving fast, and it requires no additional engineering beyond the audit log that should already be there.

---

References: OWASP Agentic AI Threats and Mitigations — ASI06: Memory and Context Poisoning