Setting Up Alerts and Monitoring

You set up GuardClaw. It’s running. Your agents are supervised. Receipts are syncing to the dashboard.

But you have a job to do. You’re not going to sit and watch the dashboard all day. You need to know when something important happens without actively looking for it.

This post covers how GuardClaw surfaces important events — from automatic enforcement to dashboard monitoring patterns to building a weekly review habit.

Automatic enforcement: the first line

The most important alerts are the ones you never need to see — because GuardClaw already handled them.

When the detection engine blocks an action, that’s enforcement. No notification needed. The threat was stopped. The receipt was logged. Your agent moved on.

For critical threats — an agent trying to modify its own configuration files, a detected exfiltration attempt, a persistent injection pattern — GuardClaw’s supervisor can terminate the agent session entirely. The guardclaw run command monitors for fatal receipts and kills the supervised process when one occurs.

This means the most dangerous situations are handled automatically. You find out when you check the dashboard, not in real time. That’s by design — the response already happened.

Dashboard monitoring patterns

The dashboard shows your agent activity over time. Here’s what to look for during a regular check:

Denial spikes. A sudden increase in blocked actions usually means one of three things:

1. A new agent was deployed with access it shouldn’t have (policy needs adjustment)
2. The agent encountered adversarial content (prompt injection in a file or dependency)
3. A policy change made enforcement stricter (your intended change is working)

The dashboard shows when the spike happened and what type of denials occurred. That context tells you which scenario you’re dealing with.

New OWASP categories. If your denial history is usually prompt injection and command injection, and you suddenly see path traversal attempts, something changed. A new dependency, a new data source, or a new attack vector targeting your environment.

Block rate changes. A team running 5% block rate that suddenly jumps to 15% should investigate. A team running 0% block rate should also investigate — either the agents aren’t doing anything interesting, or the policies are too permissive.

Building a weekly review habit

For most teams, a weekly review of the audit trail is more useful than real-time alerting. Here’s a simple routine:

Every Monday morning (15 minutes):

1. Open the dashboard. Check the scan count and block rate for the past week.
2. Filter denials to high and critical severity. Are there any you haven’t seen before?
3. Check for new OWASP categories in the denial history.
4. Look at the per-agent breakdown. Is one agent generating significantly more denials than others?
5. If anything looks unusual, dig into the receipt chain for that time window.

This takes 15 minutes and gives you a clear picture of your agent security posture for the week.

When to investigate immediately

Some patterns warrant same-day investigation:

• Configuration tampering: Any receipt showing an agent attempted to modify GuardClaw’s own files. This is a self-protection event and should be rare. If it happens, the agent may have encountered an injection that explicitly targets the security layer.
• Repeated injection patterns: The same injection appearing across multiple agent sessions. This suggests a persistent source — a compromised file, a poisoned dependency, or malicious content in a shared data source.
• Credential access attempts: Any denial involving .env files, SSH keys, API tokens, or credential stores. Even though GuardClaw blocked it, the fact that the agent tried means something in its input directed it there.

Webhooks for automated alerting

For teams that want real-time notifications for specific event types, GuardClaw supports webhooks on Pro and Ultimate plans. You can configure a webhook URL that receives a POST request when specific conditions are met — critical severity denials, self-protection events, or anomaly score thresholds.

The webhook payload includes the full receipt data, so your incident response tooling (PagerDuty, Slack, or whatever you use) gets the complete context.

Configure webhooks from the dashboard’s settings page, or via the API.

The goal

The goal isn’t to react to every denial. Most denials are the system working correctly — blocking things your agent shouldn’t do. The goal is to notice patterns that indicate something has changed.

A single command injection denial in a week? Normal. Your agent probably encountered untrusted content. GuardClaw handled it.

Fifty command injection denials in an hour? Something is actively targeting your agent. Time to investigate the source.

The audit trail gives you the data. The weekly review gives you the habit. Together, they keep you aware without making you anxious.

Next post: GuardClaw and the EU AI Act — what the August 2026 deadline means and which requirements GuardClaw helps you meet.