Cyber Riposte: When Your Security Team Wants to Code-Review the Firewall

Hook

What if every time your intrusion detection system spotted an attack, instead of blocking it immediately, it opened a pull request?

Context

Modern security automation lives in two extremes. On one side, you have SOAR platforms that execute defensive actions instantly—detect a brute force attempt, push an iptables rule, done in milliseconds. On the other, you have security teams that manually write firewall configs, review them in change advisory boards, and deploy during maintenance windows weeks later.

Cyber Riposte explores a middle path that's either brilliant or catastrophically naive, depending on your threat model. The core premise: treat an AI agent not as an autonomous defender that executes commands, but as a junior engineer that proposes infrastructure changes through your existing GitOps pipeline. Instead of directly calling cloud APIs to modify security groups, the agent generates a Terraform file, commits it to a branch, and opens a pull request. Instead of pushing iptables rules to hosts, it creates an Ansible playbook for review. The defensive action doesn't happen until a human merges the PR and your CI/CD pipeline deploys it—deliberately inserting human judgment and version control into the incident response loop.

Technical Insight

The architecture inverts conventional security automation by treating the AI as a policy proposer rather than an executor. In a traditional setup, telemetry flows from your environment into a detection engine, which triggers automated responses through APIs. Cyber Riposte places a Git repository between detection and action.

Here's what a playbook template looks like for DNS tunneling detection:

# playbooks/dns_exfiltration_mitigation.py
from dataclasses import dataclass
from typing import List

@dataclass
class DNSTunnelingAlert:
    suspicious_domains: List[str]
    source_ip: str
    entropy_score: float
    query_volume: int

def generate_mitigation(alert: DNSTunnelingAlert) -> str:
    """Generate Suricata rule to block high-entropy DNS queries"""
    
    rules = []
    for domain in alert.suspicious_domains:
        rule = f'''
alert dns any any -> any 53 (
    msg:"Potential DNS tunneling to {domain}";
    dns_query; content:"{domain}"; nocase;
    threshold: type limit, track by_src, count 1, seconds 300;
    classtype:policy-violation;
    sid:5000001; rev:1;
)
'''
        rules.append(rule)
    
    config = f'''# Generated by Cyber Riposte Agent
# Alert ID: DNS-TUNNEL-{alert.source_ip.replace(".", "-")}
# Entropy Score: {alert.entropy_score}
# Query Volume: {alert.query_volume}

{"\n".join(rules)}
'''
    return config

The agent detects anomalous DNS patterns, generates a Suricata rule as a string, then uses GitPython to create a branch and PR. The actual mitigation doesn't activate until someone reviews the generated rule, merges it, and your GitOps controller (ArgoCD, Flux, whatever) reconciles the change to your IDS cluster.

The really interesting pattern emerges in the 'Mirror' scenario, which combines defensive action with counter-reconnaissance:

# playbooks/mirror_and_gather.py
import requests
from ipaddress import ip_address

def generate_mirror_config(attacker_ip: str, honeypot_ip: str) -> dict:
    """Generate nftables DNAT rule + intelligence gathering report"""
    
    # Generate firewall redirect
    nftables_config = f'''table ip nat {{
    chain prerouting {{
        type nat hook prerouting priority -100;
        ip saddr {attacker_ip} tcp dport {{ 22, 80, 443 }} dnat to {honeypot_ip}
    }}
}}'''
    
    # Passive OSINT via Shodan (assumes API key in env)
    intel_report = gather_threat_intel(attacker_ip)
    
    return {
        "mitigation": nftables_config,
        "intelligence": intel_report,
        "pr_description": f'''## Attacker Mirror Response

**Source IP:** {attacker_ip}  
**Action:** Redirect to honeypot at {honeypot_ip}

### Threat Intelligence
- Open Ports: {intel_report.get("ports", "Unknown")}
- Hosting Provider: {intel_report.get("org", "Unknown")}
- Associated Domains: {intel_report.get("domains", [])}

**Review Checklist:**
- [ ] Verify IP is not from legitimate scanning service
- [ ] Confirm honeypot isolation from production
- [ ] Check legal constraints for jurisdiction
'''
    }

def gather_threat_intel(ip: str) -> dict:
    # Simplified - real version would use Shodan/Censys APIs
    return {
        "ports": [22, 80, 443, 3306],
        "org": "Example Hosting LLC",
        "domains": ["attacker-infra.example"]
    }

This is where the concept gets provocative. The agent doesn't just propose blocking the attacker—it redirects them to a honeypot while simultaneously gathering intelligence about their infrastructure. But critically, none of this happens until a human looks at the PR and decides whether redirecting traffic and scanning the attacker's IP is legally and operationally sound.

The asynchronous nature is the entire point. Traditional security automation optimizes for speed: detect threat, execute response, minimize dwell time. Cyber Riposte optimizes for correctness and accountability. Every defensive action produces a Git commit with a full diff. You can see exactly what changed, when, and why. If the agent proposes a firewall rule that would accidentally block legitimate traffic, the PR review catches it before it causes an outage. If the mitigation turns out to be overkill, you can revert the commit and the GitOps controller removes the rule automatically.

The predictive playbook pattern is equally interesting. Instead of reacting to completed attacks, the agent generates preemptive controls based on partial signals:

# playbooks/credential_stuffing_forecast.py

def predict_stuffing_targets(failed_auth_logs: List[dict]) -> List[str]:
    """Analyze failed auth patterns to predict next targets""\n    
    # Simplified model - real version would use ML clustering
    username_patterns = analyze_patterns(failed_auth_logs)
    
    if username_patterns["sequential_testing"]:
        # Attacker is walking through common usernames
        return generate_rate_limit_rules(scope="global")
    elif username_patterns["targeted_accounts"]:
        # Attacker has specific target list
        return generate_account_lockout_rules(
            accounts=username_patterns["targeted_accounts"]
        )
    
    return []

The agent notices an attacker testing credentials against one service, predicts they'll pivot to other services with the same credentials, and preemptively generates rate-limiting rules for those services. Again, nothing deploys until human review confirms the prediction makes sense.

Gotcha

The elephant in the room: latency. If an attacker is actively moving through your network, waiting for PR review, CI/CD pipeline execution, and GitOps reconciliation means they've already exfiltrated data or established persistence before your mitigation deploys. The repo's examples assume you have minutes to hours for response, which is realistic for proactive hardening but absurd for active intrusions. A credential stuffing attack can try thousands of passwords in the time it takes your agent to open a PR.

The legal and operational handwaving is equally problematic. The Mirror scenario casually proposes redirecting attacker traffic and scanning their infrastructure, which could violate computer fraud laws depending on jurisdiction and whether the 'attacker' is actually a security researcher or misconfigured scanner. The repo includes a disclaimer acknowledging these issues but provides zero framework for making those risk assessments. There's also the alert fatigue problem: if your agent generates 50 PRs during a sustained campaign, the review process becomes a bottleneck and operators will start rubber-stamping merges, defeating the entire purpose of human oversight. And finally, this is purely a concept repository—there's no actual AI agent implementation, no telemetry ingestion, no correlation logic. You're looking at templates and config examples, not working code.

Verdict

Use if: You're in a heavily regulated environment where every infrastructure change requires documented review anyway, and you want to explore how AI-assisted security could fit into existing change management processes. This pattern makes sense for compliance-driven policy adjustments, proactive threat hunting responses, or scenarios where accuracy and auditability matter more than speed. It's also worth studying if you're designing approval workflows for AI-generated infrastructure changes and need inspiration for making autonomous systems accountable. Skip if: You need operational security tooling for real incident response. The latency introduced by PR review makes this unsuitable for fast-moving threats. Also skip if you're looking for working code—this is a design pattern reference, not a deployment-ready system. If you need immediate response automation, look at Wazuh or Falco. If you need AI-assisted security with actual guardrails, investigate purpose-built SOAR platforms that have already solved the approval workflow problem without reinventing change management around Git.