backbond-local-rules/2.0.2 · v0.6.3
These rules inspect supplied static evidence. A finding is a reason to stop, constrain, isolate, or review. It is not proof of exploitation. Derived evidence can overreach; missing runtime evidence remains unknown.
A code or shell execution capability accepts content classified as untrusted.
Restrict executable inputs to trusted sources, validate against a narrow allowlist, and isolate execution in a runtime-enforced sandbox.
The runtime can access secrets and has an unrestricted outbound network scope.
Scope credential access to named secrets and restrict outbound destinations to an explicit allowlist; separate secret-reading and network-sending roles.
A destructive or financial capability can run without a runtime-enforced approval gate.
Place the named consequential tools behind a runtime-enforced approval gate and test that bypass attempts are blocked.
An explicit readOnlyHint suppresses inferred persistence when the remaining metadata does not indicate a write. Contradictory write metadata remains subject to the rule. A standalone untrusted persistent write is review-level. It becomes high when the same supplied tool inventory also contains an untrusted fetch or unallowlisted network destination.
Validate and provenance-tag memory writes, segregate untrusted content, and require review before untrusted data influences later sessions.
A privileged capability is configured without observable audit recording.
Record privileged tool invocation, approval identity, outcome, and stable correlation IDs in an operator-controlled audit sink.
Filesystem, subprocess, credential, or network permissions use an unrestricted wildcard scope.
Replace wildcard permissions with the smallest explicit path, executable, credential, and destination allowlists required by the runtime.
An executable tool context accepts unconstrained shell, code, evaluator, or database-interpreter input. Ambiguous query and expression fields route to review.
Use parameterized queries and named operations; reject arbitrary commands, scripts, expressions, and SQL before tool dispatch.
An active network tool accepts a URL, URI, or webhook destination without an observable hostname allowlist. Generic endpoint, host, path, or destination fields route to review.
Resolve destinations from operator-owned identifiers or enforce an explicit scheme and hostname allowlist before dispatch.
A tool description contains language that attempts to replace system, developer, safety, operator, or user instructions.
Treat tool metadata as untrusted input; reject instruction-override phrases and keep behavioral policy outside tool descriptions.
A tool description tells the agent to hide an action or instruction from the user, operator, or human reviewer.
Reject tool metadata that suppresses operator visibility; require user-visible intent, invocation, and outcome for consequential actions.
A tool description directs passwords, secrets, credentials, tokens, private keys, or environment values into a result or transmission.
Keep credentials out of tool descriptions and model-visible arguments; use runtime secret injection scoped to an allowlisted destination.
A fetch-like untrusted network tool shares one supplied inventory with explicit privilege or destructive-action evidence. Permission or delete appearing only in help text is insufficient.
Use separate agent roles or a runtime-enforced trust boundary that prevents fetched content from influencing privileged tool selection and arguments.
A tool description directs the model to always select it, invoke it before responding, or avoid competing tools.
Keep routing and tool-selection policy outside untrusted tool metadata; reject descriptions that demand priority, mandatory invocation, or exclusion of other tools.
Known boundary: scoped first-party guidance such as “always use this tool for weather” can resemble forced selection. Confirm derived evidence. Language demanding invocation before every reply or exclusion of competing tools remains a stop condition.
A permalink explains a deterministic rule. It is not evidence that a deployed environment was observed, exploited, monitored, verified, eligible for coverage, or insured.
Running this package does not create insurance coverage, determine eligibility, or imply that BackBond verified the environment.