跳到正文
DEV Community· Open-Agentic-Brain-and-Memory·· 2 小時前AI 評分59

AI 編碼記憶會保存決策與錯誤:開發者私隱檢查清單

Your AI Coding Memory Contains Your Decisions and Mistakes: A Privacy Checklist for Developers

AI 導讀

文章為使用 AI 編碼工具的開發者整理一份私隱檢查清單,涵蓋記憶存放位置、加密金鑰由誰掌握、哪些資料會離開本機,以及能否檢視、修改、刪除和匯出。

正文

What private AI coding memory self-hosted means, and what to check first

Private AI coding memory self-hosted is a memory store for your coding agents that runs on hardware you control, is encrypted with a key only you hold, and needs no vendor account. To set one up, install a local memory tool, keep the key in your OS Keychain, and verify what leaves your machine.

The rest of this article is a checklist for doing that. It is written for developers who use Claude Code, Cursor or Codex every day and want to know what those tools are quietly remembering.

What a coding memory really holds

AI coding tools are now routine. The Stack Overflow Developer Survey 2025 reported that 84% of respondents use or plan to use AI tools in their development process. A memory layer sits underneath that habit and records what the tools learn about you.

It holds decisions and the reasons behind them, such as "we dropped Redis for SQLite because the cache was never the bottleneck." It holds file paths, service names and internal conventions. It holds preferences, like "always use pnpm."

It also holds your mistakes. A memory of "the deploy failed because the staging token expired" is useful next week. It also describes your infrastructure to anyone who can read it.

Then there are secrets in passing. You paste an error log with a connection string, and the session captures it. This is not far-fetched. GitGuardian's State of Secrets Sprawl 2025 report counted 23.8 million new secrets leaked on public GitHub in 2024. Any pile of developer text that gets copied around will collect credentials.

Treat a coding memory like a private notebook about your company. Decide where it lives before it fills up.

Five questions to ask any memory tool

These work for any product, including ours. If a vendor can't answer one plainly, that is an answer.

1. Where does it run?

Find out whether memories live in a database on your disk or on someone else's servers. "Local" should mean a file you can open, not a cache for a hosted service.

2. Who holds the key?

Encryption only matters if the vendor can't decrypt your data. Ask where the key is stored and whether anyone else has a copy. A key in the OS Keychain stays on your machine. A key in a vendor dashboard does not.

3. What leaves your machine?

Look for any sync, telemetry or embedding calls. Ask what is sent, to whom, and in what form. Then confirm it yourself by watching network traffic for an hour.

4. Can you read and change everything?

A memory you can't inspect is a memory you can't trust. You should be able to list every entry, edit it, pin it and delete it.

5. What happens when you leave?

Ask if you can export your data and whether the tool is open source. If the license is permissive and the store is a plain database, you can always walk away with your history.

What no account and no server of ours means in practice

At Open Agentic Brain & Memory (OpenAB), we built the self-hosted memory layer for Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta) around those five questions. Here is how each one is answered.

  • Where it runs: memories sit in a local SQLite database on your machine.

  • Who holds the key: the memory is encrypted with age, and the key lives only in your OS Keychain.

  • What leaves: if you sync across machines, an encrypted blob goes to a Release asset on your own private GitHub repo. There is no OpenAB account and no OpenAB server.

  • Control: a local control panel lets you read, edit, pin or delete every memory.

  • Leaving: OpenAB is free and Apache-2.0 licensed.

The practical effect is simple. If our website disappeared tomorrow, your memory would keep working. If someone got hold of your private repo or a GitHub token, they would find an encrypted file and nothing readable.

This is also why "private" needs a qualifier. Your memory is private from us and from the sync host. It is not private from you, from other software running as your user, or from the model provider once a briefing is sent into a chat. The briefing is capped at 2,000 tokens, so what any tool sees at session start is bounded.

How private AI coding memory self-hosted setups handle secrets

Encryption protects memory at rest. It does nothing about what goes into memory in the first place. That part is habit and review.

Keep real credentials out of chats. Use environment variables and tell your agent the variable name, not the value. If a secret does slip in, find the memory in the control panel and delete it.

There is a second risk. A poisoned memory can steer an agent. If a tool writes something wrong into memory, every other tool inherits it. This is a good reason to prefer a store where you can read and edit entries.

Deleting memories and what happens if you lose your key

Deleting should be boring. In the control panel you can remove a single memory or a whole project's worth. After that, recall no longer returns it and it no longer appears in briefings.

Check your synced copy too. The encrypted blob in your private repo reflects the state at the last sync. After a large cleanup, sync again so the stored copy matches. Old Release assets can be deleted from GitHub directly.

The key is the harder topic. Only you hold it. If you lose it, nobody can recover your encrypted memory, including us. That is the cost of having no vendor in the loop.

Plan for it. Back up the key in a password manager before you rely on sync. A lost key is annoying, not catastrophic, because you can start fresh and let new sessions rebuild memory. You would lose the history, not the ability to work.

A short audit you can run this week

You can do this in an afternoon. Start with whatever tool you use most.

  1. List your tools. Write down every AI coding tool and machine that stores or reads memory.

  2. Find the stores. Locate the file or service holding each one. Note whether it is on disk or hosted.

  3. Read 50 entries. Skim for tokens, hostnames, customer names and anything you would not paste in a public issue.

  4. Delete what shouldn't be there. Then rotate any credential you found. Deleting a memory does not un-leak a secret.

  5. Watch the network. Run your tools for an hour and note every outbound destination.

  6. Check the key. Confirm where it lives and that you have a backup.

  7. Test recall. Ask a question you know the answer to and see if the memory returns the right entry.

If you want to try this on a tool built to pass the checklist, install Open Agentic Brain & Memory (OpenAB) and run the audit against it. Recall over 10,000 memories takes 28 ms (p50), and the start-up briefing takes 84 ms (p50), so the privacy work does not cost you speed.

FAQ

Is it safe to let an AI tool store my project decisions?

It can be, if you control where the data lives and who holds the key. Decisions are low-risk compared with credentials, but they still describe your systems. Prefer a local store, encrypted sync and a way to inspect every entry.

Is local SQLite memory private?

It is private from vendors, because the file never leaves your disk unless you sync it. It is not private from other software running as your user. Disk encryption and a locked screen still matter.

Can I self-host coding memory without an account?

Yes. OpenAB needs no account and no server of ours. Sync is optional and uses your own private GitHub repo.

Can I delete individual memories from a self-hosted AI memory?

Yes. The OpenAB control panel lets you read, edit, pin or delete each one. If you sync, run a sync afterwards so the stored copy matches.

What happens to secrets pasted into chat?

Anything you type can be captured as a memory, so treat chat as a place to avoid secrets. If one slips in, delete the memory and rotate the credential. GitGuardian's 2025 report shows how often leaked secrets stay valid long after they are exposed.

What happens to my memory if I lose the encryption key?

Nobody can recover the encrypted copy, including us. Back up the key in a password manager. If it is gone, you can start fresh and rebuild memory from new sessions.

Does it work with Claude Code and Cursor?

Yes. OpenAB shares one memory across Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta). Tell one tool something and the others know it.

來源:DEV Community · dev.to