Prompt Safety Validation

Updated on Oct 1, 2026

Forge scans input for prompt injection patterns before it sends content to the AI agent. Detection protects against instructions hidden in issues, tickets, modifier files such as edit.md, or custom prompts. This page describes the built-in rules and how to handle false positives.

How it works

Before composing a prompt, Forge checks the input against the detection rules.
A match with severity error blocks the command. A match with severity warn is logged, and the command continues.
Matches inside Markdown code fences are skipped by the default allowlist.
Forge logs each detection with the rule ID, rule name, source, matched content, and position, and records whether you bypassed the check.

Example output (abbreviated):

Error: Prompt injection attempt detected

Detected patterns:
 …

This content was blocked because it contains patterns commonly
used in prompt injection attacks.

To proceed anyway (not recommended):
 …

Security implications of bypassing:
 - AI agent may execute hidden instructions
 - Bypass attempts are logged for security audit

Built-in rules

Rule ID	Severity	Detects
`invisible-unicode`	error	Zero-width spaces, direction overrides, and other invisible characters
`ignore-instructions`	error	"Ignore previous instructions" and similar phrases
`forget-instructions`	error	Attempts to clear the AI's memory or context
`new-role`	error	"You are now a…", "act as…", "pretend to be…"
`system-tag`	error	System markers such as `system:`, `<system>`, `[SYSTEM]`
`delimiter-injection`	error	LLM prompt delimiters such as `### SYSTEM` or `<
`jailbreak-attempt`	error	Known jailbreak phrases
`role-override`	error	"Your new role…", "from now on you…"
`rm-recursive`	warn	`rm -rf` commands
`format-drive`	warn	Disk format commands (`format c:`, `mkfs`)
`drop-table`	warn	SQL `DROP TABLE`, `DROP DATABASE`, `DROP SCHEMA`
`delete-sql-no-where`	warn	SQL `DELETE FROM` without `WHERE`
`git-force-push`	warn	`git push --force`
`curl-pipe-bash`	error	Downloads piped to a shell (`curl … \| sh`)
`chmod-777`	warn	`chmod 777`
`base64-payload`	warn	Long base64-like strings that may hide instructions

Handle false positives

Legitimate content can trigger detection, for example security documentation, training material, or code examples with shell commands.

Bypass the check for one run

bash

frg issue draft --bypass-safety-checks

The help text for --bypass-safety-checks says:

WARNING: This flag should only be used when you have manually verified the input is safe. Bypassed attempts are logged for security audit.

Add allowlist entries

Export the built-in configuration:

bash

frg config export --security

This creates .forge/config/.prompt-safety.toml with the built-in rules and the default allowlist.

Add entries to the [allowlist] section:

toml

[allowlist]
# Content containing these exact strings is allowed
strings = [
"example: rm -rf in documentation",
]

# If a regex matches, detection is skipped
regexes = [
"```[\\s\\S]*?```",
]

# Paths to exclude from validation
paths = [
".forge/prompts/examples/",
"test/fixtures/",
"docs/security-training/",
]

Validate the configuration:

bash

frg config validate

Keep allowlist entries specific. A broad regular expression can hide a real attack.

Lower a rule's severity

In the exported file, change a rule's severity from "error" to "warn" so matches are logged but don't block the command.

Configuration reference

File: .forge/config/.prompt-safety.toml. If the file doesn't exist or can't be loaded, Forge uses the built-in defaults.

Key	Description	Default
`schema_version`	Configuration schema version.	`"1.0.0"`
`[settings]` `enabled`	Turns prompt safety validation on or off.	`true`
`[settings]` `default_severity`	Severity for rules that don't set one: `"error"` or `"warn"`.	`"error"`
`[[rules]]` `id`	Unique rule identifier.	—
`[[rules]]` `name`	Human-readable name.	—
`[[rules]]` `description`	What the rule detects.	—
`[[rules]]` `pattern`	Regular expression to match. Use `(?i)` for case-insensitive matching.	—
`[[rules]]` `severity`	`"error"` blocks the command; `"warn"` logs and continues.	`default_severity`
`[[rules]]` `tags`	Category labels, for example `["injection", "override"]`.	—
`[allowlist]` `strings`	Exact strings to allow.	`[]`
`[allowlist]` `regexes`	Regular expressions; if one matches, detection is skipped.	Markdown code fences
`[allowlist]` `paths`	Paths to exclude from validation.	`.forge/prompts/examples/`, `test/fixtures/`

In TOML basic strings ("…"), escape backslashes in patterns, for example "\\s+".

Custom rule example:

toml

[[rules]]
id = "internal-override"
name = "Internal Override Phrase"
description = "Detects the phrase our red team uses in injection tests"
pattern = "(?i)disregard\\s+the\\s+ticket\\s+above"
severity = "error"
tags = ["injection", "override"]

Review detections

Forge writes a log entry for each detection, including whether it was blocked (Prompt injection detected and BLOCKED) or bypassed (Prompt injection detected but BYPASSED by user). Review bypass events regularly.