AI Recommendation Poisoning: Summary Links That Try to Rewrite Assistant Memory

At the durable memory writer, quarantine externally originated memory proposals and exclude every pending state from recall. Promote only the exact tenant, content digest, namespace and version approved by an independent reviewer or trusted policy. With this enforced boundary, the summary request cannot silently become a trusted recommendation preference. Preserve external origin, prevent the model from approving its own proposal, and verify retry/crash behavior; platform ownership is required.

At the persistent-memory retrieval service, separate external or quarantined records from trusted user preferences and centrally authorize which trust tiers a personalization query may return. If external tiers are denied for trusted personalization, the poisoned record cannot influence this later answer. Tenant separation alone is insufficient: the attack occurs within one user's account. The service must enforce trusted provenance, result binding and fail-closed lease checks; it cannot rely on the model to choose its own namespace.

At an operator-controlled inference gateway, inspect the decoded URL-supplied prompt before model dispatch and deny requests flagged by a request-bound moderation decision. The detector must be calibrated for unsolicited persistent brand steering; a toxicity-only filter or the legitimate assistant hostname is insufficient. Fail closed on moderation errors. This is conditional prevention, not a SaaS tenant setting or a guarantee against semantic evasion.

Before recalled memory enters prompt assembly, scan each exact record version for instructions that promote a brand or assert source authority. Use a calibrated prompt-safety detector and emit findings bound to the tenant, recall request and content digest. This can expose an earlier poisoned write, but benign-looking paraphrases may evade detection. The scanner does not block or delete memory; a separate admission policy must act on the finding, and missing scans or detector errors must not be treated as clean.

After confirming a poisoned memory, the store operator removes the exact authorized records and their derived index/cache copies, records reinsertion tombstones, and uses a separate read-only identity to verify that a replacement agent cannot reload them. Preserve clean memories. This removes persistence after the fact; it does not undo prior recommendations. Ordinary SaaS users can remove suspicious saved memories through available controls, but cannot independently prove backend purge when the provider exposes no such evidence.