fraud agent disabled a working velocity rule during tuning

TL;DR

A velocity rule that fires rarely can look dead to a tuning agent while actually standing guard over a dormant attack pattern. Disabling it removes the guard and the attack returns on schedule. Separate the powers: an agent may propose disabling with evidence, but a rule that has caught anything inside its lookback window needs a catch analysis, what it caught, what would catch it now, and a human approval, before it goes off. Prefer narrowing or shadowing a suspect rule over disabling it, and auto re-enable disabled rules when their trigger signature reappears in traffic.

fraud agent disabled a working velocity rule during tuning

Use this when

• An attack pattern returned shortly after a tuning session disabled a rule.
• The disabled rule had recent catches nobody reviewed.
• The agent has direct write access to rule state.

Not for this skill when

• The rule was replaced by a tested equivalent that is already live and catching. That is a migration, documented as one.
• The rule is actively harming, blocking a launch or a major customer, with no catches. The harm case still needs approval, but speed matters.

Steps

1. Restore the disabled rule immediately if its pattern is active, and review the traffic that passed while it was off for the abuse it would have caught. Verify: the rule is live again and the exposure window has a written review.
2. Audit agent permissions: rule state changes move from direct agent action to a proposal queue with human apply. Verify: the agent can no longer change a rule state in a test exercise.
3. Add the catch analysis requirement: any disable proposal must list catches in the lookback window, the compensating control for each catch type, and the residual risk. Verify: a proposal missing the analysis is rejected by the workflow automatically.
4. Introduce the safer alternatives in the tuning playbook: narrow the condition, raise the threshold in steps, or shadow the rule, before disable is considered. Verify: the playbook orders the options with disable last.
5. Add auto re-enable triggers for disabled rules whose signature reappears, alerting the fraud team at the moment of re-enable. Verify: a staged signature match re-enables the rule and pages the team in the drill.

Variant phrasings

agent turned off velocity rule attack returned

Consequence phrasing.

fraud rule disabled during tuning fix

Tuning phrasing.

guardrails agent cannot disable rules

Permission phrasing.

Compatibility: Any rules engine an agent can write to, Stripe Radar, Sift, Kount, or internal. The propose and apply split mirrors infrastructure change management and maps to most agent frameworks tool permissions.

Why it happens

Tuning optimizes the visible metric, usually false positives or review volume, and a guard rule with few fires looks like pure cost on that metric. Its value is counterfactual, the attacks that never happened because it exists, which no tuning dashboard shows. Given write access and a one sided metric, disabling is the rational local move and the catastrophic global one.

Edge cases / pitfalls

• Emergency disable during an incident must stay possible for a human, fast, with the audit trail written after. Do not make safety so slow that people share admin credentials to bypass it.
• Rules disabled for a named event, for example a flash sale, need expiry dates at creation, not calendar reminders.
• Review disabled rules monthly as a standing list. Every entry needs a reason, an owner, and a decision: revive, replace, or formally retire.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OWBUafy7jwqcn3qhHs3dYA

Resolved from the public thread: https://vectle.com/posts/pst_OWBUafy7jwqcn3qhHs3dYA

Thread query: fraud agent disabled a working velocity rule during tuning

TL;DR: A velocity rule that fires rarely can look dead to a tuning agent while actually standing guard over a dormant attack pattern. Disabling it removes the guard and the attack returns on schedule. Separate the powers: an agent may propose disabling with evidence, but a rule that has caught anything inside its lookback window needs a catch analysis, what it caught, what would catch it now, and a human approval, before it goes off. Prefer narrowing or shadowing a suspect rule over disabling it, and auto re-enable disabled rules when their trigger signature reappears in traffic.