Response Actions

When the Pavri threat-detection pipeline produces a verdict, it includes a recommended response action. Response actions determine what happens to the agent or session beyond generating a notification.

The five response actions

Action	Effect	Operator sees
Alert	Notify only. The agent continues executing normally.	Alert record in dashboard; webhook/Slack notification if a rule matches.
Block	The current tool call or model invocation is denied. The SDK raises a PolicyDeniedError.	Timeline event marked "Blocked" with the threat verdict attached.
Throttle	The agent's call rate is temporarily reduced. Subsequent calls within the throttle window are delayed or denied.	Timeline events marked "Throttled"; rate-limit metrics spike.
Terminate	The agent session is killed immediately. No further tool calls or model invocations are processed.	Session marked with outcome "Terminated"; final timeline event shows the termination reason.
Quarantine	The agent is disabled across all sessions. New sessions for the agent are rejected until an operator lifts the quarantine.	Agent status changes to "Blocked" in the inventory; all active sessions are terminated.

How each action works

Alert

The lightest response. The verdict is recorded and routed through the alert rule pipeline. The agent is unaware that a threat was detected. Use this for low-confidence detections or informational signals that need human review before enforcement.

Block

Reuses the same enforcement path as policy denials from Sprint 4. When the threat verdict specifies block:

1. The detection pipeline calls enforce_policy() with the threat context.
2. The SDK raises PolicyDeniedError with the matched detector name and threat type as the denial reason.
3. The framework plugin converts this into a framework-native error (LangGraph exception, CrewAI hook return, OpenAI Agents guardrail trigger, etc.).
4. The agent receives a structured error it can handle -- retry with a different approach, fall back, or terminate gracefully.

The blocked action is recorded as both a policy_eval telemetry event and a threat-detection alert.

Throttle

When the verdict specifies throttle:

1. The detection pipeline adjusts the agent's rate-limit parameters for the current session.
2. Subsequent tool calls are subject to the tighter limit.
3. If the agent exceeds the throttled rate, calls are denied with PolicyDeniedError and action throttle.

Throttling is session-scoped by default. The original rate-limit policy parameters are restored when the session ends or when the throttle window expires.

Terminate

When the verdict specifies terminate:

1. The detection pipeline sends a termination signal to the session.
2. The SDK stops processing any queued tool calls or model invocations.
3. A final agent_lifecycle event with kind STOPPED and the threat verdict summary is emitted.
4. The session is marked with outcome Terminated in the session store.

Termination is immediate and non-recoverable for the session. The agent itself remains registered and can start new sessions.

Quarantine

The most severe response. When the verdict specifies quarantine:

1. All active sessions for the agent are terminated (same flow as terminate above).
2. The agent's status is set to Blocked in the agent registry.
3. New session creation for the agent is rejected until an operator removes the quarantine.
4. An agent_lifecycle event with kind ERROR and the quarantine reason is emitted.

Quarantine requires manual operator intervention to lift. This is intentional -- quarantine is reserved for high-confidence, high-severity threats where continued agent operation poses unacceptable risk.

Incident war rooms can also execute incident-scoped bulk quarantine for affected agents. That path uses the same bulk-action machinery as agent groups, requires an admin role, persists containment events on the incident timeline, and appends audit records. Analysts can create and update incidents, add notes, and draft communications, but cannot execute destructive containment.

How response actions map from threat verdicts

The recommended action in a verdict is determined by the detector that produced it, combined with the severity:

Severity	Typical action	Escalation path
Low	Alert	Operator reviews at next triage cycle
Medium	Alert or Throttle	Operator reviews; may escalate to block
High	Block or Terminate	Immediate investigation; policy tightening
Critical	Terminate or Quarantine	Immediate response; agent isolation

These mappings are defaults. Operators can override the action for specific threat types by configuring policies with explicit enforcement rules.

Recording actions alongside notifications

When the alert service processes a threat verdict:

1. The response action is executed first (block, throttle, terminate, or quarantine).
2. The alert rule pipeline evaluates the verdict and dispatches notifications.
3. The AlertRecord written to storage includes both the action that was taken and the delivery status of each notification channel.

This means the alert an operator receives always reflects the action that has already been applied. The operator does not need to take the action manually -- they review it.

Response actions in session investigation

When an operator follows a deep link from an alert to the session timeline:

• The triggering event is highlighted with a governance badge matching the action (Blocked, Throttled, Terminated, Quarantined).
• The event detail panel shows the full threat verdict: detector name, confidence, threat type, severity, and the action taken.
• For block and throttle actions, the subsequent timeline events show the agent's recovery behavior (retry, fallback, or graceful stop).
• For terminate and quarantine actions, the timeline ends with the termination event and a summary of why the session was killed.

Connection to Sprint 4 enforcement

Response actions build on the enforcement infrastructure from Sprint 4:

• enforce_policy() is the shared entry point for both policy denials and threat-response blocks/throttles.
• PolicyDeniedError is raised for both policy violations and threat-based blocks, with the source field distinguishing "policy" from "threat_detection".
• Prometheus metrics (pavri_policy_denials_total, pavri_policy_evaluations_total) count threat-based enforcement alongside policy-based enforcement, tagged with source=threat_detection.
• The dashboard timeline uses the same governance badge system for policy outcomes and threat responses.

Current constraints

• No action override API -- operators cannot change the action after a verdict is issued. Adjusting future behavior requires policy or rule changes.
• Throttle window is fixed -- the throttle duration is set by the detector and cannot be adjusted per-rule. Configurable throttle windows are planned for Phase 2.