Stop sandboxing your Agent. Secure it instead — with a 5-layer engine drawn from immunology, aviation safety, game theory, control theory, and neuroscience.
Zero runtime dependencies. 32 built-in rules. P99 under 1ms. The Agent never knows it's there.
Every Agent security project we studied — hermes-agent, NemoClaw, openclaw, Claude Code — landed on the same answer: wrap the Agent in a safety envelope. Sandboxes, permission dialogs, regex blocklists. Different names, same logic.
We designed our own four-phase plan. Then we looked at it honestly and realized we'd done the same thing. All roads led to the same place: assume the Agent is dangerous, then cage it.
The cage works. But it cripples the Agent. A sandboxed Agent can't do the things you hired it to do. A confirmation dialog every 30 seconds turns your Agent into a script that needs a babysitter.
So we asked a different question.
The standard reasoning: "Probabilistic decision-maker + irreversible action = unsafe."
But humans are probabilistic too. We misclick, get phished, make mistakes. Yet a human at a terminal is far safer than an Agent with the same permissions. Why?
A human sees rm -rf / and traces the causal chain — root directory, everything gone, hours of recovery, unacceptable cost. An LLM sees the same command and checks statistical associations — "this pattern often co-occurs with 'dangerous' in training data."
Swap in find / -mindepth 1 -delete. Same effect. The human still catches it — semantics haven't changed. The LLM might miss it — not enough training samples.
The real root cause isn't probability. It's the absence of consequence understanding.
❌ probabilistic decision-maker + irreversible action = unsafe
✅ decision-maker without consequence understanding + irreversible action = unsafe
When every solution in your field converges on the same pattern, the framing itself is the cage. We looked outside.
Immunology gave us adaptive threat detection — innate immunity for known patterns, adaptive immunity for new ones, negative selection to kill rules that attack friendly operations.
Control theory gave us continuous safety margins instead of binary safe/dangerous — the closer to danger, the tighter the controls.
Aviation safety gave us the Swiss Cheese model (5 independent defense layers whose blind spots don't align) and automation levels (the critical Level 3: auto-execute with interrupt window).
Game theory gave us incentive compatibility — don't command the Agent to be safe, design a mechanism where safety is the Agent's optimal strategy.
Neuroscience gave us dual-process architecture — System 1 handles 99% of operations in <1ms, System 2 activates only when something feels off.
agent-guard installs as Claude Code hooks — PreToolUse and PostToolUse. Every tool call passes through the 5-layer engine before execution. The Agent can't see the hooks, can't bypass them, can't negotiate.
MCP = LLM chooses whether to call → Agent can bypass
Skill = LLM chooses whether to follow → Agent can ignore
Hook = code in the pipeline → Agent can't see it, can't bypass it
Security is not a feature of the Agent. It's a gate the Agent passes through.
| Layer | What It Does | Discipline |
|---|---|---|
| 1. Hard Rules | 32 deterministic rules: command blacklist, path protection, credential exposure, 10 injection pattern categories. P99: 0.038ms. | Immunology (innate immunity) + Neuroscience (System 1) |
| 2. Path Safety | Risk map by file sensitivity. .env = high risk, src/ = medium, node_modules/ = low. Outside project = flag. |
Control Theory (safety margins) |
| 3. Trust Evaluation | Start at zero trust. 50 safe operations → allow writes. 200 → allow deletes. One violation → trust drops, counter resets. | Game Theory (incentive compatibility) + Aviation (automation levels) |
| 4. Rate Anomaly | Burst detection + behavioral shift. 20+ calls in 10s or sudden risk score spike → flag. | Control Theory (PID monitoring) |
| 5. Synthesis | Swiss Cheese aggregation. 2+ layers flag the same operation → auto-DENY. Single flag + high trust → auto-pass with logging. | Aviation Safety (Swiss Cheese model) |
Credential sanitizer runs as PostToolUse hook — redacts AWS keys, GitHub tokens, JWTs, private keys, connection strings, and 6 more patterns from tool output before the LLM sees them.
Negative selection — new rules are tested against audit history before deployment. False positive rate > 5%? The rule dies before it ships.
130 test cases. 1000-call benchmarks on Apple Silicon.
| Metric | Result |
|---|---|
| Normal operations (70) | 70/70 ALLOW — 0% false positive |
| Medium-risk operations (20) | 20/20 detected |
| Dangerous operations (10) | 10/10 DENY — 0% miss |
| Injection samples (30) | 30/30 DENY — 0% miss |
| Layer 1 P99 | 0.038ms |
| Full pipeline P99 | 1.087ms |
| Runtime dependencies | 0 |
Prerequisites: Node.js ≥ 18
# 1. Install
npm install -g agent-guard
# 2. Hook into Claude Code
agent-guard config install-hook --agent claude-code
# 3. Initialize for your project
cd your-project
agent-guard init --project .
# You should see: ✓ Hooks installed, ✓ Project initialized
# From now on, every tool call is inspected. The Agent won't notice.# Security check (called automatically by hooks)
agent-guard check --tool Bash --params '{"command":"rm -rf /"}' --project . # → DENY
agent-guard check --tool Bash --params '{"command":"ls -la"}' --project . # → ALLOW
# Credential sanitization
agent-guard sanitize --input 'token: ghp_ABC...XYZ' # → [REDACTED]
# Trust management
agent-guard trust show|history|reset --project .
# Rule management
agent-guard rules list|test|add
# Audit log
agent-guard audit [--last 20] | stats | export --format csv
# Configuration
agent-guard config show|set|install-hook| Code | Meaning |
|---|---|
| 0 | ALLOW — proceed |
| 1 | DENY — blocked |
| 2 | CONFIRM — ask user |
| 3 | No-op (sanitize: nothing to redact) |
rules:
- name: block-production-db
description: Prevent direct production database access
layer: 1
type: blacklist
severity: critical
action: DENY
patterns:
- regex: "psql.*prod|mysql.*production"
description: "Direct production database connection"Test before deploying — immunology's negative selection:
agent-guard rules test block-production-db
# FP rate > 5%? Kill the rule before it attacks friendly operations.agent-guard/
├── src/
│ ├── cli/ # CLI entry points (check, sanitize, trust, audit)
│ ├── engine/
│ │ ├── checker.ts # 5-layer orchestrator
│ │ ├── layers/ # layer1-hard-rules → layer5-synthesis
│ │ ├── sanitizer.ts # Credential redaction (12 patterns)
│ │ └── tool-parser.ts # Tool classification (11 tool types)
│ ├── trust/
│ │ ├── state.ts # Trust persistence + scoring
│ │ └── policy.ts # Trust level → permission matrix
│ ├── rules/
│ │ ├── loader.ts # YAML rule loader
│ │ ├── matcher.ts # Pattern matching engine
│ │ └── negative-selection.ts # FP testing before deployment
│ ├── audit/ # Append-only audit log + rotation
│ └── config/ # Hook installer + project config
├── rules/builtin/ # 32 built-in rules (4 YAML files)
│ ├── command-blacklist.yaml
│ ├── path-protection.yaml
│ ├── credential-exposure.yaml
│ └── injection-patterns.yaml
└── doc/ # Article + architecture diagrams
This is a working first step, not a finished answer. What's built validates the design logic — the five disciplines hold up in testing. What's not built yet:
- Consequence prediction (System 2 deep analysis) — still in validation
- Adaptive rule evolution (immunology's adaptive immunity) — not started
- Multi-agent support — currently Claude Code only
MIT
The full design narrative — three rounds of questioning, five disciplines, and why security envelopes don't work — is in doc/别再把Agent关起来了——跨5个学科的安全重构.md.