安全

每個客戶一個資料庫

你嘅記憶唔係一個共享表格入面嘅一行，亦冇「客戶」呢一欄。每位客戶都有屬於佢哋自己嘅記憶。 自有數據庫. 冇共享嘅資料表，亦冇可能出錯嘅跨客戶查詢，因為界限就喺資料庫本身，而唔係需要有人記得去寫嘅過濾條件。

每次發布都會由外部測試嗰條界線：用兩個真實帳戶，檢查每一個會回傳資料嘅門，確認雙方都睇唔到對方。除非通過，否則唔會發布。

鎖匙，同埋邊個可以用

我哋無法顯示你嘅密鑰。

API密鑰只會喺建立嗰陣顯示一次俾你。我哋儲存嘅係SHA-256哈希值——所以就算有人攞到我哋資料庫嘅副本，都攞唔到可用嘅密鑰；我哋或者攻擊者都讀唔返你嘅密鑰。撤銷密鑰之後，大約一分鐘內就會影響到服務，同時亦都會即刻影響到儲存你記憶嘅嗰部機。

可以縮窄鎖匙範圍。

鎖匙唔一定要有無所不能嘅力量。鎖匙可以係 按專案劃分範圍 — 可讀寫、唯讀，或者完全隱藏——呢個正係適合承辦商、CI任務，或者冇需要睇你其他工作嘅單一用途代理嘅形態。如果金鑰嘅權限範圍損壞或無法讀取，就會被拒絕所有權限，而唔係獲得所有權限。

雙重驗證

你嘅帳戶喺登入時可能需要第二重驗證方式，一旦啟用，佢就會喺登入時被強制要求使用，而唔係淨係顯示為一個設定。我哋建議大家用呢個功能，但唔強制要求：你嘅資料受到嘅保護程度取決於存放該資料嘅帳戶嘅安全性，但如果要將刪除自己資料嘅行為同註冊手機號碼掛鈎，咁情況會更差。

防止自己嘅代理造成傷害

呢個係大多數服務都冇考慮到嘅部分。你嘅記憶會持續由人工智能代理嚟處理——而呢啲代理可能會出錯，或者收到藏喺佢哋被要求閱讀嘅內容中嘅惡意指令，又或者喺人類發現之前幾小時就刪除錯誤嘅資料。

所以原始的對話檔案是刻意設計成他們無法取得嘅。沒有任何工作人員可以刪除單一訊息，也完全無法查看過去三個月的記錄。較舊的歷史記錄只能按專案整體移除。而要刪除整個專案——這唯一能一次性處理所有檔案的操作——則任何層級的工作人員都無法執行；這需要在帳戶面板中由人類手動輸入專案名稱才能完成。

呢個問題重要嘅原因好簡單：整理過嘅記憶係衍生出嚟嘅，而檔案係原始版本。任何壞編輯失去嘅嘢都可以由歷史重建。冇嘢可以重建歷史。

加密、備份，同埋你嘅數據喺邊度

資料在傳輸過程中會以 TLS 進行加密。而當資料處於靜止狀態時，則會被加密保存。 兩次: 底層有完整卷級的加密，而其上嘅資料庫——每段對話、每條記錄以及寫入預先記錄——都經過了加密處理。 每個客戶的獨有密鑰, 與其他所有客戶的資料分開存放。用於解鎖儲存空間的密鑰根本就沒有儲存在資料庫伺服器上：被盜的磁碟、洩露的圖像或已停用的硬碟都無法用來解鎖資料。

刪除即為加密。

由於每個客戶都有自己嘅密鑰，要抹除你的資料並非易事。 你的密鑰已經被破壞，而你的資料庫也遺失了。, 而剩餘的內容則連我們在內的任何人也無法閱讀。經過加密的備份資料會被直接刪除，而不會讓其過期；至於任何尚存的副本，也會在我們的備份系統循環處理過程中，在最多30天之內被清除。我們根本沒有副本可以拿回來。

每個客戶的加密方式無法涵蓋哪些內容

有兩個明確的界限。資料庫引擎會保存用於內部查詢規劃的統計資料，這些資料是從列值中抽取的樣本；這些樣本受到整體加密保護，而非由你的Personal密鑰來保護。而靜止狀態下的加密也就是如此——只有在需要時才會解密你的數據，以便處理查詢及進行資料整理，因此「我們從不查看你的數據」是我們的政策與存取控制措施，而非數學上不可能做到的事。我們寧願告訴你界限在哪裡，也不想讓你以為根本沒有界限。

備份會在每晚執行，是 在離開我們的設備之前已經被加密, 佢哋會按照輪流安排儲存喺歐盟以外的地點，儲存期最長為三個月。當一個帳戶被刪除時，其備份也會一同被刪除，而任何剩餘的副本都會在30天內清除。

你嘅記憶完全喺歐盟內儲存、索引同搜尋——我哋嘅伺服器喺法蘭克福，備份喺法爾肯斯坦，兩者都喺德國。搜尋嵌入係喺我哋自己嘅機器上計算，永遠唔會離開佢哋。

唯一嘅例外係AI整理。被整理嘅段落會被傳送至 Ollama，喺美國, 已處理並返回。Ollama嘅發布條款指出，輸入同輸出只會暫時處理，永遠唔會用嚟訓練模型——呢個係佢哋嘅承諾，喺佢哋自己嘅條款中，我哋係引用佢哋嘅講法，唔係我哋嘅承諾。冇其他嘢會離開歐盟。如果你需要整理都唔離開歐盟，可以喺專用部署上做到——請提出要求。每個子處理器，連同目的同位置，都列喺 私隱政策.

我哋嘅運作方式

預設採用最低權限原則

該服務以非特權用戶嘅身份喺其容器內運行，從唔以 root 身份運行。其資料庫角色亦唔係超級用戶，而且無法從主機上讀取檔案。呢啲規定都會喺每次發布前自動驗證，而唔係單靠推測。

內部端點喺邊緣被鎖定

用嚟建立帳戶同驗證鎖匙嘅端點，只有我哋自己嘅控制平面先可以到達，請求到達之前喺網絡邊緣認證，之後再透過背後嘅共享秘密認證。兩道鎖，唔係一道。

失敗即關閉

當有資料缺失或無法辨識時，該服務會直接拒絕處理，而唔係嘗試猜測。無法驗證嘅密鑰亦會被拒絕。損壞嘅權限唔會授予任何權限。如果缺少 webhook 簽名密碼，就會拒絕所有事件，而唔係相信所接收到嘅資料。呢種係刻意設計嘅策略：記憶服務嘅失敗模式應該係「冇回應」，而唔係「俾錯客戶嘅回應」。

每次發佈都經由外部驗證。

任何版本出貨之前，一個自動化系統會由全新帳戶開始，經由真實網絡連線行成個產品：註冊、發出同撤銷密鑰、儲存同叫返記憶、兩個活躍帳戶之間嘅隔離、資料匯出，同埋徹底刪除。佢要完全通過先至會出貨，唔係就唔會發佈。

報告安全問題

如果你認為自己發現咗安全漏洞，請喺話俾其他人知之前先話俾我哋知，我哋會同你一齊處理。聯絡資料刊登喺 /.well-known/security.txt 或者寫信畀 [email protected]. 我哋唔會威脅嗰啲誠實報告嘅研究人員。

更深層嘅要求——例如數據處理協議、喺你揀嘅地區做專用部署，或者將內容管理限制喺歐盟入面——呢啲我哋都會直接處理。問我哋就得。