Security
How Mnemom is secured.
AEGIS screens your agents' model calls as they run. Below that are the controls that protect the platform itself. Security questionnaires and control evidence are available under NDA.
AEGIS runtime screening
Every model call is checked at four points.
Model calls routed through the Mnemom gateway are checked on the way in, at tool use, in the agent's reasoning and on the way out. For each agent you choose whether a check only records, warns or steps in.
- 1
front door
The newest user message and any tool results, before they reach the model.
- 2
inside.autonomy
The tools offered to the model, and the tool calls it makes.
- 3
inside.integrity
The agent's reasoning, reviewed by our integrity check (AIP).
- 4
back door
The response, before it is returned to your application.
What we screen for
| Threat | Checked at | How |
|---|---|---|
| Prompt injectionfront door | Pattern rules, then a model-based judge. Text is normalized first, so look-alike and hidden characters do not slip past. | |
| Hidden instructions in tool resultsfront door | The same checks on tool results, such as a fetched page or document. In enforce mode a flagged result is replaced before the model sees it. | |
| Forbidden tools and protected operationsinside.autonomy | Tools are checked against the agent's Alignment Card. Tool calls are checked against the assets and operations your organization marks as protected, such as dropping a table. | |
| Sensitive data in responsesback door | Card numbers, SSNs, API keys, private keys, access tokens, connection strings, emails, phone numbers and IP addresses. Redacted on non-streaming responses, recorded on streamed ones. | |
| Payment fraud and impersonationfront door | Flags a changed payee or bank account combined with urgency, secrecy or pressure to skip approval. | |
| False claims of authorityfront door | Flags messages that claim to come from a system, an administrator or Mnemom. | |
| Unsafe reasoninginside.integrity | A model reviews the agent's reasoning for prompt injection, value misalignment, autonomy violations, deceptive reasoning and undeclared intent. |
Three settings per agent
- Safe House covers the front door, tool calls and the back door. Each of those can be switched on or off.
- Autonomy covers tool use against the Alignment Card.
- Integrity covers the agent's reasoning.
Settings apply at the platform, organization, team and agent level, and the strictest one wins. A lower level can add protection but cannot remove or weaken one set above it. Organization admins set the organization, team and agent levels.
Four modes for each setting
| Mode | What happens |
|---|---|
| off | The check does not run. |
| observe | The check runs and the result is recorded. The request and response are unchanged. |
| nudge | The request goes through with a warning the model and your application can see. Sensitive data in outgoing responses is redacted. |
| enforce | Flagged content does not go through. An unsafe message is replaced with a quarantine notice, a forbidden tool turn or failed integrity check is replaced with a refusal, and sensitive data is redacted. |
The result is on every response
Every gateway response carries the outcome of each checkpoint in a header. Each integrity checkpoint is also signed and chained, as described under Signed record below.
x-mnemom-verdict: front=pass; autonomy=pass; integrity=pass; back=passHow the rules are kept current
- Detection rules reach every gateway as an Ed25519-signed rule set. Each gateway checks the signature before it uses the rules, and picks up changes within minutes.
- We test the screening continuously with an automated, adaptive attacker that runs against sandbox agents in an isolated environment, never against customer agents.
- New rules are reviewed before they reach production.
OWASP Top 10 for Agentic Applications
Where we cover the agentic risks, and where we don't.
| Risk | Coverage | What Mnemom does |
|---|---|---|
| ASI01 Agent goal hijackPartial | Incoming messages and tool results are screened for direct and indirect injection, and risk is tracked across the turns of a session. | |
| ASI02 Tool misusePartial | Tools the card forbids can be refused, and calls that target protected assets or operations can be withheld. Not every unsafe tool call is caught. | |
| ASI03 Identity and privilege abusePartial | Tool permissions come from the agent's card, and incoming claims of system or admin authority are flagged. | |
| ASI04 Supply chainNot covered | We record the provider, model and SDK version behind each checked request, plus an optional lockfile hash. We do not detect compromised dependencies. | |
| ASI05 Unexpected code executionNot covered | Run generated code in a sandbox in your application. | |
| ASI06 Memory and context poisoningLimited | Poisoned content that comes back as a tool result is screened. We do not integrate with memory stores. | |
| ASI07 Insecure inter-agent communicationPartial | Messages from other agents are screened like any other input, and false claims of authority are flagged. Messages between agents are not authenticated. | |
| ASI08 Cascading failuresNot covered | Handle this in your application's architecture. | |
| ASI09 Human-agent trust exploitationCovered | Urgency, authority, secrecy and payment-change pressure in incoming messages are flagged. | |
| ASI10 Rogue agentsPartial | Behavior is checked against the agent's Alignment Card. Admins can pause or stop an agent, and automatic pausing on repeated violations can be turned on. |
Source: OWASP GenAI Security Project, genai.owasp.org.
NIST AI Risk Management Framework
Controls and records for each function.
The AI RMF is a voluntary framework your organization runs. It is not a certification. Mnemom provides runtime controls and records each function can use.
| Function | What Mnemom provides |
|---|---|
| Govern | A machine-readable policy per agent (the Alignment Card), settings at the organization, team and agent level, and a log of who changed what. |
| Map | Each agent's declared purpose and limits, and the OWASP mapping above. |
| Measure | A result at every checkpoint on every turn, and signed integrity checkpoints you can verify. |
| Manage | Observe, nudge and enforce modes, and pause and stop controls for every agent. |
Platform
How we protect the platform.
Signed record
- Each integrity checkpoint is signed with Ed25519 and linked into a SHA-256 hash chain within its agent session, so a removed or reordered checkpoint is detectable.
- Each checkpoint certificate includes a Merkle inclusion proof. Anyone can check a certificate against our public verify endpoint, or check its signature with any standard Ed25519 library.
- Our signing public key is published at api.mnemom.ai/v1/keys.
- Agent card attestations are recorded in a public, append-only log modelled on Certificate Transparency (RFC 6962). Its signed root and consistency proofs are public.
- Webhooks are signed with HMAC-SHA256 over a timestamp and the body.
- Signing keys are held in Azure Key Vault and loaded into our services through managed identity.
Infrastructure
- Each environment runs as a self-contained cell with its own network, database, cache, key vault, storage and identity service. Cells do not share networks.
- Databases, cache, key vault and storage have public internet access turned off and are reached only over private endpoints.
- All public traffic reaches us through Cloudflare. Production origins accept connections only from Cloudflare.
- Internal services have no public endpoint.
- The production database keeps a standby in a second availability zone. Backups are kept for 30 days and copied to a second region.
Encryption
- Public endpoints accept only TLS 1.2 and TLS 1.3. Databases, cache and storage accept only encrypted connections.
- All customer data is encrypted at rest.
- Webhook signing secrets and stored model-provider keys are also encrypted by our application with AES-256-GCM.
Access
- Organizations have five roles: owner, admin, member, viewer and auditor. The API checks the caller's membership and role on every organization request.
- Changes made through the API are logged with who made them. Owners, admins and auditors can read their organization's log.
Sign-in
- You always sign in on a Mnemom page. The identity service runs inside each cell, and its own login and admin pages are not reachable from the internet.
- Passkeys (we store only the public key) and authenticator-app MFA. Turning MFA off, removing a passkey or signing out other sessions needs a fresh second-factor check.
- Browser sessions use an encrypted, HttpOnly, Secure cookie that expires after 7 days of inactivity and 30 days at most. We email you when your account signs in on a new device.
- API keys are shown once and stored only as a SHA-256 hash. Keys are scoped, and you can revoke or rotate them at any time.
- CLI and agent sign-in uses OAuth with PKCE or the device-code flow.
How we ship
- Production changes go through a single deployment pipeline. A release reaches production only after a named engineer approves it, or after an automated canary passes for changes classified as low-risk.
- Main branches require automated checks, including secret scanning.
- Our GitHub organization requires two-factor authentication. Access to production cloud resources is limited to a few named people and scoped automation identities. Internal tools sit behind Cloudflare Access.
Compliance
Compliance-ready for SOC 2 Type II, GDPR and HIPAA. Third-party audit in progress. Security questionnaires and control evidence are available under NDA.
EU AI Act: Articles 10, 12 and Annex IV mapped to the signed record. A technical mapping, not a certification.
See the Trust pageReport a vulnerability
Email [email protected]. Our disclosure policy is in our security.txt and on the Trust page.
[email protected]Move fast. Stay standing.
Know what your agents are actually doing, before the board asks.
Two commands to install. A signed record from the first decision onward.
