What GuardClaw Watches at Runtime

Agent security gets checked at three different moments. Static analysis reads the code before it ships. Request filtering reads what goes into the model and what comes back. And then the agent runs, and starts calling tools.

GuardClaw works at that third moment, on what the agent does while it is running. This post explains what that moment involves and why it needs its own check.

The three layers of AI security

Think of AI security as three layers:

Layer 1: Code and dependency scanning. Tools that analyze your source code, find vulnerabilities in dependencies, detect hardcoded secrets, and flag insecure patterns. This happens before your code runs. It catches problems in the code itself.

Layer 2: Model input/output filtering. Tools that check what goes into the model (prompt injection detection) and what comes out (output validation, content filtering). This happens at the boundaries of the model, what goes in and what comes back.

Layer 3: Runtime agent security. Watching what the agent actually does after the model produces a response. The agent decided to run a shell command. Should it be allowed? The agent wants to read a file. Is it within bounds? The agent is making an API call. Is the destination safe?

GuardClaw operates at layer 3.

Why runtime matters

Imagine a building with a metal detector at the front door (layer 1, scanning) and a receptionist who checks IDs (layer 2, input validation). Good security. But once someone is inside the building, nobody is watching which rooms they enter, which filing cabinets they open, or which documents they photograph.

Layer 3 is the security cameras and locked doors inside the building. Even after someone passes the front desk, every door they try is checked.

For AI agents, runtime security matters because:

• Agents chain actions. A model might produce a safe-looking plan, but the execution of that plan involves dozens of individual actions. Each one needs checking.
• Context changes. An agent reading a file might encounter a prompt injection embedded in the content. The action started safe and became dangerous mid-execution.
• Tools have side effects. A shell command isn’t just text, it modifies files, starts processes, sends network requests. The consequences are real.

Three design decisions that define GuardClaw

1. Local-first

Your code is never uploaded. The detection engine runs on your hardware, and a security decision needs no network at all, so GuardClaw keeps protecting you offline. In its default setup it does check our pattern feed every thirty minutes for new attack signatures, and you can turn that off.

Why we chose this: Sending your code or your agent’s actions to a cloud service for security evaluation creates a new data exposure. The security tool itself becomes a data processing relationship you need to manage. For teams handling sensitive code, proprietary algorithms, or regulated data, that’s a problem.

The trade-off is sync latency. GuardClaw uses periodic pattern syncs, a live feed on Pro plans and weekly on free. When a new attack pattern is published, a locally synced feed picks it up at the next sync rather than the moment it lands.

2. Deterministic detection

GuardClaw uses compiled pattern matching (Bloom filters, Aho-Corasick, RE2 regexes) and rule-based policies. Not AI. Not probabilistic scoring. Deterministic rules that produce the same result every time.

Why we chose this: Security decisions need to be predictable. When an auditor asks “will this action be blocked?”, the answer should be “yes, always” or “no, never”, not “probably, 94% of the time.” Deterministic rules are auditable. You can read them, test them, verify them.

The trade-off: Pattern matching catches known attack patterns. A novel attack that doesn’t match any pattern gets through. AI-based detection can theoretically catch novel attacks through behavioral analysis. We address this partially with anomaly detection (behavioral patterns that flag unusual sequences), but it’s an area where the approach has limits. We keep writing about what we change as we learn it, on the blog.

3. Defense in depth

Seven independent layers, each assuming the others can fail. Not one filter with one chance to catch an attack. Seven different approaches, each catching what the others miss.

Why we chose this: One layer with 95% accuracy misses 5 attacks out of 100. Seven layers, each built to catch what the ones before it missed, cut that a long way down. We publish the numbers we actually measure rather than a compound figure we cannot test. Compound probability is the only way to get security that holds against creative attackers.

The trade-off: More layers means more complexity, more rules to maintain, and more potential for false positives. We manage this with tiered detection (fast checks first, deeper analysis only when earlier tiers flag something) and configurable strictness levels.

What GuardClaw doesn’t do

Being clear about boundaries:

• Doesn’t scan your code for vulnerabilities. Use a SAST tool for that.
• Doesn’t filter model outputs for hallucinations or harmful content. That’s a different layer.
• Doesn’t replace your security team. GuardClaw is a tool, not a service. You still need people who understand your threat model.
• Doesn’t guarantee 100% detection. No security tool does. Our last measured run caught 98.1 percent of the bundled malicious corpus, and our test gate fails the build below 95 percent, so you can see the floor as well as the number.

Where it fits in your stack

GuardClaw complements your existing security tools. It doesn’t replace them.

If you use a code scanner, keep using it. If you use an API gateway, keep using it. GuardClaw fills the gap between “the code is safe” and “the agent is behaving safely”, which is the runtime layer that most teams don’t have yet.

Next post: rolling out GuardClaw across a development team, covering permissions, workspaces, and shared visibility.

Take Interest Inc. (2026). What GuardClaw Watches at Runtime. Take Interest. https://takeinterest.ai/blog/how-guardclaw-is-different