{% extends "base.html" %} {% block title %}Response — psyc{% endblock %} {% block content %} {% if fired %}
ENFORCED
action #{{ fired }} · {{ fired_kind }} pushed to the perimeter
{% for i in range(8) %}{% endfor %}
{% endif %}

Response Actions

{{ counts.proposed }} proposed · {{ counts.executed }} enforced · {{ counts.rejected }} declined{% if counts.failed %} · {{ counts.failed }} failed{% endif %}

When a high-severity case lands, psyc proposes what to do about it — alert the SOC, push its IOCs to the perimeter firewall + DNS. Nothing fires on its own: you approve, psyc enforces, the ledger records it. Detection that acts, with a human on the trigger.

how to use this view

How to use. Each proposed action is one defensive move. Hit ⚡ Enforce to fire it (and enjoy the disco), or Decline to drop it. Both decisions are logged to the immutable ledger.

What you're seeing. Actions generated by Respondline for HIGH/CRITICAL cases. The frozen payload is exactly what gets pushed to the enforcement sink on approval.

Why it matters. Closing the loop — intel → decision → enforcement → audit — is what separates a threat viewer from a threat response platform. The human gate keeps automation safe.

proposed ({{ counts.proposed }}) enforced ({{ counts.executed }}) declined ({{ counts.rejected }}) all
{% if not actions %}

No actions here. Propose some with psyc respond <case_id> on a HIGH/CRITICAL case, or run psyc demo.

{% else %} {% for a in actions %} {% endfor %}
#TypeCaseSevWhat it doesStatusAction
#{{ a.id }} {{ a.action_type.value }} {{ a.case_id }} {{ a.severity or '—' }} {{ a.summary }} {{ a.status.value }} {% if a.status.value == 'proposed' %}
{% else %} {{ a.approver or '—' }} {% endif %}
{% endif %}
{% endblock %}