[Backlog]: Conversation Memory Poisoning

[felipepenha]

Checklist

• Backlog entry requires creating new sandboxes.
• Backlog entry requires creating new exploitation code and/or tutorials.

CVE List

No response

Description

Summary

Exploitation poisons memory of conversational GenAI system.

GenAI Red Teaming Manual Reference

4.2.1.3 Conversation Memory Poisoning / A. Context Injection

Sandbox

Create sandbox in similarity to llm_local, but including persistent memory.

Suggested name: sandboxes/llm_memory_local.

Suggested tech stack: ollama, mirascope, gradio, sqlite.

Exploitation

Inject a prompt with instruction or information that will be stored in memory and, thus, influence future session behavior.

[fasinet]

@felipepenha is this issue still tracked? I would like to give it a crack.

[felipepenha]

@felipepenha is this issue still tracked? I would like to give it a crack.

Sure! Feel free to do so.

[Anwaar-Ahmad9212]

@felipepenha is this issue still available ? or is it fixed? I would like to give it a try

[felipepenha]

@fasinet Have you made any progress on addressing this issue? Otherwise, @Anwaar-Ahmad9212 would like to develop it.

[fasinet]

@felipepenha ,
I think I'm halfway there. Just a couple more weeks to wrap it up.

[opitaru-sys]

I'd like to pick this one up if it's still open.

Plan follows CONTRIBUTING - a sandboxes/llm_memory_local sandbox (ollama, mirascope, gradio, sqlite) with Containerfile, Makefile (attack/stop/all), README and app/, plus an exploitation example showing an injected instruction persisting in stored memory and steering a later session. Scoped to 4.2.1.3 Context Injection.

Happy to split into two PRs, sandbox first and exploit second, if that reviews more easily.

[felipepenha]

@opitaru-sys and @Anwaar-Ahmad9212 Please, see conversation above with @fasinet . I would prefer that you wait for @fasinet's contribution and pick it up from there, either proposing improvements or creating alternatives to that code as separate entities in the repo.

[opitaru-sys]

Thanks @felipepenha. No problem at all, @fasinet was here first so their version should lead.

For context, I already have a complete implementation up as #56 (the llm_memory_local sandbox plus a working exploit, tested end to end). I built it before seeing your note, so treat it as optional.

Happy to go whichever way is least disruptive. I can hold #56 until @fasinet's lands and then fold anything useful into theirs, or keep it as a separate alternative sandbox under a different name so it doesn't collide. Your call on sequencing.

In the meantime I'll switch #56 from "Closes #22" to "Relates to #22" so a merge can't auto-close this. Looking forward to seeing @fasinet's take :)