Red-Team Your Support Agent's Memory: A Harness for Drift, Data Exposure, and Kill-Path Recovery

An authenticated support agent is not a solved security problem. It can still drift, expose data, or get memory-poisoned after it passes the front door. Authentication only made the agent reachable.

For support-agent platform owners, appsec engineers, and AI ops leads, the question is not whether the agent can be stopped at the gateway, but whether the system can notice that the agent has changed, contain what it touched, and recover without leaving a privileged zombie behind.

The gateway is not the test

Gateways are the first control teams reach for, but they are often underprepared because identity and attribution layers are missing. That makes the gateway a risky place to put the main bet.

In a secure agent architecture, gateway controls should not be the first control.

The failure mode is subtle. A gateway may block clear policy violations, but it can struggle to distinguish a justified action from one that is technically permissible but operationally inappropriate. The problem starts when the same permissions let it carry a poisoned summary into the next step, or let a stale context survive long enough to change behavior.

That is why agent security cannot be reduced to a prompt-injection filter. Drift is not a one-shot attack. It is a state problem. The agent remembers things. It accumulates context. It may be told to ignore a previous instruction, to treat a stale note as current, or to treat a privileged user as a regular customer.

Build a memory-poisoning harness

The practical move is to build a harness that treats agent memory like a system under test. You are not trying to prove the agent is safe. You are trying to find the smallest set of conditions under which it becomes unsafe, and then verify that the platform can detect, contain, and recover.

Baseline the agent's memory

Start with a known-good state. Capture the agent's identity, role, allowed tools, visible customer data, policy constraints, and memory entries. Record what it should know, what it should not know, and what it should do when a customer asks for a refund, a status update, or a sensitive account change. This baseline is your control. Without it, every later observation is just a story.

Inject stale, contradictory, or privileged context after auth

Once the agent is authenticated and in a normal support loop, introduce context that should not change its behavior. Examples: a stale ticket note that says a customer is an admin, a contradictory instruction that says a previous policy no longer applies, a customer message that claims a higher privilege, or a system note that appears to grant access to another account. The point is not to make the agent fail dramatically, but to see whether the agent treats the new context as authoritative, whether it carries the contradiction into later actions, and whether it exposes data it should not have touched.

Score drift, data exposure, and policy misuse

Score the run on three axes. Drift: did the agent's stated goals, assumptions, or behavior change from baseline? Data exposure: did it reveal, store, or forward information beyond the current customer's scope? Policy misuse: did it use a permitted tool in a way that was technically allowed but operationally wrong? Keep the scoring simple enough that a human can review it in minutes. A good scorecard should answer: what changed, what was exposed, and what should have stopped it.

Trigger the kill path

When the harness detects a high-severity condition, the platform should not just stop the conversation. A proper kill path entails disabling the agent's identity, invalidating active and derived credentials, blocking tool activation, terminating active tasks, and isolating the workload that contains the agent. Terminating the task is only one step in a proper kill path. The agent may still have background tasks, cached tokens, tool sessions, or memory writes in flight. The kill path has to cut the agent off from the systems it can touch, not just the screen it is talking on.

Verify recovery and least-privilege state

After containment, verify that the agent is actually down and that the blast radius is closed. Check that the identity is disabled, credentials are revoked, tools are blocked, tasks are terminated, and the workload is isolated. Then check the memory: was the poisoned context removed, quarantined, or flagged? If the agent restarts, does it come back with the same over-privileged state, or does it return to a least-privilege baseline? Recovery is not a celebration. It is a state check.

Make the kill path boring

The best kill path is the one nobody has to improvise. It should be a documented, rehearsed sequence with clear owners, clear signals, and clear evidence that each step completed. If your team has to decide in the moment whether to revoke a token, block a tool, or terminate a task, the design has already failed.

Least privilege is not a nice-to-have. A study found that over-privileged AI was associated with a higher incident rate than AI under least privilege, which is a reason to keep agent permissions under least privilege.

Run the harness on a schedule, not just before a launch. Memory poisoning is not a one-time event. It is a class of failure that gets more interesting as agents gain more tools, more memory, and more autonomy. The goal is to make the breakage detectable, containable, and recoverable before it becomes an incident.