DevOps
A memory server may need two write paths, not one
infracore Dev.to (EN Zone)
1 views
For anything an agent can persist, split the proposal path from the commit path and put a real trust boundary between them.
If a model can save durable facts, untrusted text from one session could influence later sessions. A practical DIY baseline:
Store proposed items as append-only JSONL in Git.
Record the source, session ID, and originating commit.
Treat agent-authored items as candidates.
Promote items into the trusted briefing only through a human-controlled credential or out-of-band approval.
Git provides diff, blame, and rollback. Provenance makes the trust decision inspectable.
A --by human argument is not an authority check when the agent can invoke the same command. The promotion signal must be inaccessible to the agent, not merely labeled as human.
One unresolved issue is expiry: provenance identifies where a rule came from, but not whether it still describes the codebase.
What non-forgeable signal do you use before an agent-proposed memory becomes trusted state?
Read original: https://dev.to/infracore/a-memory-server-may-need-two-write-paths-not-one-2p2
← Previous
Automated Reinfection and Worm-Like Lateral Movement via Modified ScreenConnect Clients
Next →
StyleSmuggler: Unauthenticated RCE via Adobe Commerce Failed Payment Email Rendering
Related
Automated Reinfection and Worm-Like Lateral Movement via Modified ScreenConnect Clients
DevOps
0
Dev.to (EN Zone)
6 Benefits of Sandbox Environments (and How Docker Sandboxes Delivers Them)
DevOps
0
Docker Blog
Kestra 2.0: a new engine, workers anywhere, and still Apache 2.0
DevOps
2
DEV Community
You built an app with AI. Now it has to run somewhere.
DevOps
2
DEV Community
Comments0
No comments yet — be the first