Your Security Dashboard

Picture this. An auditor sits across from you and asks: “Show me every time an AI agent accessed sensitive data in the last 90 days.”

You could dig through server logs. Parse timestamps. Hope nobody truncated the files when the disk filled up. Try to reconstruct a timeline from fragments spread across three different systems.

Or you open a browser, pull up your dashboard, set the date range, and filter by severity. Every decision is there, in order, verified. The auditor gets their answer in two clicks.

The GuardClaw dashboard takes the security data your CLI generates and turns it into something you can read, filter, share, and present to anyone who asks “are we secure?” This post walks through what you’ll see and what it all means.

Why a dashboard when everything runs locally

Here’s an analogy. Security cameras don’t prevent break-ins. What they do: change behavior (people act differently when they know they’re being recorded), and provide evidence when something goes wrong.

GuardClaw’s detection engine is the lock on the door. The dashboard is the camera system. The engine makes the security decisions locally on your machine. The dashboard shows you what those decisions were, so you can understand patterns, spot problems, and answer questions.

Signing in

Go to guardclaw-dashboard.web.app and sign in with Google, GitHub, or Apple.

If you connected your CLI to the cloud in the first post of this series (guardclaw connect), your workspace is already set up. Your receipts are there. If you haven’t connected yet, you can do that first — instructions are in Getting Started with GuardClaw.

Free accounts get dashboard access with basic visibility. Pro plans add advanced features like policy management, live pattern feeds, and 90-day data retention.

The overview: four numbers that matter

When the dashboard loads, you’ll see four numbers at the top:

• Total scans — how many actions GuardClaw evaluated this billing period. Every file read, shell command, and API call your agent made that passed through the security gate counts as one scan.

• Block rate — the percentage of actions that were denied. A high block rate might mean your agent is encountering a lot of threats, or it might mean your policies are very strict. Context matters.

• Active agents — how many agents are currently running with GuardClaw supervision. If you’re running guardclaw run on two projects right now, this shows 2.

• Receipt count — the total number of receipts in your audit trail. Every decision (allow or deny) generates one receipt.

Below these numbers, a usage chart shows your scan volume over time. Spikes usually mean someone deployed a new agent or kicked off a large batch of tasks.

The audit trail: what your agents actually did

This is the section you’ll use most. Every receipt your CLI generated — every allow, every deny, every flag — shows up here in chronological order.

Each entry tells you:

• When the decision happened
• What the agent tried to do (which tool, which action)
• Whether it was allowed or denied
• Why it was blocked (if it was blocked)
• How severe the engine scored it
• Which policy rule triggered the decision
• Which attack category it matched (OWASP classification)

You can narrow down what you’re looking at:

• By date range — “show me everything from last Tuesday”
• By decision type — “show me only the denials”
• By severity — “show me only high and critical”
• By agent — “show me what this specific agent did”

One important detail: the receipt chain is cryptographically verified. The dashboard checks the hash chain when it loads your data. If anyone tampered with a receipt between your CLI and the dashboard — deleted one, changed one, inserted a fake one — the chain would break and the dashboard would flag it. This is the same concept as a blockchain, applied to your audit log.

Policies: the rules your agents follow

The Policies section shows which security rules are active. GuardClaw ships with a default policy that works like this: deny everything unless it’s explicitly allowed.

From the dashboard you can see:

• Which policies are currently active
• Which policy packs you’ve enabled (groups of rules focused on specific threat categories, like OWASP Top 10 or Data Protection)
• How many times each rule has been triggered — which tells you which rules are actually catching things and which ones are inactive

Policy changes happen through the CLI or API, not the dashboard. The dashboard shows you the current state and enforcement history so you can decide what to adjust.

Compliance: connecting enforcement to frameworks

If your organization needs to meet compliance standards — SOC 2, GDPR, HIPAA, or the EU AI Act — the compliance section maps your GuardClaw activity to the specific controls auditors care about.

For example:

• SOC 2 — your tamper-evident receipt chain maps directly to audit logging controls. The cryptographic verification proves the logs haven’t been altered.
• GDPR — GuardClaw’s data boundary enforcement (blocking agents from accessing files outside their project) maps to data processing requirements.
• HIPAA — access controls and the audit trail map to technical safeguard requirements.

This isn’t a checkbox exercise where you claim compliance because you have a policy document. The mapping connects your actual enforcement data — real denials, real audits, verified receipts — to the specific controls that auditors ask about.

When they say “show me your audit log controls,” you show them a cryptographic receipt chain with every decision your agents made. That’s a different conversation than showing them a Word document.

What the dashboard is telling you

After a week of running GuardClaw with supervised execution, the dashboard gives you a clear picture:

• How often your agents try to do something outside their boundaries
• Which threats appear most frequently in your environment
• Whether your policies need adjustment — too strict (blocking legitimate work) or too loose (letting things through)
• A verifiable record you can present to anyone who asks — leadership, auditors, customers, or your own team

The dashboard doesn’t make security decisions. The local engine on your machine does that, in real time, with no cloud dependency. The dashboard shows you what happened, so you can understand your environment and make informed decisions about what to change.

Where to go from here

This wraps up the “GuardClaw in Practice” series. You’ve installed the CLI, run attack simulations, set up supervised execution, and explored the dashboard.

For deeper reading on the threat models behind all of this — why agents need different security than traditional software, what prompt injection actually is, and how defense in depth works — check out The Builder’s Guide to Agent Security. It’s a 12-part series on agent security architecture.

For a technical breakdown of the seven defense layers GuardClaw uses, there’s Seven Layers of Defense.

And for the story behind why we built this product, Why We Built GuardClaw.