Suy Sideguy
Runtime safety guard for autonomous AI agents.
Suy Sideguy watches a running agent process and decides whether actions should be SAFE, FLAGGED, HALTED, or KILLED based on your policy.
What this tool is (and is not)
✅ What it does
- Watches process, file, and network behavior for an agent process
- Applies policy rules (optionally with a local LLM judge via Ollama)
- HALT suspicious actions (freeze + alert) before they escalate
- KILL severe violations with
SIGKILLwhen policy requires it - Stores evidence and can generate incident-ready forensic reports
⚠️ What it does not do
- It is not kernel-level enforcement (it runs in userspace)
- File visibility via
psutil.open_files()is best-effort and OS-dependent - Network checks are based on observed remote IP/port; domain matching can be lossy after DNS
Relationship to Little Canary
- Little Canary protects the input side (prompt-injection sensing)
- Suy Sideguy protects the runtime/output side (containment + forensics)
Use both for defense in depth.
Install
pip install suy-sideguy
Requires Python 3.9+.
For development:
git clone https://github.com/roli-lpci/suy-sideguy.git
cd suy-sideguy
pip install -e ".[dev]"
5-minute quickstart
1) Choose target process
Use one of:
--agent-pid(recommended for production)--agent-name(convenient, but can match unintended processes)
2) Start from the example policy scope
- Open
examples/scope.openclaw.yaml - For staged rollout, start with
examples/scope.low-disruption.yaml - Narrow allowlists to only what your workload truly needs
3) Run the warden
# Safer targeting: PID
suy-warden --scope examples/scope.openclaw.yaml --agent-pid 12345 --poll 0.5
# Convenience targeting: process name
suy-warden --scope examples/scope.openclaw.yaml --agent-name openclaw --poll 0.5
4) Generate report after a run
suy-forensic-report --last-hours 24
Where logs and evidence go
Default paths:
~/.local/share/sysmond/warden.log~/.local/share/sysmond/logs/actions_*.jsonl~/.local/share/sysmond/logs/incidents/*.json
Tip: treat these as security artifacts. Protect access and define retention/rotation.
Recommended rollout strategy
- Audit-first: observe and tune policy without auto-kill pressure.
- Confirm mode for ambiguous events.
- Enforce mode only after your hard invariants are validated.
Important safety caveats
SIGKILLis immediate and can interrupt legitimate work if policy is too broad.- Name matching (
--agent-name) can over-match; prefer PID targeting in production. - This project should be one part of a layered defense strategy.
Verdict levels
| Verdict | Meaning | Response |
|---|---|---|
SAFE |
Action is within policy | Continue |
FLAG |
Suspicious, below threshold | Log, continue |
HALT |
Dangerous pattern detected | Freeze, alert operator |
KILL |
Critical violation | SIGKILL immediately |
HALT triggers (freeze + alert, agent is not killed)
- 3+ file deletions in 10 seconds — mass deletion pattern
- curl or wget spawned — unexpected outbound data transfer
- 50+ network calls in 60 seconds — bulk messaging / API spam
- Write outside allowed workspace — unexpected filesystem access
KILL triggers (immediate, no recovery)
- SSH key access — any read/write to
~/.ssh/or*id_rsa*,*id_ed25519* - Config tampering — writing to
~/.openclaw/openclaw.json - rm -rf on non-tmp paths — destructive sweep outside
/tmp - Forbidden paths — any path in your scope's
deny_writelist
Expected flag noise (early rollout)
Early flag noise is normal during policy calibration on real workloads.
- Treat early
FLAGevents as calibration data, not immediate defects. - Use policy thresholds (
flag_threshold,flag_window) to control when accumulated risk escalates to kill. - Keep hard invariants (e.g., forbidden secrets paths / destructive commands) as immediate stop conditions.
- Start in audit-first mode, then tighten only after reviewing forensic logs.
Release quality status
Current status based on repository checks and CI configuration; not a formal security certification.
- ✅ Tests in repo (
pytest) - ✅ Package buildable (
python -m build) - ✅ CI workflow (
.github/workflows/ci.yml) - ✅ Publish workflow (
.github/workflows/publish.yml) - ✅ Security disclosure policy (
SECURITY.md)
Development
pip install -e .[dev]
pytest
Also see:
CONTRIBUTING.mdSECURITY.mdPUBLISH_CHECKLIST.mdAGENTS.mdCODE_OF_CONDUCT.md- Audit checklist:
docs/AUDIT_CHECKLIST.md - Layered plan:
docs/IMPLEMENTATION_PLAN_LAYERED.md
Metadata
Release files for suy-sideguy 0.1.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| suy_sideguy-0.1.3.tar.gz | 28.4 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| suy_sideguy-0.1.3-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 52.6 kB
Release files / suy_sideguy-0.1.3.tar.gz
| Download URL | suy_sideguy-0.1.3.tar.gz |
|---|---|
| Size | 28.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
7b4d2c105d832ed6877e45c528e2c78507863b4ec21cea2f70685ccadb8c9cec
|
|
BLAKE2b-256 checksum How to use checksums |
dfaf1a7941b86435d983bdea2078f180055a2d3e7597303e34dce63adf9569d3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.15
|
Release files / suy_sideguy-0.1.3-py3-none-any.whl
| Download URL | suy_sideguy-0.1.3-py3-none-any.whl |
|---|---|
| Size | 24.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
f210bbbdc0f7bd0c5a293f4748cc37f33f7d57b94e8bf7a0e1a79089e0138be5
|
|
BLAKE2b-256 checksum How to use checksums |
3178076f5c56cd073558ef9e6c3a4fd74fc43efc300796a6ad665fb407da04fa
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.11.15
|