Built In, Not Bolted On
The phrase "security-first" gets used in marketing copy so often it has nearly lost meaning. Let us be specific about what we mean when we say security is built in to the Sovereignty Protocol.
Every action taken on the platform — every login, every tool call, every memory write, every vault read — generates an immutable audit log entry that cannot be edited or deleted. Not by users. Not by admins. Not by the platform itself. The audit log is append-only by design, enforced at the database layer.
That is not a feature. That is an architectural commitment.
The Immutable Audit Log
Every audit entry captures:
- Action type — what operation was performed (login, tool_call, memory_write, vault_read, etc.)
- Resource path — which record or endpoint was affected
- HTTP method — GET, POST, DELETE, etc.
- IP address — the origin of the request
- User agent — the client that made the request
- Response status — whether it succeeded, failed, or was blocked
- Duration — how long the operation took in milliseconds
- User ID — who performed the action
This gives you complete forensic context for every event. If something unexpected happens — an agent calls a tool it should not have, a user accesses a record outside their scope, a vault read happens at an unusual hour — the audit log tells you exactly what happened and when.
The log is accessible to administrators through the Security Overview dashboard. Regular users can view their own audit history. Nobody can modify or delete entries — the append-only constraint is not a setting, it is the schema.
The Secrets Scanner
Before any piece of text is stored in the Smart Memory System, it passes through a 15-pattern secrets scanner.
The scanner checks for:
- API keys (OpenAI, Anthropic, AWS, Google Cloud, and a dozen more)
- Bearer tokens and authorization headers
- PEM certificates and private keys
- JWT tokens
- Database connection strings with credentials
- Generic high-entropy strings that match credential patterns
If a match is detected, the memory write is blocked. The user is redirected to the Vault and shown an explanation of what was detected and why it was not stored. The raw secret is never persisted to the database.
This protects against the most common way credentials end up in the wrong place: someone pastes a config file into a chat window without thinking. The scanner catches it before it lands in a database that might be exported, backed up, or accessed by another agent.
AES-256-GCM Vault Encryption
The Sentinel Vault stores user secrets — API keys, passwords, configuration values, personal data — encrypted at rest using AES-256-GCM.
The encryption key is derived from the user's master key, secured with bcrypt. The plaintext of any secret never leaves the server unencrypted. When the vault returns a secret to an agent via MCP, it decrypts in memory and passes the value directly to the requesting tool — it is never written to a log, a file, or a database field in plaintext form.
The vault has two modes:
- Personal Vault — user-only access, for storing sensitive credentials you do not want agents to touch autonomously
- Nexus MCP Vault — AI-accessible secrets with explicit user control; agents can read from this vault using the
read_secretMCP tool when the vault is unsealed
Automatic Sealing
The MCP Vault seals automatically after a configurable inactivity period. When sealed, no agent — regardless of permissions — can read vault contents. The user must explicitly unseal to grant access again.
This reduces the window of exposure for any compromised agent session. Even if an agent is behaving unexpectedly, it cannot access vault contents if the vault has sealed since the last user interaction.
Session Management
Every login creates a tracked session record. This is not a background accounting entry — it is a first-class object you can view and act on.
For each session, the platform tracks:
- Device hint — the browser and operating system
- IP address — where the login originated
- Creation timestamp — when the session was established
- Last seen timestamp — the most recent activity on this session
All active sessions are visible in the Account → Two-Factor Auth & Sessions dashboard. You can revoke any individual session with a single click. If you see a session you do not recognise — wrong IP, wrong device, wrong time — you revoke it immediately and the access is cut.
Memory Privacy Scoping
The Smart Memory System stores memories under user-scoped paths: users/{id}/memory/. This is enforced at both the filesystem level and the PocketBase sync layer.
A memory belonging to user A cannot be read by user B, even if user B has administrative access to the platform. The scoping is not a permission check — it is a path constraint. There is no query that crosses user boundaries because the data is physically separated.
This matters for multi-tenant deployments, shared enterprise instances, and any scenario where multiple users interact with the same platform installation.
What Zero-Trust Means Here
Zero-trust in the context of the Sovereignty Protocol means: no component of the system is trusted by default, including agents.
Agents do not have implicit access to vaults. They must request access through the MCP tool layer, the vault must be unsealed, and the access is logged. Agents do not have implicit access to other users' memories. Agents cannot modify audit logs. Agents that are misbehaving — as detected by self-assessment loops — can be paused pending human review.
The security model treats the AI layer with the same scepticism it treats every other component. That is not a limitation on what AI can do in the system. It is what makes it safe to let AI do more.
Forensic Context at Every Layer
The combination of:
- Immutable audit logs at the action level
- Secrets scanning at the memory write level
- Vault encryption at the storage level
- Session tracking at the authentication level
- Memory scoping at the filesystem level
...means that every interaction in the Sovereignty Protocol is traceable, auditable, and bounded.
If something goes wrong, you can find out exactly what happened. If something was done that should not have been, you can see who did it, from where, and when. And because the audit log is append-only, you can trust that the record has not been altered after the fact.
That is what zero-trust AI governance actually looks like in practice.