Four policies covering deployments people actually run. Each is a working starting point, not a finished control: read the rules, keep what fits your system, and delete what does not.
Every rule here is exercised against realistic prompts in
src/inline/tests/example_policies.rs,
including inputs that must not fire. Copy that pattern for your own
policies — a guard nobody trusts gets turned off.
| Policy | Deployment | Posture |
|---|---|---|
starter.rgp |
Quickstart walkthrough | Minimal, three rules |
support-agent-pii.rgp |
Support assistant forwarding ticket text to a hosted model | Block identifiers, escalate account changes |
engineering-copilot-secrets.rgp |
Coding assistant with repo context | Block credential shapes, escalate env/DSN lines |
rag-untrusted-content.rgp |
RAG over user-uploaded documents | Escalate only — humans decide |
The split is the whole design, and it is about false positives.
Block when the matched string is self-evidently the thing: an AWS key ID in
AKIA… form is a credential, and no legitimate prompt needs to carry it. A
false positive costs one rejected prompt.
Escalate when the phrase is ambiguous in context. rag-untrusted-content.rgp
blocks nothing, because a security runbook legitimately discusses prompt
injection and a changelog legitimately quotes old instructions. Blocking those
produces noise, and operators respond to noise by disabling the guard — which
is strictly worse than routing to a human.
runtimeguard validate examples/policies/support-agent-pii.rgp
runtimeguard evaluate \
--policy examples/policies/support-agent-pii.rgp \
--evidence-dir ./evidence \
--signing-key rg-signing.key \
--request-id ticket-88231 \
--prompt "Customer says: my SSN is 123-45-6789"The evidence directory pins the policy's source digest on first use. Editing
the policy — including its comments — is a new policy identity and needs a new
evidence directory. See docs/writing-policies.md.
These are regex rules, not classifiers. They match shape, not meaning:
- The card rule checks issuer prefixes and grouping, not a Luhn checksum, so it both over-matches some digit runs and misses unusual issuer ranges.
- Secret detection covers documented credential formats. A bespoke internal token format needs a rule you write.
- Injection phrasing is unbounded. Escalation rules catch common shapes and will miss novel ones; they are a tripwire, not a boundary.
RuntimeGuard's guarantee is about the evidence — that the decision was bound to an exact policy, committed durably, and is externally verifiable. It is not a claim that the policy caught everything.