raven-zero-day-auto-prevent

name

raven-zero-day-auto-prevent

description

Automatically enforce defensive policy against an in-progress 0-day signal, end-to-end, with strict approval gating. Use when the user says "auto-prevent", "auto-block", "auto-quarantine", "policy-driven response", "stop this 0-day now without me clicking through", or asks Raven to execute the Defend plan automatically when criteria are met. Every automatic action terminates at a tool oracle (𝒯) with mandatory approval-gate verification, references a real D3FEND Isolate / Evict / Harden technique id, and emits a tamper-evident audit trail.

Raven — 0-Day Auto-Prevent

This skill is Raven's policy enforcer. It runs the same defensive plan as raven-zero-day-defend but with the human pre-authorizing classes of action by policy rather than each individual action. It is the highest-blast-radius skill in the 0-day suite, and the rules below are non-negotiable.

The skill MUST NOT bypass raven/approval/gate.py. "Auto" means the gate's smart mode is configured with policy-derived rules — it does NOT mean the gate is off.

When to use

Trigger when the user asks any of:

• "Auto-prevent this 0-day"
• "Auto-block / auto-quarantine on detection of <pattern>"
• "Run my response policy automatically"
• "Standing policy: isolate any host that matches <criteria>"
• "Apply the playbook without my approval for low-risk actions"

Do not trigger for: a single one-off incident (use raven-zero-day-defend), or for any user who has not explicitly written a policy. This skill refuses to fabricate a policy on the user's behalf.

Inputs

Required:

1. Policy reference — path to a Raven policy file OR an inline policy YAML block. Policies must be validated against the policy schema before execution.
2. Trigger source — one of: alert-stream (live from raven-zero-day-detection), single-alert (one alert id), signal (analyst-supplied indicator block)

Optional:

• Dry run — true to evaluate the policy and emit the plan without executing; default false
• Audit sink — file (default), kafka, siem-webhook

Policy schema (mandatory)

A policy is a YAML document with these top-level keys. The skill MUST reject any policy that fails schema validation.

policy_id: P-PROD-WEB-2026-01
owner: <email or team>
authorized_assets:
  - <fqdn or cidr or asset tag>     # at least one; "*" is rejected
trigger_predicate:
  any_of:
    - alert.severity: critical
    - alert.detector_hits[*].rule_id: raven.binary.suspicious_packer_v3
    - alert.d3fend_techniques: [D3-FA]
actions:
  - name: isolate_host
    d3fend_id: D3-NI
    module: raven.mitigation.containment_actions
    auto_approve_if:
      - asset_tag in [non-production, canary]
      - blast_radius_score < 0.3
    else: manual
  - name: rotate_credentials
    d3fend_id: D3-CH
    module: raven.mitigation.response_orchestrator
    auto_approve_if:
      - principal.type == service-account
    else: manual
  - name: deploy_decoy
    d3fend_id: D3-DF
    module: decoy.file
    auto_approve_if:
      - always
required_negative_constraints:
  - never_touch_assets: [<asset list>]
  - never_apply_to_principals: [<principal list>]
  - max_actions_per_minute: 10
  - max_actions_per_hour: 100

Schema notes:

• authorized_assets MUST list specific assets — wildcard * is rejected.
• Every action MUST have a d3fend_id and a module from Raven's defender-edition module list. Excluded modules (offensive.py, metasploit_integration.py, empire_client.py, exploitdb*.py) fail validation.
• auto_approve_if predicates are evaluated against the trigger context; if any predicate is unresolvable, the action falls to else: manual automatically.
• required_negative_constraints are hard caps; the skill MUST honor them even if auto_approve_if would otherwise authorize.

Pipeline — six mandatory stages

Stage 1 — Policy load and validate (𝒯-grounded)

1. Parse the policy with a JSON-schema validator. Reject on any schema failure.
2. Resolve every d3fend_id via raven.d3fend.api.lookup_technique — non-existent ids fail validation.
3. Confirm every module reference is in the defender-edition allowlist via raven.d3fend.coverage.allowed_modules.
4. Persist the policy hash to the audit log; future runs MUST log the same hash or fail-closed.

Stage 2 — Trigger evaluation (𝒯-grounded)

For each incoming signal (alert from raven-zero-day-detection, finding from raven-zero-day-investigator, or analyst-supplied indicator):

1. Evaluate trigger_predicate strictly — boolean evaluation only, no LLM interpretation.
2. If the predicate matches, emit a MatchedTrigger event with the signal hash and policy id.
3. If multiple actions match, retain order from the policy file — execution is deterministic.

Stage 3 — Action authorization (G4 + approval-gate)

For each candidate action:

1. Check required_negative_constraints first. If any constraint is violated, the action is rejected with reason=constraint_violation and dispatched to manual review.
2. Evaluate auto_approve_if predicates. If all resolve true, the action is marked smart_eligible.
3. The action ALWAYS routes through raven.mitigation.response_orchestrator.execute(...), which calls raven/approval/gate.py. Even smart_eligible actions go through the gate — the gate is the single enforcement point.
4. The gate's smart.py LLM is given the action context, policy snippet, and trigger evidence. It returns approve / deny / escalate.
5. UNRECOVERABLE_BLOCKLIST patterns in raven/approval/patterns.py are hard-rejected even when policy says auto-approve.

The skill MUST NOT call mitigation modules directly to bypass the gate. This is the most-tested invariant.

Stage 4 — Rate limiting

Enforce max_actions_per_minute and max_actions_per_hour using a Redis-backed sliding window. On rate-limit breach:

• Subsequent actions are dispatched to manual regardless of policy.
• Emit a raven_auto_prevent_rate_limit_breach_total Prometheus counter.
• Notify the policy owner via the configured channel.

Stage 5 — Execution & verification (𝒯-grounded)

After the gate approves, execute the action through the named module. After execution:

1. Capture the module's return value and any side-effect handle (process id, firewall rule id, decoy deployment id).
2. Verify the side effect with an independent tool-oracle call — e.g. if the action was isolate_host, query the firewall to confirm the rule is present.
3. If verification fails, immediately attempt a rollback via the restore/ subsystem and escalate to manual.

Stage 6 — Audit log emission

Every action — approved, denied, rate-limited, or rolled-back — appends one record to the audit log:

{
  "ts": "...",
  "policy_id": "...",
  "policy_sha": "...",
  "trigger_signal_hash": "...",
  "action_name": "...",
  "d3fend_id": "...",
  "module": "...",
  "approval_decision": "approve|deny|escalate",
  "approval_reason": "...",
  "executed": true|false,
  "verified": true|false,
  "rolled_back": true|false,
  "blast_radius_score": <float>,
  "operator_override": null,
  "cdp_grounding": {"T": true, "M": true|false, "L": false}
}

Audit log is append-only, hash-chained (each record contains prev_record_sha256). The skill MUST refuse to start if the chain on disk is broken.

CDP contract — quick check before each action

assert action.d3fend_id resolves through raven.d3fend.api.lookup_technique
assert action.module in defender-edition allowlist
assert approval gate returned a decision (not None)
assert at least one 𝒯 tool oracle invocation was made (this stage or upstream)
assert action satisfies required_negative_constraints

Any failed assertion aborts the action and emits an audit record with approval_decision="abort_cdp_violation".

Output contract

# Raven 0-Day Auto-Prevent — policy <policy_id>

## Run metadata
- Policy SHA: <sha>
- Trigger source: <alert-stream|single-alert|signal>
- Window: <start> → <end>
- Dry run: <true|false>

## Triggered actions (<count>)

### Action <action_name> on <target>
- D3FEND: <id>
- Module: <module>
- Approval: <approve|deny|escalate>
- Auto-approve predicates: <list>
- Executed: <yes|no>
- Verified: <yes|no>
- Rolled back: <yes|no>
- Blast radius: <score>
- Audit record: <id>

(repeat)

## Rate-limit events (<count>)
| ts | counter | breach |
|----|---------|--------|

## Constraint violations rejected (<count>)
| action | violation | dispatched_to_manual |
|--------|-----------|-----------------------|

## Audit chain integrity
- Records appended: <n>
- Chain valid: <yes|no>
- Last record SHA: <sha>

Refusal rules

1. Refuse to run without a validated policy. No default policy exists.
2. Refuse any policy with authorized_assets: ["*"].
3. Refuse any policy referencing excluded modules.
4. Refuse to start if the audit log chain on disk is broken.
5. Refuse to bypass raven/approval/gate.py under any flag, including --force.
6. Refuse to auto-execute any action without a verification step.
7. Refuse to silently downgrade manual decisions to smart — the gate's decision is final per-action.

Related skills

• raven-zero-day-detection — primary upstream producer of triggers.
• raven-zero-day-investigator — alternative upstream producer (investigation outcomes).
• raven-zero-day-defend — same action library, but always operator-in-the-loop.
• raven-zero-day-fixing — invoked when an action is apply_patch or rollback.
• restore/ subsystem — invoked for verified rollback on execution failure.
• D3FEND OWL integration (raven/d3fend/) — id resolution for every action (D3FEND home).