Skip to main content
Mnemom AEGIS — Adaptive Enforcement, Governance & Intelligence Substrate — is the runtime screening layer of Safe House. Every model call routed through the Mnemom gateway is checked at four checkpoints (front door, inside.autonomy, inside.integrity, back door). For each agent you choose, per setting, whether a check is off, only records (observe), warns (nudge), or steps in (enforce). Detection content reaches the gateways as Managed Rules: an Ed25519-signed rule set that each gateway verifies before it uses it, and picks up within minutes of a change.

​
The four checkpoints

A checkpoint is a position in the request lifecycle, not a per-turn budget. The front door fires once per inbound surface: a request that hands three tool results back to the model passes the front door for the message and again for each of those results. See When the front door runs.

​
Three settings per agent

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. See Card Composition.

​
Four enforcement modes

Every gateway response carries the outcome of each checkpoint in the X-Mnemom-Verdict header, for example front=pass; autonomy=pass; integrity=pass; back=pass. See Headers.

​
How detection rules are kept current

  • Signed delivery. Managed 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.
  • Review before production. New rules are reviewed before they reach production. See Managed Rules.
  • Continuous testing. Screening is tested continuously by an automated, adaptive attacker that runs against sandbox agents in an isolated environment, never against customer agents.
  • Customer reports. You can report a missed attack or a false block against a rule. Reports go into the review queue.
Every candidate rule carries a writer_identity recording where it came from (a customer’s own false-negative or false-positive report, an internal observation, a security-researcher submission, or a platform-admin entry). It is stamped server-side from the auth context used at write time; a customer can file a report but never sets the writer identity itself.

​
Limits

  1. Not a trust protocol. AAP declares an agent’s identity and alignment, AIP verifies reasoning in flight, CLPI governs the card lifecycle, and AEGIS screens traffic at the gateway. None of these layers substitutes for the others.
  2. Detection confidence varies by threat class. A low-confidence rule in observe is not the same claim as a reviewed rule in enforce.
  3. Only traffic through the gateway is screened. Direct provider calls that bypass the gateway are not seen.
  4. No supply-chain detection. The substrate fingerprint records which provider, model, SDK and (optionally) lockfile produced each checkpoint, as evidence for your own audits. AEGIS does not detect compromised dependencies; use package-level provenance for that. See Supply-chain trust.

​
See also