Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Protection Network

The Protection Network is the five-layer cross-tenant defensive model Mnemom AEGIS adds on top of Safe House. Per-customer Safe Houses detect on what they can see — one tenant’s traffic, one tenant’s agents. The Protection Network aggregates the cross-tenant signal, signs the resulting Managed Rules, and propagates them back to every gateway in the network. The layers stack from per-evaluation identity to public transparency:
LayerFunctionSurface
L0 — Axis identityStamp every evaluation with (substrate, vertical, pattern, source)Internal, on every row
L1 — Cross-tenant aggregatorRoll up rolling stats per axis-bucketInternal; customer-readable view via /v1/network/threat-state
L2 — Under-attack overlayComposition-layer auto-elevation during active campaignsPer-org toggle + dashboard
L3 — Managed Rules pushSign + propagate cross-tenant detection contentGateway evaluates at the four checkpoints
L4 — Threat thermometerPer-axis state surfaced to the customer/dashboard/threats
L5 — IoC feed + advisoriesPublic transparency surface/v1/trust/iocs + /trust/advisories
All five layers ship with the mechanism wired at GA. Where any layer’s content is partial (no campaigns active; the IoC feed empty), the surface displays the partial state honestly — see the calm-at-GA contract.

​
L0 — Axis identity

Every evaluation, checkpoint, and trace row that flows through Safe House is stamped server-side with four axis-identity fingerprints:
  • substrate_id — the AI substrate the agent ran on (<provider>:<model> at minimum; see Substrate fingerprint for the full composition).
  • vertical_id — the customer industry vertical the agent serves (enum).
  • pattern_fingerprint — the canonicalized hash of the detection pattern that matched (or the empty pattern, for unflagged evaluations).
  • source_fingerprint — the canonicalized hash of the request source identity (channel + principal class + region).
The stamping is pure derivation from row context — there is no customer-side opt-in for the substrate, vertical, pattern, or source fields. L0 is backfilled across the three observation tables (integrity_checkpoints, arena_attempts, sideband_analyses) so every historical row carries axis identity as well. L0 is the foundation of every upstream layer: the aggregator (L1) buckets by axis; the under-attack overlay (L2) elevates per-axis; the Managed Rules push (L3) targets per-axis. Without L0, none of the cross-tenant primitives have a substrate to operate on.

​
L1 — Cross-tenant aggregator

L1 maintains rolling stats per axis-bucket. For each (axis, bucket, window) triple — substrate × 24h, vertical × 1h, pattern × 6h, etc. — the aggregator counts detection events, computes baseline rate, and triggers state transitions when the rolling delta crosses thresholds. The wire format readable by customers is GET /v1/network/threat-state. The endpoint returns per-axis arrays of { bucket, threat_level, updated_at } objects; the threat_level enum is calm | elevated | high | under_attack. The aggregator’s internal table schema is not part of the public surface; what is on the wire is documented in Threat state response schema.

​
L2 — Under-attack overlay

L2 is a composition-layer auto-elevation. When an axis-bucket transitions to high or under_attack, AEGIS inserts an under-attack overlay layer between Platform and Org in the card cascade — present only during the campaign, removed when the bucket falls back to calm. The overlay tightens detection thresholds and surfaces the elevation to the affected customers.

​
Under-attack ceiling — additive ratcheting, not override

L2 honors a customer-configured elevation ceiling. The platform may auto-ratchet protection up to the ceiling; it does not override the customer’s hard configured maximum. This matches the Cloudflare “I’m Under Attack” pattern: 
effective_mode = max(normal_posture, min(threat_level_suggested, elevation_ceiling))
Two posture knobs per org:
  1. Normal posture — enforcement_mode during calm conditions (off / observe / nudge / enforce).
  2. Elevation ceiling — maximum AEGIS may auto-ratchet to during a campaign. Default enforce (full headroom); customers may clamp lower.

​
Three honest customer scenarios

Customer configThreat levelCustomer sees
Ceiling = enforce, normal = nudgehigh”AEGIS elevated your agents to enforce because of active campaign X. Revert here.”
Ceiling = nudge, normal = nudgeunder_attack”AEGIS detected a critical campaign affecting your substrate. You have clamped your maximum at nudge; we recommend raising your ceiling for the duration of this campaign. [Raise temporarily]“
Ceiling = enforce, normal = enforceunder_attack”You are at your maximum configured posture and at the highest threat level. No further elevation possible. Additional protections active: canaries planted, credential issuance frozen, AIP proof rate = 100%.”
The third scenario surfaces a key insight: the under-attack overlay is not just enforcement_mode ratcheting — it is a whole overlay layer of “what under_attack means.” Most of the integrity-side primitives (canaries planted, credential issuance frozen, full AIP proofs) kick in regardless of customer ceiling because they are not posture changes; they are integrity-side primitives the customer cannot toggle.
Honest GA disclosure. The L2 mechanism is wired at GA — the bucket transitions fire, the toggle UI is live, the audit log records every elevation. The composition-layer auto-elevation ships in Phase 4 (depends on the card composition primitive); manual operator override on the org flag covers the interim. Un-defer trigger: Phase 4 production cutover (2026-05-29).

​
L3 — Managed Rules push

L3 is the cross-tenant rule plane. A candidate enters the review queue with a writer_identity stamped by its auth context (arena-bypass, customer-fn-report, researcher-submission, internal-observation, or manual-admin). After review, the candidate is signed with RECIPE_PROMOTION_SIGNING_KEY and propagated to every gateway via two parallel signed envelopes:
  1. KV envelope — signed with RECIPE_KV_SIGNING_KEY; the gateway’s primary read tier.
  2. R2 envelope — signed with RECIPE_R2_SIGNING_KEY (an independent signing chain from KV); the gateway’s secondary read tier for failover.
Promotion target: P95 ≤ 30s propagation latency from approve-action to gateway-active. See /trust/slos for the published commitments and Managed rule envelope schema for the wire format.

​
The protective invariant

A tier-1 or tier-2 Managed Rule — one that would block real production traffic — can never auto-promote without a human in the loop, regardless of how aggressive the platform’s reviewer-mode setting is. The invariant is enforced structurally by a schema CHECK constraint (promotion_quorum_met = TRUE required when status = 'active'), not procedurally. See Managed Rules for the three reviewer modes and the tier breakdown.

​
24-hour observe soak

Newly-promoted rules enter observe mode for 24 hours before any mode escalation. The aggregator computes the per-recipe false-positive rate during the soak; rules above the FP threshold auto-rollback under CLPI Phase 2 trust recovery. Only rules that survive the soak escalate to their target mode.

​
L4 — Threat thermometer

L4 is the customer-facing read of L1. The /dashboard/threats page displays per-axis state pulled live from the aggregator — calm, elevated, high, or under_attack per axis-bucket — plus a 30-day trend line per axis. At GA, if all axes are calm, the thermometer shows calm. There is no fabricated activity to make the page look busy; the page reflects actual operational state per the calm-at-GA contract.

​
L5 — IoC feed + advisories

L5 is the public transparency surface. Two endpoints:
  • /v1/trust/iocs — STIX 2.1 bundle of Indicators of Compromise AEGIS has published to the network. See IoCs and the wire-format spec at IoC STIX mapping.
  • /trust/advisories — published per-incident summaries. See Advisories.
At GA both surfaces are honest about the calm state. The IoC bundle is { "type": "bundle", "objects": [] } — empty by design. The advisories page lists the synthetic seed post-mortem with synthetic: true. When AEGIS publishes a real advisory it will carry synthetic: false; the field is reliable.

​
How a signal becomes a Managed Rule

The end-to-end flow from raw signal to gateway-active enforcement: 
1.  Signal arrives
    arena bypass / customer FN report / sideband cross-tenant aggregator hit
                  │
                  ▼
2.  Candidate inserted with writer_identity stamp
                  │
                  ▼
3.  Review queue
    manual / auto-approve-trusted-sources / auto-approve-high-confidence
    (tier 1-2 always requires dual-control human approval)
                  │
                  ▼
4.  Signed promotion (Ed25519, per-row promotion_signature)
                  │
                  ▼
5.  KV + R2 envelope dual-write
    (independent signing chains; P95 ≤ 30s propagation)
                  │
                  ▼
6.  Gateway evaluates at the four checkpoints
    initial mode: observe (24h soak)
                  │
                  ▼
7.  Escalation to target mode (or auto-rollback on FP threshold)
See Managed Rules for the pipeline in detail, including the three reviewer modes and the writer-identity taxonomy.

​
See also