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

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

Compartment हा agent memory store आहे. तो प्रत्येक record तयार करणाऱ्या machine वर encrypted ठेवतो आणि network service शी कधीही संपर्क साधत नाही. Agent memory क्षेत्रातील इतर पर्यायांपासून त्याला वेगळे करणारे दोन मुद्दे आहेत. Vault ही एक sealed file आहे. ती फक्त तुमचा passphrase उघडू शकतो. Embedding step स्थानिक पातळीवर चालतो. त्यामुळे memory मधील text vector मध्ये रूपांतरित करण्यासाठी कुठेही पाठवला जात नाही. Version 4.6.0 10 August 2026 रोजी प्रकाशित झाले. Licence Apache-2.0 आहे. ते PyPI वरून install करता येते.

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

हा guide 11 August 2026 रोजी वाचलेल्या project च्या documentation आणि release notes वर आधारित आहे. Compartment मध्ये command line tool सोबत desktop application, macOS वरील menu bar item आणि Windows मधील notification area icon उपलब्ध आहेत. Passphrase prompt automated container मधून चालवता येत नाही. पुढील माहिती 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 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. हा प्रकल्प वेगाने बदलत आहे. 10 August 2026 पर्यंत PyPI वर त्याच्या तीस आवृत्त्या उपलब्ध होत्या. त्यामुळे install करताना त्या दिवसाची current आवृत्ती घेण्याऐवजी आवृत्ती pin करा.

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

compartment --version ने तुम्ही pin केलेली आवृत्ती दाखवली पाहिजे. 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 दोनदा विचारली जाते आणि काहीही echo केले जात नाही. ही passphrase हीच एकमेव key आहे. प्रकल्प कोणताही password किंवा recovery phrase तयार करत नाही. हे जाणूनबुजून केले आहे: software कडे असलेले आणि तुमच्याकडे नसलेले कोणतेही credential उपलब्ध नाही.

त्याच्याशी काहीही जोडण्यापूर्वी परिणाम तपासा.

compartment status

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

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

डीफॉल्ट 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 ला तो भरण्यास सुरुवात करू द्या.

सर्व्हर किंवा memory server

Compartment ची रचना एका मशीनसाठीच केलेली आहे. Share करण्यासाठी locked file कॉपी करावी लागते किंवा export आणि import करावे लागते. एकाच वेळी लिहिणारा कोणताही समन्वय नसल्यामुळे, एकाच file कडे निर्देश करणारा laptop आणि workstation एकमेकांचे बदल overwrite करतील.

अनेक मशीनना एकाच वेळी समान 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 अधिक मजबूत पर्याय आहे. मशीन बदलताच agent सर्वकाही विसरणे हा धोका असेल, तर server योग्य पर्याय आहे.

FAQ

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

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

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

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

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

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

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

एकाच वेळी नाही. Locked vault ही एकच portable file असते. Document केलेली पद्धत म्हणजे ती lock करणे, copy करणे आणि नंतर --vault वापरून दुसऱ्या machine वर unlock करणे. Concurrent access नसल्यामुळे दोन machines ने एकाच file मध्ये write केल्यास memories हरवतील. त्यासाठी memory server चालवा.