Guardrails

Concept of the skill

Use when planning or executing agent/tool operations that touch protected files, credentials, destructive git commands, destructive SQL, PII, secrets, deployments, package publication, or irreversible system mutations.

Coverage

This skill covers the portable guardrail discipline for agents and tool-using assistants: proactive action classification, reactive tripwires, input/output/tool-call guardrail placement, blocking vs advisory enforcement, protected-file and secret-exposure detection, destructive git and SQL patterns, deployment/package-publication gates, excessive-agency containment, and the verification protocol for high-risk operations.

Philosophy of the skill

Agents with broad tool access will eventually approach dangerous operations -- not from malice, but from inference errors, ambiguous instructions, or optimistic assumptions about reversibility. Guardrails exist to make irreversible actions harder to reach than safe alternatives. "Allowed" is not the same as "safe": an agent may be authorized to edit a repo and still need a hard stop before it writes a secret, force-pushes main, drops a production table, or publishes a package.

The core distinction is placement. A pre-action classifier asks "what kind of operation is this?" A guardrail asks "should this exact input, output, or tool call be blocked, escalated, or logged?" Modern agent frameworks expose input guardrails, output guardrails, and tool guardrails at different workflow boundaries; high-risk side effects require checks around the tool invocation itself, not only around the first user message or final answer.

Guardrail Model

Use guardrails as a layered circuit breaker:

For actions with real side effects, prefer blocking guardrails over parallel guardrails. Parallel checks may improve latency, but they can complete after the agent has already consumed tokens or invoked tools. Blocking is slower and more conservative, which is exactly the right tradeoff for protected paths, irreversible mutations, credentials, and production-adjacent systems.

Protected Operations

Any operation matching these patterns triggers a block or high-severity warning.

Git Mutations

• Force push: git push --force or -f is blocked unless the user explicitly asked for history rewrite on the exact branch. Prefer --force-with-lease when force is truly required.
• Hard reset: git reset --hard is blocked outside disposable worktrees unless the user explicitly authorizes discarding uncommitted work.
• Clean/delete: git clean -f, branch deletion, tag deletion, and bulk file removal require a preview of affected paths first.
• History rewrite: rebase, filter-repo, amend, or squash after publication requires confirmation of the remote branch and collaborators affected.

Filesystem & Secrets

• Protected files: writes to .env*, credentials.*, id_rsa*, *.pem, *.key, keystores, or CI secret config are critical by default.
• Sensitive reads: reading protected files is reconnaissance, not passive browsing. Do not echo or summarize secret values into chat or logs.
• Secret patterns: scan proposed writes and command output for generic API keys, provider keys, GitHub token prefixes such as ghp_..., live payment keys such as sk_live_..., and private key sentinels such as BEGIN ... PRIVATE KEY.
• Repository protection: automated secret scanning and push protection are useful backstops, not replacements for pre-write/pre-push guardrails.

SQL Execution

• Unbounded mutation: DELETE FROM or UPDATE without a WHERE clause is blocked.
• Schema destruction: DROP TABLE, TRUNCATE, and ALTER TABLE ... DROP COLUMN require an explicit rollback/restore plan.
• Production ambiguity: if the connection target might be production, classify it as production until proven otherwise.
• Bulk backfill: large updates require batching, progress visibility, and a tested interruption path.

Deployment, Publication, and External Effects

• Package publication: npm publish, pip upload, container pushes, release tags, and marketplace submissions require dry-run or preview where the tool supports it.
• Deployments: production deploys require current branch, diff scope, target project, environment, and rollback path to be stated before execution.
• Credential rotation: rotating keys, revoking tokens, or changing auth providers is destructive to dependent systems unless the rollout plan names consumers and fallback.
• Third-party writes: calls that send email, charge money, modify remote config, delete cloud resources, or open public issues/PRs are state-changing even when the local filesystem is untouched.

Enforcement Tiers

Escalation must be boring and specific: name the exact command or tool call, the target, the risk, the safer alternative, and what evidence would allow progress. A guardrail message that only says "unsafe" teaches the agent nothing.

Pre-Action Protocol

Before any high-risk operation:

1. Classify the action using intent-recognition: operation, target, tier, and whether the target sensitivity elevates the tier.
2. Preview the effect: changed paths, affected rows, target branch, remote service, package name, or deployment environment.
3. Scan proposed inputs, outputs, and file writes for secret-like strings and protected paths.
4. Prefer the reversible form: dry-run, preview, branch, archive/rename, soft-delete, --force-with-lease, transaction, rollback migration, or staged rollout.
5. Confirm only when needed: ask the user for explicit approval when the operation is destructive, irreversible, public, credential-affecting, or production-adjacent.
6. Log the decision when the harness supports it: blocked action, bypass reason, approving user, timestamp, and verification evidence.

Agentic Threats

Guardrails for tool-using agents must cover LLM-specific risks as well as classic software safety:

Drift Traps

Verification

• [ ] The action was classified by operation and target, with sensitive targets elevated.
• [ ] Any destructive or public action included a preview of affected paths, rows, branch, environment, package, or remote resource.
• [ ] Proposed writes and command outputs were scanned for secret-like values before committing, publishing, or posting.
• [ ] A reversible alternative was considered and chosen unless the destructive action was explicitly required.
• [ ] Blocking guardrails were used for protected paths, credentials, production-adjacent tools, and irreversible mutations.
• [ ] Tool-level guardrails cover side-effecting tools; agent-level input/output guardrails are not the only safety layer.
• [ ] Any bypass or escalation captured the exact reason, approving user, and verification evidence.

Do NOT Use When

Skill Graph context

<!-- skill-graph-context:start (generated — do not edit by hand) -->

Classification

• Subject: ai-engineering
• Public: true
• Domain: quality/safety
• Scope: Teaches proactive safety control for agent and tool operations: protected-surface recognition, tripwire placement, block-vs-advise decisions, secret and PII exposure prevention, destructive-operation containment, and excessive-agency limits. Portable across tool-using agent workflows. Excludes ordinary application validation, git workflow design, migration authoring, and general correctness review.

When to use

• Triggers: guardrails-skill, tool-guardrails, tripwire-skill, agent-safety-guardrails

Related skills

• Verify with: intent-recognition, code-review, prompt-craft
• Related: version-control, database-migration, intent-recognition, code-review, cognitive-load-theory

Grounding

• Mode: hybrid
• Truth sources: https://openai.github.io/openai-agents-python/guardrails/, https://owasp.org/www-project-top-10-for-large-language-model-applications/, https://www.nist.gov/itl/ai-risk-management-framework, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf, https://docs.github.com/en/code-security/how-tos/secure-your-secrets/detect-secret-leaks

Keywords

• guardrails, tool guardrails, tripwire, safety gate, force push, secret detection, destructive action, protected files, circuit breaker, excessive agency

<!-- skill-graph-context:end -->