Compartment: offline encrypted agent memory कसे काम करते

Compartment वेगळे काय करते

Compartment हे agent memory store आहे. ते प्रत्येक record ज्या मशीनवर तयार होते त्याच मशीनवर encrypted ठेवते आणि कोणत्याही network service शी संपर्क साधत नाही. Agent memory क्षेत्रातील इतर पर्यायांपासून ते दोन बाबींमुळे वेगळे ठरते. Vault ही एक sealed file आहे आणि ती फक्त तुमच्या passphrase ने उघडते. Embedding प्रक्रिया स्थानिक पातळीवर चालते. त्यामुळे memory मधील मजकूर vector मध्ये रूपांतरित करण्यासाठी कुठेही पाठवला जात नाही. Version 4.6.0 हे 10 August 2026 रोजी प्रकाशित झाले. Licence Apache-2.0 आहे आणि ते PyPI वरून install करता येते. त्यानंतर newer releases प्रकाशित झाले आहेत. 12 October 2026 रोजी PyPI वरील latest version 4.11.0 आहे, जी 30 September 2026 रोजी प्रकाशित झाली. हे guide 4.6.0 वर pinned आहे.

हा threat model संबंधीचा दावा आहे. त्यामुळे हे guide त्याचा तसाच विचार करते. At-rest encryption आणि offline design यामुळे विशिष्ट गोष्टी सुरक्षित राहतात. इतर गोष्टी मात्र उघड्या राहतात. पुढील टप्प्यातील अडचणी याच अंतरातून निर्माण होतात.

हे guide project च्या 4.6.0 version साठीच्या स्वतःच्या documentation चे अनुसरण करते. ते शेवटचे 12 October 2026 रोजी पुन्हा वाचले गेले. Compartment desktop application, macOS वरील menu bar item आणि Windows मधील notification area icon पुरवते. यासोबत command line tool देखील असते. Automated container मधून passphrase prompt हाताळता येत नाही. पुढील माहिती documented behaviour म्हणून घ्या; येथे तिचे प्रत्यक्ष मोजमाप केलेले नाही. त्यावर खऱ्या माहितीचा विश्वास ठेवण्यापूर्वी spare machine वर ते चालवून पाहा.

वापरात नसताना केलेले encryption प्रत्यक्षात कशाचे संरक्षण करते

Vault XChaCha20-Poly1305 ने sealed आहे. हे AEAD (authenticated encryption with associated data) cipher आहे. Master key असलेले keyslots Argon2id ने wrapped आहेत. Argon2id हे password hashing function आहे. ते जाणीवपूर्वक धीमे ठेवलेले असून त्याला मोठ्या प्रमाणात memory आवश्यक असते.

यातून दोन गोष्टी स्पष्ट होतात. चोरीला गेलेल्या disk वरील file ची प्रत, जुन्या backup मधील प्रत किंवा support ticket ला जोडलेली प्रत ही केवळ bytes असते. त्यातून दुसरी कोणतीही माहिती मिळत नाही. File उघडताना एक bit जरी बदललेला आढळला, तरी authentication fail होते. त्यामुळे corruption मुळे चुकीचे उत्तर मिळत नाही; त्याऐवजी स्पष्ट error मिळतो.

Embedding vectors देखील encrypted असतात. हे दिसते त्यापेक्षा अधिक महत्त्वाचे आहे. Embedding म्हणजे hash नाही. Embedding inversion वरील संशोधनातून केवळ vector वापरून मूळ text चे वाचता येणारे तुकडे पुनर्प्राप्त करण्यात आले आहेत. त्यामुळे encrypted database शेजारी plaintext vector index ठेवणे म्हणजे database जवळजवळ उघडे ठेवण्यासारखे आहे. Compartment plaintext index disk वर लिहित नाही.

Deletion म्हणजे प्रत्यक्ष deletion. प्रत्येक record सोबत स्वतंत्र key असते आणि compartment forget --shred ती key नष्ट करते. त्यामुळे उरलेला ciphertext कोणालाही decrypt करता येत नाही; तुम्हालाही नाही. याची तुलना database file मधून delete केलेल्या row शी करा. एखाद्या गोष्टीने overwrite करेपर्यंत ती row सामान्यतः free pages मध्ये वाचता येते.

Offline असणे हा याचा दुसरा महत्त्वाचा भाग आहे. काहीही upload केले जात नाही. त्यामुळे तुमच्या memories ठेवणारे vendor account नसते आणि त्या उघड करणारी API key देखील leak होऊ शकत नाही.

Compartment कशापासून संरक्षण करत नाही

हा दावा vault च्या सीमारेषेपर्यंतच लागू होतो. ती सीमारेषा दिसते त्यापेक्षा जवळ आहे.

Agent plaintext वाचतो. Recall memory decrypt करून मजकूर agent कडे पाठवते. तो agent hosted model असल्यास, memory पुढील prompt मध्ये model provider कडे जाते. Context window मधील इतर सर्व मजकुराप्रमाणेच. At-rest encryption फाइलचे संरक्षण करते. Retrieval चे संरक्षण करत नाही. त्यामुळे AI agents पासून secrets दूर ठेवण्याचे नियम store encrypted असल्यामुळे शिथिल होत नाहीत. Memory म्हणून जतन केलेला password म्हणजे तो prompt मध्ये आपोआप paste करण्याची व्यवस्था केलेला password आहे.

चालू machine वरील unlocked vault उघडाच असतो. Project च्या security notes मध्ये हे स्पष्टपणे नमूद आहे. Vault unlocked असताना master key आणि working set RAM मध्ये असतात. Python buffer पुसला जाईल याची हमी देऊ शकत नाही. तसेच swap किंवा hibernation image मुळे ती memory disk वर लिहिली जाऊ शकते. तुमच्या user म्हणून चालणाऱ्या malware ला cipher तोडण्याची गरज नसते. ते आधीच unlocked असलेल्या vault कडे विनंती करू शकते.

Caller identity ही declarative असते. प्रत्येक caller साठी namespaces प्रतिबंधित करता येतात. मात्र caller चे नाव host process कडून येते. त्यामुळे नावाबद्दल खोटी माहिती देणाऱ्या host ला तो ज्या grants चा दावा करतो ते grants मिळतात. Namespace permissions ही organisation आहे; hostile local program विरुद्ध security boundary नाही.

Shredding ला copies पर्यंत पोहोचता येत नाही. forget --shred current file मधील key नष्ट करते. Shred करण्यापूर्वी घेतलेल्या backup मध्ये तो record अजूनही असतो. त्या दिवसाच्या passphrase ने तो अजूनही उघडता येतो.

कमकुवत passphrase मुळे पुढील चर्चा निरर्थक ठरते. Argon2id प्रत्येक guess महाग करते. मात्र word list मध्ये असलेल्या passphrase चे संरक्षण ते करू शकत नाही.

Pinned release मधून Compartment install करा

Compartment ला Python 3.11 किंवा त्यापुढील version आवश्यक आहे. Project वेगाने बदलते. 26 July ते 10 August 2026 दरम्यान PyPI वर 23 releases आणि 12 October 2026 पर्यंत 35 releases प्रकाशित झाल्या आहेत. त्यामुळे install करताना त्या दिवसाची current version घेण्याऐवजी version pin करा.

python3 --version
pip install "compartment==4.6.0"
compartment --version
compartment init

compartment --version ने तुम्ही pinned केलेली version दाखवली पाहिजे. Shell ने compartment: command not found दाखवले, तर install directory तुमच्या PATH मध्ये नाही. बहुतांश systems वर ती directory ~/.local/bin असते. pipx install compartment==4.6.0 आणि uv tool install compartment==4.6.0 स्वतःचे paths व्यवस्थापित करून ही अडचण टाळतात.

compartment init passphrase दोनदा विचारते आणि कोणतेही अक्षर दाखवत नाही. ही passphrase हाच एकमेव key आहे. Project कोणताही password किंवा recovery phrase तयार करत नाही. हा निर्णय जाणीवपूर्वक घेतलेला आहे: तुमच्याकडे नसलेले कोणतेही credential software कडे ठेवलेले नाही.

कुठलीही जोडणी करण्यापूर्वी result तपासा.

compartment status

सुरळीत चालणारा vault unlocked असल्याचे दाखवतो. तो locked असल्याचे दाखवत असल्यास compartment unlock चालवा आणि passphrase द्या. Restart केल्यानंतर vault पुन्हा locked होतो, कारण तो उघडा ठेवणारे credential प्रत्येक boot साठीच्या secret वर अवलंबून असते. macOS वर compartment unlock --keychain वापरल्यास ते credential system keychain मध्ये साठवून reboot नंतरही vault उघडा ठेवता येतो.

डेटा प्रत्यक्षात कुठे साठवला जातो

डीफॉल्ट vault ~/.compartment/memory.vault येथे आहे. कोणत्याही command मध्ये --vault PATH वापरून तो दुसऱ्या ठिकाणी निर्देशित करा किंवा COMPARTMENT_VAULT environment variable वापरा.

ही एकच file संपूर्ण store आहे. सुरुवातीला format version आणि Argon2id keyslots असलेला header असतो. त्यानंतर sealed payload आणि नवीन memories जोडल्या गेल्यावर शेवटी append केलेल्या journal entries असतात. प्रत्येक journal entry ची रचना तिची length आणि त्या length साठी CRC (cyclic redundancy check) यांसह केली जाते. त्यामुळे crash मुळे write अपूर्ण राहिल्यास ती entry data म्हणून वाचली जात नाही; truncated entry म्हणून ओळखली जाते. Compaction vault ला serialise करते, temporary file लिहिते, त्यावर fsync करते आणि नंतर ती file योग्य ठिकाणी rename करते. त्यामुळे reader ला अर्धवट लिहिलेला vault कधीही दिसत नाही.

याचा उपयोगी परिणाम असा आहे: backup script नेमका एकच path copy करते. अडचण अशी आहे: तुम्ही त्यावर grep चालवू शकत नाही आणि text editor मध्ये त्याची दुरुस्ती करू शकत नाही. cat वापरून वाचता येईल आणि git मध्ये commit करता येईल अशी memory हवी असल्यास, Memmy च्या साध्या स्थानिक memory files हा याच्या उलट पर्याय आहे. कोणती गोष्ट अधिक चिंतेची आहे यावर दोन्ही पर्याय योग्य ठरू शकतात: चोरीला गेलेला laptop की बिघडणारे tool.

compartment uninstall software काढून टाकते आणि vault ठेवते. --purge फक्त जाणीवपूर्वक तेच करायचे असेल तेव्हाच पास करा.

एजंटशी जोडणे

एका command ने समर्थित client जोडला जातो.

compartment integrate --list
compartment integrate claude

Claude Code साठी हा command MCP (model context protocol) server entry आणि PostToolUse hook ~/.claude/settings.json मध्ये लिहितो. त्यापूर्वी संबंधित file चा backup घेतो. तो /compartmentalize skill ~/.claude/skills/ अंतर्गत install करतो. तसेच ~/.claude/CLAUDE.md मध्ये managed block जोडतो. या block मध्ये Compartment, agent वापरत असलेल्या file-based memory पेक्षा प्राधान्यक्रमाने वापरायचे असल्याचे नमूद केलेले असते. दोन्ही भागांची पुष्टी करा:

compartment hook status
compartment recent

Server स्वतः नोंदवायचा असल्यास:

claude mcp add --scope user compartment -- \
    compartment --vault ~/.compartment/memory.vault --caller claude-code serve

इतर कोणताही MCP सक्षम host स्वतःच्या caller name सह हाच server वापरतो.

{ "mcpServers": { "compartment": {
    "command": "compartment",
    "args": ["--vault", "/path/to/memory.vault",
             "--caller", "your-agent-name", "serve"] } } }

प्रत्येक host साठी वेगळे --caller value द्या. हे audit log मध्ये नोंदवले जाणारे label आहे. Namespace grants याच key विरुद्ध लिहिले जातात. त्यामुळे एकच name वापरल्यास दोन्हींचा उपयोग होत नाही.

Claude Code ने आधीच स्वतःच्या memory files मध्ये facts लिहिले असतील, तर काहीही हलवण्यापूर्वी काय हलवले जाईल ते compartment import-claude --dry-run दाखवते. आधी Claude Code आपल्या memory files मध्ये काय ठेवते हे वाचा. कारण एक वर्षाच्या notes नवीन vault मध्ये import केल्यास memory store मध्ये कोणीही ठेवायचे ठरवले नसलेल्या गोष्टी साठतात.

स्थानिक vault किती वेगवान आहे

वैयक्तिक आकाराच्या vault साठी प्रकल्पाने प्रकाशित केलेले आकडे खाली दिले आहेत. हे आकडे या ठिकाणी केलेल्या चाचणीवर आधारित नसून, प्रकल्पाच्या दस्तऐवजीकरणातून घेतलेले आहेत.

[
  {
    "label": "Store one memory, end to end",
    "latency_ms": 40
  },
  {
    "label": "Embed one memory, bundled model",
    "latency_ms": 25
  },
  {
    "label": "Hybrid search, median",
    "latency_ms": 11.6
  },
  {
    "label": "Vector search at 20k records, p95",
    "latency_ms": 0.68
  }
]

एक memory साठवण्यासाठी 40 ms लागतात, असे नमूद केले आहे. तसेच वीस हजार records मध्ये vector search केल्यास 95th percentile साठी 0.68 ms लागतात. memory स्थानिक ठेवण्यामागील प्रकल्पाचा तर्क साधा आहे: hosted memory API साठी network round trip ला अनेकदा येथे केलेल्या पूर्ण hybrid search च्या 11.6 ms median पेक्षा जास्त वेळ लागतो.

दोन design details मुळे search चे हे आकडे स्पष्ट होतात. वीस हजार records पेक्षा कमी असताना Compartment प्रत्येक vector शी query ची तुलना करते. त्यामुळे recall अचूक मिळतो; तो approximate पद्धतीवर आधारित नसतो. त्यापेक्षा अधिक records असतील, तर Compartment HNSW (hierarchical navigable small world) वापरते. हा approximate index वेगासाठी थोडा recall गमावतो. vault embedding model चा SHA-256 hash देखील नोंदवते आणि वेगळ्या model अंतर्गत उघडण्यास नकार देते. कारण दोन वेगवेगळ्या models मधील vectors ची तुलना केली तरी कोणतीही error दिसू शकत नाही, आणि परत मिळणाऱ्या scores चा अर्थ उरत नाही.

बॅकअप, आणि पुढच्या वर्षीही उघडता येणारी प्रत

Locked vault ही एक portable file असते, त्यामुळे ती हलवणे म्हणजे तिची प्रत तयार करणे.

compartment lock
scp ~/.compartment/memory.vault other-machine:
compartment --vault memory.vault unlock

प्रथम ती lock करा. Agent लिहित असताना प्रत तयार केल्यास journal entry मधील append प्रक्रिया अर्धवट अवस्थेत पकडली जाऊ शकते. CRC framing मुळे reader तो शेवटचा अपूर्ण भाग वगळू शकतो, पण त्यातील memory परत मिळत नाही. compartment lock --sign file वर Ed25519 manifest लावून ती seal करते. त्यामुळे passphrase न देता receiving machine वर प्रत पूर्णपणे आणि अखंड पोहोचली आहे का हे पडताळता येते.

File आधीच seal केलेली असल्यामुळे सामान्य cloud storage हे तिच्यासाठी स्वीकारार्ह ठिकाण आहे. Encryption at rest चा थेट फायदा येथे मिळतो: backup target ला कोणतीही memory दिसत नाही.

दोन सूचना लक्षात ठेवा. Shredding backups पर्यंत पोहोचत नाही. त्यामुळे आज crypto shredded केलेला record, मागील आठवड्याच्या copy मध्ये, मागील आठवड्याची passphrase असलेल्या कोणालाही वाचता येतो. तसेच compartment export --plaintext संपूर्ण vault unencrypted स्वरूपात लिहिते. दुसऱ्या प्रणालीकडे migration करण्यासाठी हे योग्य साधन आहे. मात्र ~/Downloads मध्ये ठेवण्यासाठी ही चुकीची file आहे.

कमी copies ठेवा आणि त्यांना date द्या. कोणीही memory store मधील जुन्या प्रती काढून टाकत नसेल, तर तो liability बनतो. जुन्या agent memories retrieval ला शांतपणे का दूषित करतात यामागचा मुद्दा हाच आहे.

की हाताळणी, रोटेशन आणि दुसरा घटक

compartment rekey
compartment 2fa enable
compartment 2fa status

rekey सध्याच्या फाइलच्या keyslot मधील master key पुन्हा wrap करून passphrase बदलते. जुन्या प्रतींमध्ये जुनी passphraseच राहते, कारण बदलापूर्वी ते bytes sealed झालेले असतात आणि त्यांना मागे जाऊन संपादित करण्याची कोणतीही प्रक्रिया नसते. प्रतींचेही रोटेशन करा किंवा जुनी passphrase अजूनही काहीतरी उघडू शकते हे स्वीकारा.

2fa enable keyfile हा दुसरा घटक म्हणून जोडते. Key derivation दरम्यान तो passphrase सोबत वापरला जातो, त्यामुळे vault उघडण्यासाठी दोन्ही आवश्यक असतात. त्यामुळे हरवू शकणाऱ्या गोष्टींची संख्याही दुप्पट होते. Vault असलेल्या मशीनपासून keyfile वेगळ्या ठिकाणी ठेवा.

Scripts आणि CI (continuous integration) साठी passphrase COMPARTMENT_PASSPHRASE environment variable द्वारे दिली जाऊ शकते आणि unlock --passphrase-stdin ती pipe मधून वाचते. Pipe ला प्राधान्य द्या. त्याच user च्या मालकीच्या इतर processes ना environment variable वाचता येते. तसेच ती job logs मध्ये नोंदली जाण्याची शक्यता असते.

Audit history hash chain ने जोडलेली असते. compartment audit verify तिच्यातील दुवे तपासते आणि पहिला तुटलेला दुवा दाखवते. प्रत्येक restore नंतर ते चालवा, कारण अशा वेळी न कळत truncated झालेली file दिसून येते.

पासफ्रेज हरवल्यावर काय होते

काहीही होत नाही, आणि हीच या रचनेमागील कल्पना आहे. कोणतेही reset, recovery phrase किंवा लिहून ठेवण्यासाठी address नसतो, कारण तुमच्या स्मरणशक्तीबाहेर आणि ऐच्छिक keyfile व्यतिरिक्त key ची कोणतीही प्रत अस्तित्वात नसते. vault यादृच्छिक दिसणाऱ्या bytes ची फाइलच राहते.

म्हणून recovery plan हा vault साठी नसून passphrase साठी असतो. compartment init चालवलेल्या दिवशी ते password manager मध्ये नोंदवा. त्यानंतर त्याची चाचणी घ्या: vault lock करा, लिहून ठेवलेल्या माहितीचा वापर करूनच तो unlock करा आणि हे यशस्वी झाल्यावर agent ला तो भरण्यास सुरुवात करू द्या.

Compartment किंवा memory server

Compartment ची रचना single machine साठी आहे. Machines मधील sharing म्हणजे locked file copy करणे किंवा export आणि import करणे. Advisory file lock त्यांचे writes क्रमाने पार पाडत असल्यामुळे त्याच machine वरील अनेक agents एकाच vault चा एकाच वेळी वापर करू शकतात. दोन machines कडून एका file वर writes करण्याबाबत documentation मध्ये काहीही दिलेले नाही. त्यामुळे laptop आणि workstation ला network share किंवा sync folder वरील एकाच vault कडे point करू नका.

अनेक machines ना एकाच वेळी समान memory आवश्यक असल्यास, ती server ची समस्या आहे. VPS वरील self-hosted Mem0 memory server याचे उत्तर देते: एक endpoint, अनेक clients आणि laptop पेक्षा अधिक काळ टिकणारी memory. याची किंमत स्पष्टपणे समजून घ्या. हा server साठवलेला data वाचू शकणारी process चालवतो. त्यामुळे तुमच्या threat model मध्ये VPS आणि त्याच्या API पर्यंत पोहोचू शकणारे सर्वजण समाविष्ट होतात.

तुम्हाला प्रत्यक्षात कोणत्या नुकसानीची भीती वाटते त्यानुसार निवड करा. चोरीला गेलेला laptop किंवा vendor ने तुमच्या notes वाचणे ही भीती असल्यास encrypted local vault अधिक मजबूत पर्याय आहे. Machines बदलताच agent ने सर्व काही विसरणे ही भीती असल्यास server योग्य पर्याय आहे.

FAQ

Compartment चे encryption प्रत्यक्षात कशाचे संरक्षण करते?

ते file चे संरक्षण करते. Vault XChaCha20-Poly1305 ने sealed आहे. त्याचे keyslots Argon2id ने wrapped आहेत. Embedding vectors देखील encrypted असतात. त्यामुळे चोरीला गेलेली disk किंवा जुना backup readable data ऐवजी केवळ bytes देतो. Running machine वरील unlocked vault चे ते संरक्षण करत नाही. Vault उघडा असताना master key RAM मध्ये असते. Recall नंतर plaintext स्वरूपात मिळालेल्या memory सोबत agent काय करतो यावरही ते नियंत्रण ठेवत नाही.

Compartment offline असल्यास माझ्या memories माझ्या model provider पासून private राहतात का?

त्या recall होईपर्यंतच. Storing आणि searching network शिवाय होतात. Embedding model स्थानिक पातळीवर चालत असल्यामुळे write वेळी काहीही machine बाहेर जात नाही. Read वेळी agent ला plaintext मिळतो. तो agent hosted model असल्यास memory prompt मध्ये जाते आणि context window मधील इतर मजकुराप्रमाणे provider कडे पाठवली जाते. Credential memory म्हणून कधीही store करू नका.

माझी Compartment passphrase हरवल्यास काय होते?

Vault recover करता येत नाही. हे जाणीवपूर्वक असे आहे. Compartment कोणतेही seed किंवा recovery phrase तयार करत नाही आणि तुमच्याकडे नसलेले कोणतेही credential ठेवत नाही. त्यामुळे reset करण्यासारखे काहीही नाही. Passphrase password manager मध्ये ठेवा. Vault साठवणाऱ्या machine पासून कोणतीही 2FA keyfile वेगळी ठेवा. Vault मध्ये महत्त्वाची माहिती ठेवण्यापूर्वी त्याची copy unlock करता येते याची खात्री करा.

दोन machines एकच Compartment vault share करू शकतात का?

एकाच वेळी नाही. Locked vault ही एकच portable file असते. Documented पद्धत म्हणजे vault lock करणे, त्याची copy करणे आणि नंतर --vault वापरून दुसऱ्या machine वर unlock करणे. Advisory file lock agents चे writes एकाच machine वर क्रमाने पार पाडतो, एवढेच documentation मध्ये समाविष्ट आहे. दोन machines कडून एका file वर writes करण्याबाबत त्यात काहीही दिलेले नाही. त्यामुळे अशा setup मुळे memories गमावल्या जाऊ शकतात असे समजा. अशी गरज असल्यास memory server चालवा.