> ## 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.

# Managed Rules

> Detection rules AEGIS delivers to every gateway as an Ed25519-signed rule set. Each gateway verifies the signature before it uses the rules and picks up changes within minutes. New rules are reviewed before they reach production.

A **Managed Rule** is the control-plane state that wraps a detection recipe. Recipes are detection content; rules are the control-plane state; both compose through the same machinery as [agent cards](/concepts/agent-cards) (Platform → Org → Team → Agent). [AEGIS](/concepts/aegis) delivers the active rules to every gateway as one signed rule set.

## Where candidates come from

A candidate rule enters a review queue before it can become a Managed Rule. Every candidate row is stamped server-side with a `writer_identity` recording where it came from and under which auth context — a customer's own false-negative or false-positive report, an internal observation, a security-researcher submission, or a platform-admin entry. The customer never sets the writer identity; it is the server-side stamp review uses to decide what a candidate is eligible for.

Screening is also tested continuously by an automated, adaptive attacker that runs against sandbox agents in an isolated environment, never against customer agents.

## Review

New rules are reviewed before they reach production. The reviewer mode is set platform-wide:

| Mode | Low blast radius (`observe` / `nudge`) | Would block production traffic |
| - | - | - |
| **`manual`** (default) | A platform admin reviews and promotes | Approval from a second reviewer who did not create the rule is required before promotion |
| **`auto-approve-trusted-sources`** | May auto-promote when the source is a trusted internal signal and pattern complexity is below threshold | Same as `manual` |
| **`auto-approve-high-confidence`** | May auto-promote when a confidence score clears threshold | Same as `manual` |

The reviewer mode only affects rules whose blast radius is bounded. Rules that would block production traffic always go through human review. Each review step is recorded in a table that rejects edits and deletes.

## Signed delivery

Promotion writes the active rule set to two independent storage tiers, each signed with its own Ed25519 key. The gateway verifies the signature on every read:

* A rule set whose signature does not verify against the primary tier's key falls through to the secondary tier.
* A secondary-tier rule set that does not verify falls through to the gateway's last-known-good in-process copy.

Gateways pick up a changed rule set within minutes. See [Managed rule envelope schema](/specifications/managed-rule-envelope-schema) for the wire format.

## Webhook events

Only one event in the rule lifecycle is delivered to your org's own webhook subscription today:

| Event | When | Notable fields |
| - | - | - |
| [`recipe.candidate.created`](/api-reference/webhook-events#recipecandidatecreated) | Your org submits a false-positive/false-negative report on a recipe (see below) | `candidate_id`, `writer_identity`, `report_type`, `related_recipe_id` |

The rest of the lifecycle (`recipe.promoted`, `recipe.retired`) is internal Mnemom operations signals, not customer-subscribable webhooks; see the note on [Webhook Event Catalog](/api-reference/webhook-events#detection-reports). See [Webhooks](/guides/webhooks) for subscription setup and [Webhook contract](/concepts/webhook-contract) for the canonical payload shape.

## Reporting a false positive or false negative

Customers report a recipe misfire (false positive) or a miss (false negative) against a specific detection recipe:

```bash theme={null}
curl -X POST https://api.mnemom.ai/v1/recipes/{recipe_id}/report \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "fp",
    "summary": "Flagged a routine internal API call as data_exfiltration"
  }'
```

The report lands in the same review queue as every other candidate, with the customer recorded as its creator — never its approver.

## See also

* [AEGIS](/concepts/aegis) — runtime screening at four checkpoints
* [Managed rule envelope schema](/specifications/managed-rule-envelope-schema) — the wire format of the signed rule set
* [Protection Card](/concepts/protection-card) — the per-agent configuration Managed Rules apply under
* [Card Composition](/concepts/card-composition) — the scope cascade Managed Rules compose into


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.