Repository navigation
Add policy-as-code layer for agent runtime governance #2
Description
ShellWard's 8-layer defense is the strongest open-source agent security middleware I've seen — it covers everything from PII detection to DLP to data exfiltration blocking. One area that would complement the runtime defense is a declarative policy layer for agent governance at the Git/CI boundary.
Why it fits: ShellWard already handles runtime behavior (block dangerous commands, redact secrets, enforce DLP). A policy-as-code file in the repo (e.g. ) would let teams declare pre-deployment rules like:
- "Only the tool may run in CI — never "
- "Agents authored by external contributors must have limited tool scope"
- "Prompt injection detector must be enabled for all PRs touching "
This creates a defense-in-depth chain: policy at Git push → enforcement at runtime, closing the gap where an agent can be injected during development but only caught at execution. ShellWard's existing GitHub Action integration is the natural place to evaluate such a policy before the agent even starts.
Activity
feat(policy): policy-as-code 门禁 .shellward.json (响应 issue #2) v0.7.21
jnMetaCode commentedon Jun 23, 2026
Thanks @cschanhniem — this is a great suggestion and exactly the right direction (policy at the Git/CI boundary complementing runtime enforcement). I shipped a lightweight v1 of policy-as-code in
v0.7.21:Drop a
.shellward.jsonin your repo root:{ "failOn": ["secret", "pii"], "maxFindings": 0, "allowOverseas": ["OpenAI"] }failOn— fail CI if any finding matches these kinds (secret/pii/overseas/env-perm) or severities (critical/high/medium)maxFindings— max total findings allowedallowOverseas— overseas LLM providers explicitly permitted (exempt from failure)shellward scan --ci(and the GitHub Action) reads it and gates the build; without the file it defaults to "fail on any critical". This gives the declare-at-push → enforce-at-runtime chain you described.This is a deliberately small first cut. The richer rules you mentioned are the natural next step — I'd love your input to get them right:
/agentsmust have injection detection enabled")policyVersion/ schema so it's forward-compatibleIf you can share 2–3 concrete rules from your own setup, I'll extend the schema to cover them. PRs very welcome too. Thanks again for engaging — this is the first community-driven feature in the project. 🙏
MemoAsh commentedon Jul 5, 2026
I am testing an AI coding-agent safety receipt pack. If you had to keep this minimal for a paid pilot, what 2-3 policy fields would you require at PR-review scope?
For example:
If you think the pack is still too weak without runtime enforcement, tell me what is the minimal enforcement boundary you would trust for a first-paid tryout.
jnMetaCode commentedon Sep 28, 2026
Update (v0.7.22): two items from the list above are now shipped via #5.
rules: [{ "path": "agents/**", "failOn": ["overseas"] }], checked on top of the global rules; per-ruleallowOverseascan override the global allowlist.versionfield —"version": 1; a newer version, unknown fields or misspelledfailOnvalues now produce visible warnings instead of being silently ignored (previously a typo could quietly turn the gate into a no-op).Still open: tool scope by authorship (external contributors get a narrower policy). That needs PR author context, which
scan --cidoes not have today; the likely shape is the GitHub Action passing author association into the policy. Leaving this issue open for that — concrete rule examples are still very welcome.chenhz01 commentedon Oct 2, 2026
ShellWard's 8-layer runtime defense is genuinely strong, and a declarative policy layer at the Git/CI boundary is the right complement — runtime blocking catches bad behavior, but a policy gate at merge time stops the dangerous config from shipping at all. Since the maintainer already shipped per-path requirements (#5), the natural next step is a policy test: assert that a PR adding
overseastoagents/**fails the gate. That closes the loop between the policy and its enforcement.