Encrypted memory export, AES-256-GCM, tamper detection, and the engineering work behind safer memory portability.
AI systems are becoming increasingly dependent on persistent memory.
An AI employee needs to retain useful context across tasks, retrieve relevant information, and operate within clearly defined boundaries. But memory is not just about storing information. It also involves protecting that information when it moves between systems.
With RagLeap Memory v0.3.1, we've taken another step towards building a stronger, security-conscious memory infrastructure for open-source AI employees.
This release introduces optional encrypted memory export and import, powered by AES-256-GCM through ragleap-security.
This article explains what changed, how the encryption works, what we tested, and — just as importantly — what this release does not claim to protect.
1. Why encrypted memory portability matters
Memory portability is useful when operators need to:
- Move memory exports between environments.
- Back up selected memory scopes.
- Transfer memory data securely.
- Preserve useful context across deployments.
- Manage memory exports with stronger confidentiality guarantees.
However, a portable memory file can contain sensitive information.
A plain export may be convenient, but anyone who obtains that file could potentially inspect its contents.
RagLeap Memory 0.3.1 adds an optional encryption layer to exported memory files while preserving the existing plain-export behaviour for users who do not enable encryption.
The goal is straightforward: make memory portability safer without unexpectedly changing existing workflows.
2. AES-256-GCM encrypted exports
The new encryption capability uses AES-256-GCM through the ragleap-security package.
The memory package provides the export/import workflow, while the security package handles the underlying encryption.
Install the optional cryptography dependency:
pip install "ragleap-memory[crypto]==0.3.1"
The base package remains available without the optional extra:
pip install ragleap-memory==0.3.1
If encryption is requested without the optional dependency, the package raises an error explaining which extra is required.
This keeps the encryption dependency optional and avoids changing the behaviour of installations that do not need it.
3. New encryption APIs
Version 0.3.1 adds optional encryption and decryption parameters to the existing file and stream APIs.
The new export signature is:
export_file(
scope,
path,
encrypt_with=None,
passphrase=None,
context=None,
)
Import operations support:
import_file(
...,
decrypt_with=None,
passphrase=None,
context=None,
)
And the same decryption options are available through import_stream.
The implementation supports:
-
Keyfor encryption and decryption. -
KeyRingfor key selection and rotation workflows. - Passphrase-based encryption using scrypt-derived keys.
- Context-bound encrypted exports.
Passphrase derivation happens once per file rather than once per individual memory entry.
This provides flexibility for different operational requirements without forcing every user into one key-management approach.
4. Tamper detection and context binding
Encryption alone is not the complete story.
The release also strengthens the relationship between encrypted entries and their original export.
Each encrypted line is bound to:
- A fixed cryptographic label.
- The SHA-256 hash of the exact header line.
- Its position in the export.
- The supplied context.
This means changes to encrypted data, moving entries, duplicating entries, or attempting to reuse entries across different export contexts will cause decryption to fail.
Incorrect keys or contexts also result in decryption failure.
The import process checks the expected entry count, so dropped or additional lines are rejected.
Errors are reported with the relevant line number rather than silently accepting corrupted data.
These checks are intended to make accidental modification and tampering detectable.
5. No silent downgrade between encrypted and plain exports
A security-sensitive import operation should not silently change its interpretation of a file.
RagLeap Memory 0.3.1 explicitly distinguishes encrypted and plain exports.
The new behaviour includes:
- Encrypted exports require the appropriate decryption key or passphrase.
- Supplying encryption credentials for a plain export causes the import to refuse it.
- Unsupported header versions are rejected.
- Version 2 headers identify encrypted exports.
- Existing version 1 plain exports continue to work.
Importantly, existing calls without the new arguments retain their 0.3.0 behaviour.
This makes the release additive rather than a breaking change for existing users.
6. Existing import safeguards remain in place
Decryption does not bypass the existing memory import controls.
After decryption, data still passes through the established import path, including:
- Trust limits.
- Scope validation.
- Quotas.
- Size limits.
- A single database transaction.
- Existing import safety checks.
The principle is important: encryption should protect the exported file, but it should not become a shortcut around the controls governing what enters the memory system.
7. Testing beyond ordinary unit tests
Security-sensitive changes require more than checking whether encryption and decryption work in a basic example.
For this release, we performed several layers of verification.
Test results:
| Verification | Result |
|---|---|
| VPS test suite, Python 3.10 | 532 passed |
| Sandbox test suite, Python 3.10 | 532 passed |
| Sandbox test suite, Python 3.12 | 532 passed |
| Mutation testing | 232/232 caught |
| GitHub CI checks on implementation PR | 55/55 passed |
Mutation testing deliberately introduces changes into the implementation to determine whether the tests detect them.
In this release, all 232 tested mutations were detected in the reported sandbox runs.
We also performed release-artifact verification:
- The five Python files in the published wheel were compared with the source at the release tag.
- Fresh installations were tested with and without the optional crypto extra.
- The source distribution test suite was run against the installed wheel.
- A real database export created using RagLeap Memory 0.3.0 was successfully opened and imported.
- RagLeap Memory 0.3.0 rejected a 0.3.1 encrypted export with the expected unsupported-version behaviour.
The published wheel and source distribution were also checked against their recorded SHA-256 digests and release provenance.
These checks provide evidence that the published package corresponds to the tested release source.
8. Important security limitations
We want to be precise about what this release protects.
Encrypted export files are protected — not the entire memory environment.
The current implementation does not encrypt:
- The underlying SQLite database.
- Process memory while exporting or importing.
- Other application data outside the exported file.
There are additional limitations:
- The export header reveals the number of entries.
- Encrypted line lengths reveal approximate entry sizes.
- Anyone possessing the appropriate key can read or forge an export.
- Replaying an older valid export is not detected by this release.
- Decrypted content remains untrusted input and must still pass the import safeguards.
- No independent security audit has been performed.
Large imports are also subject to the configured size limit, which defaults to 64 MiB.
We believe transparent security boundaries are essential. Encryption should not be presented as a guarantee that every part of a memory system is secure.
9. Where this fits into RagLeap's memory direction
RagLeap is building an open-source, self-hosted AI employee platform.
Our memory direction is not simply about sharing personal context between different chat applications.
We are working towards a stronger memory infrastructure that can support AI employees and enterprise workflows.
That requires several capabilities to work together:
- Persistent and structured memory.
- Scoped access and isolation.
- Reliable retrieval.
- Security and controlled data portability.
- Memory governance and lifecycle management.
- Integration with the wider AI employee architecture.
RagLeap Memory 0.3.1 is one step in that direction.
It does not complete the enterprise memory roadmap, but it adds an important security capability while preserving compatibility with existing workflows.
10. Install RagLeap Memory 0.3.1
Standard installation:
pip install ragleap-memory==0.3.1
With encrypted export/import support:
pip install "ragleap-memory[crypto]==0.3.1"
Project resources:
- GitHub: https://github.com/ragleap/ragleap-core
- PyPI: https://pypi.org/project/ragleap-memory/
- Documentation: https://docs.ragleap.com/
Contributions, testing, security feedback, and technical discussions are welcome through the official repository.
Final thoughts
AI memory is becoming a foundational part of intelligent systems.
As AI employees take on more responsibilities, their memory infrastructure needs to be reliable, controlled, portable, and designed with security boundaries in mind.
With RagLeap Memory 0.3.1, we have added encrypted memory export and import, context binding, tamper detection, and extensive release verification.
We will continue developing RagLeap's memory infrastructure with a focus on security, reliability, and self-hosted control.
RagLeap — Open-source AI employees that ask before they act.
Top comments (0)