Database-first security
Govern memory, retrieval, and tools at the source of truth.
MaluDB treats AI security as a database systems problem: roles, schemas, privileges, Row Level Security, compartments, audit trails, and rebuildable derivations.
- Identity
- Users, services, agents, tools
- Boundary
- Compartment-level retrieval and row policies
- Audit
- Prompt, model, source, tool, and memory events
Compartmentalized memory
Sensitive context can be separated by tenant, product, department, incident, account, project, or regulatory boundary.
Retrieval with policy checks
Search plans apply identity and compartment rules before context is assembled for an application, model, or MCP tool.
Provenance and audit
Memory changes can point back to source packages, extraction jobs, validation decisions, model calls, and human reviewers.
Operational resilience
Preserved sources and derivation records make it possible to rebuild memory indexes after policy, schema, or model changes.
Controls
Security surfaces to document before launch.
This scaffold leaves room for a formal security page with compliance posture, incident response, vulnerability reporting, and deployment architecture.
| Area | Control | Website message |
|---|---|---|
| Access | PostgreSQL roles, privileges, and RLS | Policies stay close to data and memory. |
| AI usage | Prompt, context, model, and tool permissions | Agents can only see and do what the DB allows. |
| Traceability | Source links and derivation ledger | Teams can explain how memory was created. |
| Isolation | Compartments and deployment boundaries | Memory is separated by organizational need. |