ai-memory 安全模型解析威胁边界、认证体系与本地数据保密实践【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory导读本文基于 ai-memory 官方安全策略SECURITY.md系统梳理这个面向 Agent 编码 CLI 的长期记忆服务的威胁模型、认证阶梯与数据保密设计。ai-memory 定位为单租户的工作站/家庭实验室homelab服务虽然支持多用户归属attributed users但所有已认证用户属于同一信任域、可读取相同的项目记忆。读完本文你将掌握本地数据如何通过0700/0600文件权限实现零配置保密绑定非回环地址时服务如何 fail-closedBearer 令牌、数据库用户令牌与 OIDC 可信代理构成的认证阶梯以及--allow-insecure-no-auth、AI_MEMORY_AUTH_TOKEN、AI_MEMORY_ALLOWED_HOSTS、AI_MEMORY_RERANKERllm等关键开关的正确打开方式与风险边界。漏洞报告流程安全策略明确要求安全漏洞不要通过公开 Issue 报告而应通过 GitHub 的 private security advisory私有安全公告渠道提交。承诺的响应节奏为收到报告后7 天内回复问题确认后30 天内发布补丁除非报告者要求匿名否则会在 CHANGELOG.md 中致谢。威胁模型单租户信任域ai-memory 的定位决定了它的防御边界。策略原文点明这是一个单租户 workstation/homelab 服务支持多归属用户但每个已认证用户都属于同一信任域彼此可以读取相同的项目记忆。因此下面所述的一切防护都建立在一个前提上运行服务的那台机器及其登录用户本身是可信的。范围内防护In scope以下威胁是 ai-memory 明确设计要防御的。1. 本地数据机密性基于文件系统权限的零加密保障Wiki 文件与 SQLite 数据库都存放在单一数据目录下由运行服务的操作系统用户控制。v1 版本不提供静态加密encryption at rest依赖文件系统权限Unix 下新建的数据目录为 owner-only0700新建的配置文件、SQLite 数据库、managed-workstream 分段、下载的备份文件为 owner 读写0600与 umask 无关已有安装不会被自动 chmod——升级旧版本不会偷偷改权限Windows 使用文件系统 ACL 而非 POSIX 权限位。源码中可找到大量印证。例如 crates/ai-memory-cli/src/commands/init.rs 初始化数据目录时对目录使用builder.mode(0o700)、对内部文件使用options.mode(0o600)crates/ai-memory-cli/src/commands/hook_spool.rs 创建 spool 目录时同样以0o700创建、以0o600写入 spool 条目并附有测试断言spool dir must be owner-onlyassert_eq!(mode, 0o700, ...)。LLM 凭据文件也在落盘前先chmod 0600crates/ai-memory-llm/src/auth_file.rs。0600的约定贯穿整条数据链路这正是本地数据机密性的实现基础。2. 非回环地址绑定的网络暴露fail-closed 检查如果运行ai-memory serve --bind 0.0.0.0:…MCP 与 admin 路由就会暴露到本地网络。策略给出的防护组合是AI_MEMORY_AUTH_TOKEN/ai-memory generate-auth-tokenBearer 令牌每个请求都会校验防火墙规则或带 TLS 的反向代理。服务在向未认证的非回环 HTTP 请求提供服务之前就会 fail-closed。--allow-insecure-no-auth是一个刻意保留的危险覆盖开关仅用于有意的明文 HTTP 局域网部署。源码 crates/ai-memory-cli/src/commands/serve.rs 的validate_http_exposure函数完整实现了这套判定监听地址是回环loopback→Safe直接放行人机认证模式下 cookie 未设 Secure → 直接拒绝refusing human authentication on non-loopback plain HTTP...已配置认证 →Safe传了--allow-insecure-no-auth→InsecureByOverride允许但记录警告容器内 →UndeterminedInContainer见下其余情况 →bail!拒绝启动错误信息明确指引配置AI_MEMORY_AUTH_TOKEN或绑定回环地址。容器内的特殊处理警告而非拒绝容器场景值得单独说明。由于docker run -p发布端口必然要求命名空间内绑定0.0.0.0容器内的 bind 地址无法反映真实可达性——这由宿主侧的发布规格决定进程自身看不到。因此在容器内validate_http_exposure不再拒绝而是改为响亮警告UndeterminedInContainer。容器运维者需要检查的是自己的-p参数-p 127.0.0.1:49374:49374仅回环可达无令牌也安全任何更宽的发布范围必须配置AI_MEMORY_AUTH_TOKEN。源码中running_in_container()的检测信号包括 Docker 的/.dockerenv、Podman 的/run/.containerenv以及官方镜像设置的AI_MEMORY_IN_CONTAINER环境变量crates/ai-memory-cli/src/commands/serve.rs。Host 白名单不是访问控制注意Host白名单不能替代令牌。它防御的是 DNS rebinding浏览器可控的 Host 头而能路由到该端口的客户端可以自由设置Host头所以它不是访问控制。另外认证本身不会加密 Bearer 令牌——离开回环的流量必须走 TLS 反向代理详见 docs/https-via-proxy.md。/web 的 HTTPS-only Cookie若/web置于可信 TLS 反向代理之后需设置AI_MEMORY_AUTH__SECURE_COOKIEtrue让浏览器会话 Cookie 仅限 HTTPS 发送。ai-memory不信任 forwarded-protocol 头来做这个决定必须由运维显式配置同时应关闭或重定向直接 HTTP 访问因为浏览器会刻意在 HTTP 上扣留 Secure Cookie。配置模板 crates/ai-memory-cli/templates/config.default.toml 中[auth] secure_cookie false的注释明确说明明文回环 HTTP 下默认安全反向代理后才需要开启。3. Host-header DNS rebinding 防护HTTP 服务器强制AI_MEMORY_ALLOWED_HOSTS白名单默认值为127.0.0.1与localhostHost头不在列表内的请求以403拒绝。默认配置模板中白名单是[localhost, 127.0.0.1, ::1]crates/ai-memory-cli/templates/config.default.toml并提示绑定 LAN 地址时要把客户端实际使用的 host/IP 加入例如AI_MEMORY_ALLOWED_HOSTShomelab,192.168.0.90,localhost,127.0.0.1。serve.rs 中apply_host_layer实现了该中间件命中白名单之外的 Host 时记录warn日志并拒绝crates/ai-memory-cli/src/commands/serve.rs。4. 请求体大小上限入站 HTTP 请求体被限制为10 MB防止简单的内存耗尽memory exhaustion。源码常量MAX_BODY_BYTES: usize 10 * 1024 * 1024通过 axum 的DefaultBodyLimit::max(MAX_BODY_BYTES)挂载crates/ai-memory-cli/src/commands/serve.rs。hook spool 的注释也提到其分块设计刻意保持在服务器 body 限制之下crates/ai-memory-cli/src/commands/hook_spool.rs。5. 认证与管理授权静态 root 令牌 DB 用户令牌 OIDC认证体系是一个文档化的认证阶梯auth ladder静态 root Bearer 令牌由AI_MEMORY_AUTH_TOKEN或[auth].bearer_token配置数据库用户令牌DB-user tokens提供归属attribution永远不授予 admin 权限可选 OIDC hook-edge 令牌供可信反向代理断言身份。关键规则第一个数据库用户创建后所有/admin/*路由仅限 rootDB 用户令牌只做归属记录。令牌可通过ai-memory generate-auth-token生成。该命令调用ai_memory_mcp::auth::generate_token_hex(args.bytes)用 OS 随机数生成十六进制令牌crates/ai-memory-cli/src/commands/generate_auth_token.rs源码注释建议工作流为ai-memory generate-auth-token docker/.env.production后加上AI_MEMORY_AUTH_TOKEN前缀。默认熵预算 32 字节256 位源码注释明确对任何设想的威胁模型都足够crates/ai-memory-mcp/src/auth.rs。认证中间件crates/ai-memory-mcp/src/auth.rs的底层实现要点令牌比较使用subtle::ConstantTimeEq常量时间比较防止同一局域网内的攻击者通过响应时间差逐字节还原令牌机器路由/mcp、/hook、/handoff、/workstream/*只接受Authorization: BearerCookie 和 Basic 永远不是机器凭据测试cookie_is_never_a_machine_credential、basic_auth_is_never_a_machine_credential均验证这一点空/空白配置值视为未配置认证避免占位符环境变量被当成 root 凭据 陷阱可信代理专用 Bearer 与 root Bearer必须不同否则缺失身份断言的代理流量可能意外成为 root 流量validate_trusted_proxy_authcrates/ai-memory-cli/src/commands/serve.rs代理断言的身份统一降级为 User 级除非 OIDC issuersubject 与 root 完全一致测试proxy_asserted_identity_is_downgraded_to_user_level。6. 项目间隔离(workspace_id, project_id)命名空间Wiki 文件与 SQLite 行都以(workspace_id, project_id)命名空间隔离。项目 A 的 purge 操作不能删除也属于项目 B 的文件实体查询在项目 CTE 与页面边界处过滤数据库迁移 V38 的触发器拒绝 workspace/project 不匹配的实体以及跨项目的实体/页面链接见 crates/ai-memory-store/migrations/V38__entities.sql。这与策略中purge for project A cannot delete files that also belong to project B的描述一一对应。7. 实体文本保持有界Consolidator 输出与手写的entities:frontmatter 经过同一条规范化边界每页至多 10 个名称、每个名称 64 字符控制字符被拒绝。查询令牌与 SQL 参数都有界词法实体匹配不会触发额外的出站 provider 调用。即便在 explain 响应中渲染实体名称仍被视为不可信存储内容。8. Assistant/Stop 捕获双重 opt-in 与双重净化#196Agent 的最终轮内容默认永不持久化。存储它需要双重 opt-in服务端capture_assistant true对应AI_MEMORY_CAPTURE_ASSISTANTtrue客户端install-hooks --capture-assistant。启用后必须意识到以下几点策略原文的完整警告双重净化客户端先以内置模式脱敏之后才进入 spool/网络传输服务端再用自身配置的[sanitize]模式二次脱敏后再存储。操作员的extra_patterns只在服务端运行——因此仅被extra_patterns规则命中的秘密在到达服务端之前可能仍留在客户端 spool/传输中。客户端脱敏是不可逆的服务端allowlist无法恢复客户端已替换为[REDACTED]的文本捕获的 assistant 文本会流入 consolidation 与 reviewer 的 prompt若配置了云 LLM provider还会发送给该 provideropt-in 是全局的没有按项目的 marker 可以在开启后排除敏感仓库assistant 文本无法按路径归属。关闭服务端开关即可全局禁用摘录可能引用 ai-memory 从未见过的路径中的代码、秘密或内容Sanitizer是尽力而为的凭据剥离不是保证。配置模板对capture_assistant的注释完整复述了这些隐私警告crates/ai-memory-cli/templates/config.default.toml。净化器实现位于 crates/ai-memory-core/src/sanitize.rs内置模式覆盖 Bearer 令牌、厂商前缀 API 密钥sk-、sk_live_、ghp_、github_pat_、AKIA、AIza、Slack 形态的xoxb/xoxp/xoxa/xapp、JWT、PEM 私钥、URL 内嵌凭据postgres://user:passhost、各支持 provider 的命名环境变量、通用*_(KEY|TOKEN|SECRET|PASSWORD|CREDENTIAL)…形态以及~/.ssh、~/.aws、~/.kube、~/.config/gcloud、~/.gnupg下的路径。extra_patterns在启动时一次性编译非法正则直接中止启动allowlist按匹配逐条检查命中的片段原样保留如公共标识符PUBLIC_VERIFY_KEY不应被通用*_KEY规则误伤。9. 存储内容的 prompt 注入Handoff、项目 brief、managed workstream 包、MCP routing 与 LLM 维护 prompt 都明确将存储材料标记为不可信历史数据。净化和结构化输出 schema 只是纵深防御不能证明模型不被操纵操作员与 Agent 必须对照当前指令与 checkout 验证安全敏感声明。10. 搜索重排是出站数据的 opt-in设置AI_MEMORY_RERANKERllm会把每次符合资格的实时查询加上有界的页面标题与搜索片段发送给所配置的 LLM provider。要点managed 写入会经过 ai-memory 的净化器但手动编辑的 wiki 文件可能含未净化的文本实时查询有界但不净化——脱敏可能改变其含义JSON 编码、显式 untrusted-data prompt、严格分数校验、超时、四路并发上限concurrency cap限制了控制与可用性影响但都不让云 provider 变得私密需要查询或召回片段不离开服务器时保持重排关闭或使用本地 provider。配置模板中的reranker llm注释写明其代价与并发上限crates/ai-memory-cli/templates/config.default.toml。11. 发布物完整性SHA-256 与 GitleaksDocker wrapper 与独立 hook 安装使用 GitHub Release 资产及其SHA-256 摘要文件GitHub Actions固定到已审查的 commit发布任务默认只读令牌权限除 GitHub Release 发布者外Gitleaks 检查每个推送或提议的 commit 范围另有独立周度/手动工作流检查完整可达历史全历史扫描只认.gitleaksignore中已审查、精确的指纹添加 ignore 条目绝不替代从当前树中移除真实凭据并轮换。v1 范围外Out of scope以下威胁 v1明确不防御部署时须自行补足租户隔离与按用户 ACL数据库用户只提供归属不提供私有记忆。没有按用户或按项目的 ACL互不可见数据的用户必须运行独立的服务器/数据目录静态加密数据目录是明文文件系统树远程同步安全若将 wiki git 仓库推送到远程保护该通道SSH 密钥、GitHub 访问控制等是你自己的责任完美的语义 prompt 注入防护隐私剥离能去除明显的凭据、prompt 表面保留信任边界但没有文本过滤器能证明 LLM 会无视每一段对抗性文本面向敌意互联网的 DoS 防护hook 队列、请求体、速率限制与并发都有界但服务不是为直接暴露于不可信互联网设计的——请置于常规网络控制防火墙、代理之后。支持的版本只有最新 release 接收安全修复不向旧 minor 版本 backport。这要求使用者保持升级习惯及时跟进最新版本以获取安全补丁。实操速查综合策略文档与源码一套安全的部署姿势可以浓缩为场景推荐配置纯本机使用保持默认绑定127.0.0.1:49374无需令牌Host白名单保持默认局域网明文暴露非容器配置AI_MEMORY_AUTH_TOKEN或用--allow-insecure-no-auth显式覆盖须理解风险容器端口发布只发布127.0.0.1:49374:49374可免令牌更宽必须配令牌反向代理 /webTLS 终止 AI_MEMORY_AUTH__SECURE_COOKIEtrue参考 docs/https-via-proxy.md局域网访问域名AI_MEMORY_ALLOWED_HOSTS中加入客户端实际使用的 host/IP启用 assistant 捕获服务端capture_assistanttrue且客户端install-hooks --capture-assistant并接受全局生效的事实敏感查询保持reranker关闭或使用本地 provider多用户互不可见运行多个独立服务器/数据目录配置的完整安全相关项可在 crates/ai-memory-cli/templates/config.default.toml 中逐一核对认证中间件的测试用例crates/ai-memory-mcp/src/auth.rs则提供了可运行的验证样例展示每种凭据形态在 wire 层的真实行为。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ai-memory 安全模型解析：威胁边界、认证体系与本地数据保密实践
ai-memory 安全模型解析威胁边界、认证体系与本地数据保密实践【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory导读本文基于 ai-memory 官方安全策略SECURITY.md系统梳理这个面向 Agent 编码 CLI 的长期记忆服务的威胁模型、认证阶梯与数据保密设计。ai-memory 定位为单租户的工作站/家庭实验室homelab服务虽然支持多用户归属attributed users但所有已认证用户属于同一信任域、可读取相同的项目记忆。读完本文你将掌握本地数据如何通过0700/0600文件权限实现零配置保密绑定非回环地址时服务如何 fail-closedBearer 令牌、数据库用户令牌与 OIDC 可信代理构成的认证阶梯以及--allow-insecure-no-auth、AI_MEMORY_AUTH_TOKEN、AI_MEMORY_ALLOWED_HOSTS、AI_MEMORY_RERANKERllm等关键开关的正确打开方式与风险边界。漏洞报告流程安全策略明确要求安全漏洞不要通过公开 Issue 报告而应通过 GitHub 的 private security advisory私有安全公告渠道提交。承诺的响应节奏为收到报告后7 天内回复问题确认后30 天内发布补丁除非报告者要求匿名否则会在 CHANGELOG.md 中致谢。威胁模型单租户信任域ai-memory 的定位决定了它的防御边界。策略原文点明这是一个单租户 workstation/homelab 服务支持多归属用户但每个已认证用户都属于同一信任域彼此可以读取相同的项目记忆。因此下面所述的一切防护都建立在一个前提上运行服务的那台机器及其登录用户本身是可信的。范围内防护In scope以下威胁是 ai-memory 明确设计要防御的。1. 本地数据机密性基于文件系统权限的零加密保障Wiki 文件与 SQLite 数据库都存放在单一数据目录下由运行服务的操作系统用户控制。v1 版本不提供静态加密encryption at rest依赖文件系统权限Unix 下新建的数据目录为 owner-only0700新建的配置文件、SQLite 数据库、managed-workstream 分段、下载的备份文件为 owner 读写0600与 umask 无关已有安装不会被自动 chmod——升级旧版本不会偷偷改权限Windows 使用文件系统 ACL 而非 POSIX 权限位。源码中可找到大量印证。例如 crates/ai-memory-cli/src/commands/init.rs 初始化数据目录时对目录使用builder.mode(0o700)、对内部文件使用options.mode(0o600)crates/ai-memory-cli/src/commands/hook_spool.rs 创建 spool 目录时同样以0o700创建、以0o600写入 spool 条目并附有测试断言spool dir must be owner-onlyassert_eq!(mode, 0o700, ...)。LLM 凭据文件也在落盘前先chmod 0600crates/ai-memory-llm/src/auth_file.rs。0600的约定贯穿整条数据链路这正是本地数据机密性的实现基础。2. 非回环地址绑定的网络暴露fail-closed 检查如果运行ai-memory serve --bind 0.0.0.0:…MCP 与 admin 路由就会暴露到本地网络。策略给出的防护组合是AI_MEMORY_AUTH_TOKEN/ai-memory generate-auth-tokenBearer 令牌每个请求都会校验防火墙规则或带 TLS 的反向代理。服务在向未认证的非回环 HTTP 请求提供服务之前就会 fail-closed。--allow-insecure-no-auth是一个刻意保留的危险覆盖开关仅用于有意的明文 HTTP 局域网部署。源码 crates/ai-memory-cli/src/commands/serve.rs 的validate_http_exposure函数完整实现了这套判定监听地址是回环loopback→Safe直接放行人机认证模式下 cookie 未设 Secure → 直接拒绝refusing human authentication on non-loopback plain HTTP...已配置认证 →Safe传了--allow-insecure-no-auth→InsecureByOverride允许但记录警告容器内 →UndeterminedInContainer见下其余情况 →bail!拒绝启动错误信息明确指引配置AI_MEMORY_AUTH_TOKEN或绑定回环地址。容器内的特殊处理警告而非拒绝容器场景值得单独说明。由于docker run -p发布端口必然要求命名空间内绑定0.0.0.0容器内的 bind 地址无法反映真实可达性——这由宿主侧的发布规格决定进程自身看不到。因此在容器内validate_http_exposure不再拒绝而是改为响亮警告UndeterminedInContainer。容器运维者需要检查的是自己的-p参数-p 127.0.0.1:49374:49374仅回环可达无令牌也安全任何更宽的发布范围必须配置AI_MEMORY_AUTH_TOKEN。源码中running_in_container()的检测信号包括 Docker 的/.dockerenv、Podman 的/run/.containerenv以及官方镜像设置的AI_MEMORY_IN_CONTAINER环境变量crates/ai-memory-cli/src/commands/serve.rs。Host 白名单不是访问控制注意Host白名单不能替代令牌。它防御的是 DNS rebinding浏览器可控的 Host 头而能路由到该端口的客户端可以自由设置Host头所以它不是访问控制。另外认证本身不会加密 Bearer 令牌——离开回环的流量必须走 TLS 反向代理详见 docs/https-via-proxy.md。/web 的 HTTPS-only Cookie若/web置于可信 TLS 反向代理之后需设置AI_MEMORY_AUTH__SECURE_COOKIEtrue让浏览器会话 Cookie 仅限 HTTPS 发送。ai-memory不信任 forwarded-protocol 头来做这个决定必须由运维显式配置同时应关闭或重定向直接 HTTP 访问因为浏览器会刻意在 HTTP 上扣留 Secure Cookie。配置模板 crates/ai-memory-cli/templates/config.default.toml 中[auth] secure_cookie false的注释明确说明明文回环 HTTP 下默认安全反向代理后才需要开启。3. Host-header DNS rebinding 防护HTTP 服务器强制AI_MEMORY_ALLOWED_HOSTS白名单默认值为127.0.0.1与localhostHost头不在列表内的请求以403拒绝。默认配置模板中白名单是[localhost, 127.0.0.1, ::1]crates/ai-memory-cli/templates/config.default.toml并提示绑定 LAN 地址时要把客户端实际使用的 host/IP 加入例如AI_MEMORY_ALLOWED_HOSTShomelab,192.168.0.90,localhost,127.0.0.1。serve.rs 中apply_host_layer实现了该中间件命中白名单之外的 Host 时记录warn日志并拒绝crates/ai-memory-cli/src/commands/serve.rs。4. 请求体大小上限入站 HTTP 请求体被限制为10 MB防止简单的内存耗尽memory exhaustion。源码常量MAX_BODY_BYTES: usize 10 * 1024 * 1024通过 axum 的DefaultBodyLimit::max(MAX_BODY_BYTES)挂载crates/ai-memory-cli/src/commands/serve.rs。hook spool 的注释也提到其分块设计刻意保持在服务器 body 限制之下crates/ai-memory-cli/src/commands/hook_spool.rs。5. 认证与管理授权静态 root 令牌 DB 用户令牌 OIDC认证体系是一个文档化的认证阶梯auth ladder静态 root Bearer 令牌由AI_MEMORY_AUTH_TOKEN或[auth].bearer_token配置数据库用户令牌DB-user tokens提供归属attribution永远不授予 admin 权限可选 OIDC hook-edge 令牌供可信反向代理断言身份。关键规则第一个数据库用户创建后所有/admin/*路由仅限 rootDB 用户令牌只做归属记录。令牌可通过ai-memory generate-auth-token生成。该命令调用ai_memory_mcp::auth::generate_token_hex(args.bytes)用 OS 随机数生成十六进制令牌crates/ai-memory-cli/src/commands/generate_auth_token.rs源码注释建议工作流为ai-memory generate-auth-token docker/.env.production后加上AI_MEMORY_AUTH_TOKEN前缀。默认熵预算 32 字节256 位源码注释明确对任何设想的威胁模型都足够crates/ai-memory-mcp/src/auth.rs。认证中间件crates/ai-memory-mcp/src/auth.rs的底层实现要点令牌比较使用subtle::ConstantTimeEq常量时间比较防止同一局域网内的攻击者通过响应时间差逐字节还原令牌机器路由/mcp、/hook、/handoff、/workstream/*只接受Authorization: BearerCookie 和 Basic 永远不是机器凭据测试cookie_is_never_a_machine_credential、basic_auth_is_never_a_machine_credential均验证这一点空/空白配置值视为未配置认证避免占位符环境变量被当成 root 凭据 陷阱可信代理专用 Bearer 与 root Bearer必须不同否则缺失身份断言的代理流量可能意外成为 root 流量validate_trusted_proxy_authcrates/ai-memory-cli/src/commands/serve.rs代理断言的身份统一降级为 User 级除非 OIDC issuersubject 与 root 完全一致测试proxy_asserted_identity_is_downgraded_to_user_level。6. 项目间隔离(workspace_id, project_id)命名空间Wiki 文件与 SQLite 行都以(workspace_id, project_id)命名空间隔离。项目 A 的 purge 操作不能删除也属于项目 B 的文件实体查询在项目 CTE 与页面边界处过滤数据库迁移 V38 的触发器拒绝 workspace/project 不匹配的实体以及跨项目的实体/页面链接见 crates/ai-memory-store/migrations/V38__entities.sql。这与策略中purge for project A cannot delete files that also belong to project B的描述一一对应。7. 实体文本保持有界Consolidator 输出与手写的entities:frontmatter 经过同一条规范化边界每页至多 10 个名称、每个名称 64 字符控制字符被拒绝。查询令牌与 SQL 参数都有界词法实体匹配不会触发额外的出站 provider 调用。即便在 explain 响应中渲染实体名称仍被视为不可信存储内容。8. Assistant/Stop 捕获双重 opt-in 与双重净化#196Agent 的最终轮内容默认永不持久化。存储它需要双重 opt-in服务端capture_assistant true对应AI_MEMORY_CAPTURE_ASSISTANTtrue客户端install-hooks --capture-assistant。启用后必须意识到以下几点策略原文的完整警告双重净化客户端先以内置模式脱敏之后才进入 spool/网络传输服务端再用自身配置的[sanitize]模式二次脱敏后再存储。操作员的extra_patterns只在服务端运行——因此仅被extra_patterns规则命中的秘密在到达服务端之前可能仍留在客户端 spool/传输中。客户端脱敏是不可逆的服务端allowlist无法恢复客户端已替换为[REDACTED]的文本捕获的 assistant 文本会流入 consolidation 与 reviewer 的 prompt若配置了云 LLM provider还会发送给该 provideropt-in 是全局的没有按项目的 marker 可以在开启后排除敏感仓库assistant 文本无法按路径归属。关闭服务端开关即可全局禁用摘录可能引用 ai-memory 从未见过的路径中的代码、秘密或内容Sanitizer是尽力而为的凭据剥离不是保证。配置模板对capture_assistant的注释完整复述了这些隐私警告crates/ai-memory-cli/templates/config.default.toml。净化器实现位于 crates/ai-memory-core/src/sanitize.rs内置模式覆盖 Bearer 令牌、厂商前缀 API 密钥sk-、sk_live_、ghp_、github_pat_、AKIA、AIza、Slack 形态的xoxb/xoxp/xoxa/xapp、JWT、PEM 私钥、URL 内嵌凭据postgres://user:passhost、各支持 provider 的命名环境变量、通用*_(KEY|TOKEN|SECRET|PASSWORD|CREDENTIAL)…形态以及~/.ssh、~/.aws、~/.kube、~/.config/gcloud、~/.gnupg下的路径。extra_patterns在启动时一次性编译非法正则直接中止启动allowlist按匹配逐条检查命中的片段原样保留如公共标识符PUBLIC_VERIFY_KEY不应被通用*_KEY规则误伤。9. 存储内容的 prompt 注入Handoff、项目 brief、managed workstream 包、MCP routing 与 LLM 维护 prompt 都明确将存储材料标记为不可信历史数据。净化和结构化输出 schema 只是纵深防御不能证明模型不被操纵操作员与 Agent 必须对照当前指令与 checkout 验证安全敏感声明。10. 搜索重排是出站数据的 opt-in设置AI_MEMORY_RERANKERllm会把每次符合资格的实时查询加上有界的页面标题与搜索片段发送给所配置的 LLM provider。要点managed 写入会经过 ai-memory 的净化器但手动编辑的 wiki 文件可能含未净化的文本实时查询有界但不净化——脱敏可能改变其含义JSON 编码、显式 untrusted-data prompt、严格分数校验、超时、四路并发上限concurrency cap限制了控制与可用性影响但都不让云 provider 变得私密需要查询或召回片段不离开服务器时保持重排关闭或使用本地 provider。配置模板中的reranker llm注释写明其代价与并发上限crates/ai-memory-cli/templates/config.default.toml。11. 发布物完整性SHA-256 与 GitleaksDocker wrapper 与独立 hook 安装使用 GitHub Release 资产及其SHA-256 摘要文件GitHub Actions固定到已审查的 commit发布任务默认只读令牌权限除 GitHub Release 发布者外Gitleaks 检查每个推送或提议的 commit 范围另有独立周度/手动工作流检查完整可达历史全历史扫描只认.gitleaksignore中已审查、精确的指纹添加 ignore 条目绝不替代从当前树中移除真实凭据并轮换。v1 范围外Out of scope以下威胁 v1明确不防御部署时须自行补足租户隔离与按用户 ACL数据库用户只提供归属不提供私有记忆。没有按用户或按项目的 ACL互不可见数据的用户必须运行独立的服务器/数据目录静态加密数据目录是明文文件系统树远程同步安全若将 wiki git 仓库推送到远程保护该通道SSH 密钥、GitHub 访问控制等是你自己的责任完美的语义 prompt 注入防护隐私剥离能去除明显的凭据、prompt 表面保留信任边界但没有文本过滤器能证明 LLM 会无视每一段对抗性文本面向敌意互联网的 DoS 防护hook 队列、请求体、速率限制与并发都有界但服务不是为直接暴露于不可信互联网设计的——请置于常规网络控制防火墙、代理之后。支持的版本只有最新 release 接收安全修复不向旧 minor 版本 backport。这要求使用者保持升级习惯及时跟进最新版本以获取安全补丁。实操速查综合策略文档与源码一套安全的部署姿势可以浓缩为场景推荐配置纯本机使用保持默认绑定127.0.0.1:49374无需令牌Host白名单保持默认局域网明文暴露非容器配置AI_MEMORY_AUTH_TOKEN或用--allow-insecure-no-auth显式覆盖须理解风险容器端口发布只发布127.0.0.1:49374:49374可免令牌更宽必须配令牌反向代理 /webTLS 终止 AI_MEMORY_AUTH__SECURE_COOKIEtrue参考 docs/https-via-proxy.md局域网访问域名AI_MEMORY_ALLOWED_HOSTS中加入客户端实际使用的 host/IP启用 assistant 捕获服务端capture_assistanttrue且客户端install-hooks --capture-assistant并接受全局生效的事实敏感查询保持reranker关闭或使用本地 provider多用户互不可见运行多个独立服务器/数据目录配置的完整安全相关项可在 crates/ai-memory-cli/templates/config.default.toml 中逐一核对认证中间件的测试用例crates/ai-memory-mcp/src/auth.rs则提供了可运行的验证样例展示每种凭据形态在 wire 层的真实行为。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考