Core Concepts
Boundaries
Access control in Memax. Every memory has a boundary that determines who can see it.
A boundary determines who can access a memory. Memax is private by default — you must explicitly opt in to sharing.
Boundary levels
| Boundary | Who can see it | Use case |
|---|---|---|
private | Only you | Personal notes, drafts, sensitive info |
team | All hub members | Architecture docs, runbooks, decisions |
public | Anyone with the link | Open-source docs, public references |
How boundaries are enforced
Boundaries are enforced at the data layer, not the application layer. Every database query filters by owner_id and boundary permissions. This means:
- A bug in application code cannot leak private memories
- Cross-user access is impossible even with a compromised API endpoint
- Team boundaries are checked against hub membership
Boundary enforcement is critical security infrastructure. Every memory access verifies the requester's access level against the memory's boundary and hub membership.
Setting boundaries
At push time
# Private (default)
memax push -f ./notes.md
# Team
memax push -f ./runbook.md --boundary team
# Public
memax push -f ./readme.md --boundary publicAfter the fact
# Change an existing memory's boundary
memax edit mem_a1b2c3d4 --boundary teamBoundary in retrieval
When an agent calls memax_recall:
- Personal memories — always included (if the user owns them)
- Team memories — included if the user is a member of the hub
- Public memories — included based on relevance
Boundaries filter before ranking. An irrelevant team memory won't crowd out a highly relevant private one.