Shields · node9 documentation
Shields
One-click protection packages for the services your AI agent touches.
Shields are pre-packaged sets of smart rules for specific services. Instead of writing regex patterns yourself, you enable a shield and get expert-crafted protection instantly. Shields are applied as a separate layer on top of core built-in rules — your config.json is never modified.
Layer 1 vs Layer 2
Layer 1 (always on): Core smart rules protect git, SQL, and shell for every user automatically.
Layer 2 (shields): Opt-in protection for specific infrastructure — only relevant if you actually use that service.
Layer 2 (shields): Opt-in protection for specific infrastructure — only relevant if you actually use that service.
Available Shields
postgresDatabase
Blocks:
Reviews:
Dangerous words:
Aliases:
DROP TABLE, TRUNCATE TABLE, DROP COLUMNReviews:
GRANT / REVOKE permission changesDangerous words:
dropdb, pg_dropclusterAliases:
pg, postgresqlmongodbDatabase
Blocks:
Reviews:
Dangerous words:
Aliases:
.dropDatabase(), .drop(), .deleteMany({}) (empty filter)Reviews:
.deleteMany() with filter, .dropIndex()Dangerous words:
dropDatabase, dropCollectionAliases:
mongoredisCache
Blocks:
Reviews:
Dangerous words:
FLUSHALL, FLUSHDB, CONFIG RESETSTATReviews:
CONFIG SET, wildcard DEL patternsDangerous words:
FLUSHALL, FLUSHDBgithubGit
Blocks:
Reviews: remote branch deletion via
Note: force push and local branch deletion are already covered by built-in core rules.
Aliases:
gh repo deleteReviews: remote branch deletion via
git push --deleteNote: force push and local branch deletion are already covered by built-in core rules.
Aliases:
gitawsCloud
Blocks: S3 bucket deletion (
Reviews: IAM changes, RDS deletion
Aliases:
aws s3 rb, aws s3api delete-bucket), EC2 instance terminationReviews: IAM changes, RDS deletion
Aliases:
amazonk8sInfrastructure
Blocks:
Reviews:
Aliases:
kubectl delete namespace, kubectl delete --all, helm uninstallReviews:
--replicas=0, deployment deletion, kubectl apply --forceAliases:
kubernetes, kubectldockerInfrastructure
Blocks:
Reviews:
docker system prune, docker volume prune, docker rm -fReviews:
docker stop, docker kill, docker volume rm, docker rmi --forcefilesystemLocal
Blocks:
Reviews:
Dangerous words:
Aliases:
rm -rf targeting home directory (~, $HOME, /home/*, /root)Reviews:
chmod 777, writes to /etc/Dangerous words:
wipefsAliases:
fsbash-safeShell
Blocks: pipe-to-shell (
Reviews:
Aliases:
curl | bash), obfuscated exec (base64 | sh), rm -rf /, raw disk writes (dd of=/dev/sd*)Reviews:
eval of dynamic contentAliases:
bash, shellCommands
Managing shields
# Enable a shield node9 shield enable postgres node9 shield enable aws # Disable a shield node9 shield disable postgres # List all available shields (with enabled/disabled status) node9 shield list # Show which shields are currently active node9 shield statusShields accept aliases:
node9 shield enable pg is the same as node9 shield enable postgres.Filesystem shield limitation
The filesystem shield covers common
rm -rf patterns but cannot intercept every file deletion method. Tools like unlink, find -delete, or language-level file operations (Python's shutil.rmtree) are not intercepted. The shield is a best-effort heuristic, not a full sandbox.How shields are applied
When you run node9 shield enable postgres, Node9 writes postgres to ~/.node9/shields.json. On every node9 check invocation, the engine reads that file, looks up the shield's rules in the built-in catalog, and appends them to the active policy — without touching your config.json. This means shield rules update automatically when you upgrade the Node9 binary.