Recovery criteria for compromised AI memory and vector stores

A vector database can be healthy, a restore can complete successfully, and an agent can still be unsafe to return to service.

That is the central recovery problem after memory or retrieval poisoning. Infrastructure recovery proves that data is available. Security recovery must prove that the data is trustworthy, authorization still holds, poisoned derivatives are absent, and the recovered context cannot drive the same harmful behavior again.

The previous field note, When retrieval becomes the attack path, covered containment, evidence preservation, affected-window analysis, and trusted index reconstruction. This article starts where that one stopped: the incident team has isolated the affected retrieval and memory paths and now must decide what can be restored, rebuilt, or released.

Operating principle: A successful restore is not a recovery decision. Recovery is authorized only when a specific candidate state passes integrity, isolation, retrieval, memory, downstream-action, and rollback tests against a recorded trusted baseline.

The incident we will recover

At 08:40, responders confirm that an internal investigation agent stored a malicious instruction from a case attachment in shared long-term memory. The same interaction produced a case summary that was embedded into the SOC knowledge index. Over the next six hours, three other agents retrieved the summary. One suggested an incorrect containment action; another wrote a derived note into memory; a third created a ticket that was later ingested back into the index.

The team has contained new memory writes, disabled affected retrieval aliases, preserved the active collections, and blocked high-impact tools. It now has four possible recovery sources:

1. A vector-store snapshot taken two hours before the first confirmed malicious write.
2. The authoritative document repositories and case system.
3. A memory export containing entries, ownership, timestamps, and partial lineage.
4. The compromised production index, retained as evidence.

Only the second source is independently authoritative. The snapshot may be clean, but its capture time does not prove that every object inside it predates the attacker’s influence. The memory export may contain legitimate user preferences mixed with corrupted summaries. The production index is evidence, not a recovery source.

The recovery decision must answer:

• Which point in time and which source versions are actually trustworthy?
• Which chunks, vectors, summaries, caches, memory entries, tickets, and generated artifacts inherit risk from the poisoned material?
• Can the team rebuild without replaying the same contaminated event stream?
• What tests prove that tenant, user, agent, and case boundaries still hold?
• Which canary conditions allow traffic to return, and which signals force rollback?

During an incident

If the team cannot identify a trustworthy starting point, do not declare recovery. Keep the system in a constrained mode, rebuild from independently authoritative sources, or accept a documented business outage while the evidence gap is resolved.

A snapshot has three possible roles

Responders often use the word snapshot as if it means known good. It does not.

1. Evidence snapshot

Captured after detection to preserve the compromised collection, configuration, aliases, metadata, memory records, and index state. It supports investigation and replay. It should never be silently promoted into production.

2. Recovery candidate

Captured before the currently known compromise window and eligible for validation. It is not trusted until its contents, configuration, source lineage, and software compatibility have been checked.

3. Trusted recovery point

A recovery candidate that has passed the defined evidence and test gates and has an accountable approver. Trust applies to the documented scope—not to every external source, cache, or downstream system that may later reconnect.

Vector platforms implement snapshots differently. Qdrant, for example, documents collection snapshots as archives of collection data and its pre-built index and applies version-compatibility constraints to restoration. Amazon OpenSearch warns about partial snapshots, index and alias conflicts, version compatibility, and restoration behavior. Those platform mechanics matter, but neither product can determine whether the restored records are semantically safe for an agent. Qdrant migration and recovery, Amazon OpenSearch snapshot restore

Treat a backup as a container of state. The incident team must establish the trust of that state separately.

Recovery control architecture

S1 / S2 / M1 --> G1
E1 -. compare only .-> G1
E2 -. lineage only .-> G1
E3 -. affected-window evidence .-> G1
G1 --> B1 --> B2 --> B3 --> T1
T1 --> C1 --> C2 --> C3 --> P1
R1 -. fallback .-> P1
R2 -. switch alias / disable memory .-> P1
R3 -. authorizes .-> R2
C1 / C2 / C3 -. telemetry .-> R2

The compromised snapshot never crosses into the production serving path. It is compared against the recovery candidate to identify unexpected objects, mutations, and configuration changes. The recovery factory creates a new collection and memory namespace with new identifiers. The release plane advances through explicit gates. Rollback changes a versioned alias or configuration reference; it does not depend on deleting records during a live incident.

Establish the trusted boundary before rebuilding

The team needs a signed or otherwise protected recovery manifest. At minimum, it should identify:

The manifest should be generated from controlled configuration and evidence, not reconstructed from an engineer’s memory during the bridge call.

NIST’s Generative AI Profile describes provenance as a way to trace origins, modifications, and downstream effects and recommends documenting provenance limitations. That limitation matters here: if a system has only source-level provenance but no chunk-to-vector or memory-write lineage, the recovery scope must be broader. NIST AI 600-1

Invalidate the derivative graph, not only the bad record

Every compromised object has descendants. Recovery requires a graph, even if the organization must assemble it from logs after the incident.

source version
  ├─ extracted text / OCR
  ├─ chunks
  │    ├─ embeddings
  │    ├─ vector + keyword records
  │    └─ retrieval-cache entries
  ├─ prompt assemblies
  │    ├─ responses and citations
  │    ├─ summaries
  │    ├─ memory writes
  │    └─ tool proposals and actions
  └─ generated artifacts
       ├─ tickets / documents / messages
       └─ sources re-ingested by another pipeline

For each node, assign one disposition:

• Preserve as evidence: restricted, immutable where possible, never served to users or agents.
• Invalidate: logically denied through an exclusion set, tombstone, generation marker, or version boundary.
• Rebuild: recreated from an approved parent using pinned transformations.
• Review manually: retained only after a qualified owner confirms meaning and provenance.
• Unknown: assumed affected until evidence proves otherwise.

Do not rely only on deletion. Distributed caches may retain values, replicas may lag, backups may reintroduce them, and generated artifacts may have become new sources. A durable invalidation record should survive restore and reindex operations. It should contain the incident ID, object type and ID, source version, reason, effective time, scope, approving authority, and whether descendants were enumerated.

Rebuild vector state from source, not from vectors

When the source-to-vector lineage is complete and the incident is narrow, a team may remove a known affected subset and rebuild it. When lineage is incomplete, configuration integrity is uncertain, or shared state crossed tenants, build a new collection.

A defensible rebuild uses:

1. Approved source versions with independent ownership and integrity checks.
2. A clean, isolated worker identity and build environment.
3. Pinned parser, OCR, normalization, chunking, and embedding versions.
4. A new index or collection identifier—not an in-place overwrite.
5. New chunk and vector identifiers linked to the prior IDs only in the evidence map.
6. Authorization metadata derived from the authoritative source, not copied from suspect vectors.
7. A deterministic build manifest with record counts, failures, exclusions, and hashes where meaningful.
8. Writes disabled after the candidate build until the test gate is complete.

Reusing vectors because embedding is expensive is a risk decision, not an optimization detail. If the incident could have changed content, chunk boundaries, embedding configuration, payload metadata, or the embedding itself, reuse carries the unverified state forward.

Rebuild memory by purpose and subject

Agent memory is not one database table. It can include user preferences, conversation summaries, analyst feedback, plans, scratchpads, case facts, tool results, task state, or shared organizational knowledge. Each class needs its own recovery rule.

Microsoft’s current agentic-memory guidance recommends provenance on each memory entry; deterministic isolation by user, agent, and tenant; full CRUD logging; propagation tracking; and history sufficient for rollback. It also treats memory as candidate context rather than authoritative truth. Microsoft: Manage AI memory safety

Use this disposition table:

Restore the smallest memory set needed for the service to function. “Keep everything the agent learned” is not a recovery requirement.

This becomes especially important when AI is used for cybersecurity. Microsoft documents Security Copilot agents that can retain feedback in memory and use it in later outputs, including agents supporting triage, investigation, hunting, and threat intelligence. Some agent capabilities remain preview or workload-dependent. The defensive implication is broader than one vendor: poisoned analyst feedback, case summaries, or remembered exceptions can bias later security decisions even when the underlying SIEM evidence is clean. Recovered security agents should therefore start with read-only access, replay known cases, and prove that conclusions cite authoritative telemetry before automation is restored. Microsoft Security Copilot agent application card

Six test families for recovery

The recovery gate should be executable and produce evidence—not a checklist answered from memory.

1. Structural integrity

• Every candidate record maps to an approved source version and tenant.
• Record, chunk, vector, and memory counts reconcile with the build manifest or have explained differences.
• Parser, chunker, embedding, schema, dimensions, distance metric, and index configuration match the approved versions.
• No quarantined source, digest, prior vector ID, memory ID, or exclusion marker is present in the serving candidate.
• Snapshot or restore operations report complete success; partial or incompatible state fails the gate.
• Candidate configuration and manifests are protected from modification after testing.

Required evidence: build logs, manifest digest, reconciliation report, exception list, and independent reviewer.

2. Authorization and isolation

• Cross-tenant, cross-user, cross-case, and cross-agent queries return no unauthorized results.
• Deleted or disabled identities cannot retrieve historical content through alternate APIs, caches, or direct vector-store access.
• Missing tenant, ACL, classification, or provenance metadata fails closed.
• Memory reads and writes enforce the same subject and purpose constraints as the primary application.
• Service identities can perform only the operations required for their pipeline stage.

Required evidence: negative-test results, policy decision IDs, target audit events, and access review.

3. Retrieval behavior

• Golden queries return the expected source versions and citations.
• Known poisoned phrases, semantic variants, and indirect-instruction canaries do not retrieve excluded material.
• Ranking and score distributions remain inside reviewed tolerances relative to a trusted benchmark.
• New or rare sources cannot dominate unrelated queries without a documented ranking reason.
• Hybrid search, rerankers, fallback indexes, and alternate regions return equivalent authorized results.
• Retrieval traces expose the query, filters, top-K results, scores, source versions, and cache status.

Required evidence: versioned test corpus, expected results, measured deltas, and trace export.

4. Memory behavior

• A test memory write cannot omit subject, source, purpose, timestamp, model/agent version, classification, or expiry.
• Disallowed memory types and untrusted raw content are rejected or routed for review.
• Deleted or quarantined memory cannot reappear after restart, failover, compaction, or cache warming.
• Shared-memory tests cannot cross tenant, user, agent, or case boundaries.
• Multi-turn adversarial tests do not create delayed poisoned state.
• Responders can trace which memory entries influenced a response or action.

Required evidence: CRUD audit events, policy results, restart/failover test, and influence trace.

OWASP’s Top 10 for Agentic Applications 2026 describes memory and context poisoning as persistent corruption that can propagate across sessions and agents, influence reasoning, and lead to unsafe tool use or exfiltration. Recovery tests must therefore cover delayed and cross-agent effects, not only the first clean response. OWASP ASI06: Memory & Context Poisoning

5. Downstream action safety

• Tool proposals based on recovered context are reauthorized independently.
• High-impact tools remain denied during synthetic and read-only canaries.
• Target-system logs correlate every executed test action to the candidate version, trace, identity, and approval.
• Known poisoned scenarios produce refusal, escalation, or safe read-only behavior.
• Generated tickets, messages, code, and reports cannot enter an ingestion loop without provenance and approval.

Required evidence: policy decisions, tool traces, target-system events, and loop-prevention test.

6. Operational observability and rollback

• Telemetry covers source selection, ingestion, vector mutation, retrieval, memory CRUD, policy decisions, tool actions, and target outcomes.
• Alerts fire for quarantined identifiers, missing provenance, ACL failures, unexpected write volume, ranking drift, and memory-policy denials.
• Operators can identify which candidate version served each request.
• The alias or configuration switch back to the prior safe state has been tested.
• Rollback does not erase evidence, reopen writes, or reconnect high-risk tools.

Required evidence: monitoring queries, test alerts, dashboard capture, rollback timing, and named owner.

Measurable release gates

Avoid “looks normal” as a recovery criterion. Set thresholds before the canary begins.

These percentages are control objectives for the defined recovery scope, not claims about product reliability. If a team cannot measure a row, it should record the gap and decide whether the service must remain constrained.

Canary release without turning users into testers

Use four stages, each with a separate decision record:

Stage 0 — Offline

Run deterministic tests against the isolated candidate. No production identity, live memory, external destination, or consequential tool is reachable.

Stage 1 — Synthetic canary

Use dedicated identities, seeded trusted data, poisoned canaries, known ACL boundaries, and reversible mock tools. Confirm telemetry and rollback before adding real context.

Stage 2 — Internal read-only

Allow a small responder and service-owner group to query approved production-derived sources. Keep memory writes and high-impact tools disabled. Require users to report incorrect citations, missing context, or unexpected personalization.

Stage 3 — Limited production

Enable selected tenants or use cases with enhanced monitoring. Restore typed memory writes only after read behavior is stable. Restore each tool class separately; do not bundle retrieval, memory, and tool reactivation into one change.

Full service follows only after the observation window passes and the incident commander, AI service owner, data owner, and security approver accept the evidence package.

Microsoft’s retrieval-hygiene guidance recommends versioned memory snapshots, logged writes, rollback to known-good state, time-bound entries, revalidation, and read/write lineage. Those controls make this staged recovery possible; without them, the team is forced into broader rebuilds and longer observation windows. Microsoft: Input, Context, and Retrieval Hygiene

Rollback triggers must be decided before release

Any of these should stop progression and normally roll back the candidate:

• A known quarantined ID, digest, phrase, or semantic canary is retrieved.
• A record lacks required provenance, tenant, ACL, or source-version metadata.
• A cross-boundary retrieval or memory access succeeds.
• Ranking or citation behavior exceeds the approved tolerance without explanation.
• A memory write bypasses its schema, policy decision, or audit event.
• An agent proposes or executes a high-impact action outside the canary contract.
• Telemetry cannot reconstruct the request, retrieved context, memory influence, and target outcome.
• Error, denial, latency, or fallback behavior causes traffic to use an untested index or cache.
• A previously invalidated derivative reappears after restart, restore, or cache warm-up.

Rollback should switch the serving alias to a previously validated, read-only, or degraded-safe target and disable candidate memory writes. Preserve the failed candidate and its telemetry for investigation. Do not “fix forward” under production traffic unless the incident commander explicitly accepts that risk.

The recovery authorization packet

The final decision should fit into a reviewable package:

1. Incident and affected-window summary.
2. Trusted source and recovery-point rationale.
3. Recovery manifest and digest.
4. Derivative graph with every node’s disposition.
5. Build and restore results, including warnings and exceptions.
6. Test evidence for all required families.
7. Canary scope, observation results, and unresolved anomalies.
8. Monitoring queries, alert ownership, and retention.
9. Rollback target, procedure, tested duration, and authority.
10. Residual risk, expiry date, and signatures or recorded approvals.

Approval should come from people who can accept both security and service risk. A platform engineer can prove that the index works; the data owner can confirm source authority; security can assess poisoning and access-control evidence; the service owner can accept degraded behavior; the incident commander can authorize the transition.

Responder worksheet

Blank cells are intentional working fields. Populate them in the incident record; do not put sensitive case data into a public copy of this worksheet.

Closing position

Recovery from compromised AI memory or vector state is not a database operation with a security checklist attached.

It is a controlled reconstruction of what the system is allowed to remember, retrieve, and act upon.

A trustworthy recovery begins from independently approved sources, invalidates the full derivative graph, rebuilds into a new versioned boundary, tests negative cases as seriously as successful queries, and releases through canaries with a measured rollback path.

The decisive question is not “Did the restore finish?”

It is:

Can we prove which state is serving, why every object in it is trusted, what it is permitted to influence, and how quickly we can withdraw it if that proof fails?