Skip to main content
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 (Platform → Org → Team → Agent). 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: 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 for the wire format.

​
Webhook events

Only one event in the rule lifecycle is delivered to your org’s own webhook subscription today: 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. See Webhooks for subscription setup and 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:
The report lands in the same review queue as every other candidate, with the customer recorded as its creator — never its approver.

​
See also