Event-Driven Automation: How We Auto-Ban Malicious IPs in Real Time

Why Event-Driven Matters

Polling is how most automation systems react to new data. Check the database every 60 seconds, find new records, process them. It works. It is also slow, resource-intensive, and introduces a gap between when something happens and when you respond to it.

Event-driven automation removes that gap. Instead of polling, the system watches a collection and fires the moment a matching record appears. Zero lag. Zero wasted polling cycles. Reaction time measured in milliseconds, not minutes.

The Sovereignty Protocol's event cascade type is built exactly this way — it uses PocketBase's real-time subscription system to detect new records and trigger a cascade chain immediately.

The Auto-Ban Cascade: What It Does

The auto-ban cascade is the security workflow shown on the Sovereignty Protocol landing page. It demonstrates the full power of event cascades in a single, concrete example that most developers immediately understand.

The scenario: A suspicious request hits your server. The IP is logged to a security events collection. The cascade fires. Within seconds, the IP is geo-located, assessed by an AI agent, written to the ban list, and your team is notified.

No human needed. No 60-second polling delay. No manual review queue for standard cases.

The Cascade Definition (Step by Step)

Here is the cascade as it actually runs:

Trigger

type: event
collection: security_events
filter: (status = "pending") && (severity != "low")
state_field: status

The cascade watches the security_events collection. When a new record appears with status = "pending" and severity above low, it fires. The state_field prevents double-firing — as the cascade processes the event, it updates status from pending to the report ID, making the record no longer match the trigger filter.

Step 1: Geo Lookup

- name: geo_lookup
  type: geo_lookup
  ip: "$trigger.ip$"

Resolves the triggering IP address to country, city, ISP, and ASN. Takes ~200ms. The result is available to all subsequent steps as $geo_lookup.*$ .

Step 2: Police Agent Assessment

- name: assessment
  type: agent
  persona: police
  prompt: |
    IP $trigger.ip$ from $geo_lookup.city$, $geo_lookup.country$
    ($geo_lookup.isp$) triggered a $trigger.event_type$ event.
    Request path: $trigger.path$
    User agent: $trigger.user_agent$

    Assess the threat level, provide a brief rationale, and recommend
    action: BAN, MONITOR, or ALLOW.
  model: secondary

The Police agent receives the full context — IP, geo data, event type, request path, user agent — and produces a structured assessment with a recommended action and rationale.

Step 3: Write Ban Record

- name: write_ban
  type: db_write
  collection: ip_bans
  data:
    ip: "$trigger.ip$"
    country: "$geo_lookup.country$"
    reason: "$assessment.content$"
    report_id: "$meta.report_id$"
    banned_at: "$meta.timestamp$"
  condition: "$assessment.action$ == BAN"

If the agent recommended a ban, the record is written to the ip_bans collection. The condition field means this step only executes if the assessment result was "BAN" — monitor and allow recommendations skip this step.

Step 4: Discord Notification

- name: notify
  type: http
  method: POST
  url: "$env.DISCORD_WEBHOOK_URL$"
  body:
    content: |
      🚓 **IP Ban Applied**
      IP: $trigger.ip$ ($geo_lookup.country$)
      Event: $trigger.event_type$
      Reason: $assessment.content$
      Report: $meta.report_url$
  optional: true

A Discord notification is sent with the full context. Marked optional: true so if Discord is unreachable, the cascade does not fail — the ban has already been written.

The State Machine

The state_field: status configuration is what prevents a race condition. Here is what happens:

Record created with status = "pending" → triggers cascade
Cascade immediately updates status to "processing" → no longer matches trigger filter
Cascade completes, updates status to the report ID
Even if the record is somehow duplicated or re-queued, it will not trigger again

This deduplication is built into the cascade runtime. You do not need to write custom lock logic.

Building Your Own Event Cascade

The auto-ban cascade is a template. The same pattern works for any scenario where you want to react to database events in real time:

Customer onboarding — watch for new user records, trigger an enrichment + welcome email chain.

Payment failure handling — watch for failed payment records, trigger a retry + notification sequence.

Content moderation — watch for new user-submitted content, trigger an AI review + approval workflow.

Inventory alerts — watch for low-stock records, trigger a reorder notification and supplier contact.

Support ticket triage — watch for new support tickets, trigger an AI assessment + priority assignment + routing.

The pattern is always the same: something happens in your database → the event cascade fires immediately → your agent workflow handles it. No polling, no manual triggers, no delay.

What Makes This Governed

The auto-ban cascade is not just automated — it is governed. The Police agent operates under the active law set. It cannot produce recommendations that violate your ethical laws. Its outputs are logged in an immutable audit trail. Every ban record includes the full AI rationale.

If a ban is disputed, you can pull the exact Nexus Report for that event, see the geo data, the agent assessment, and the model response that led to the ban decision. That is governance — not just automation.