Strategy — Security First

When to use

• The task involves accepting or processing data from outside the program — user requests, uploaded files, external APIs, or queue messages.
• The task touches secrets or sensitive values — API keys, passwords, tokens, or personal data — that must not leak into logs or output.
• The user asks to harden code, review it for security, or choose safe defaults so that mistakes fail closed rather than open.

When NOT to use

• Do not impose full hardening on a one-off local script that never accepts external data and never runs in a shared or exposed environment.
• Do not add boundary validation and escaping to values that are computed internally and never derived from outside the trust boundary.

Core guidance

• Escape data for the context it is rendered into — Escape or parameterize data for the exact context it flows into — HTML, SQL, a shell, a URL — using the context-appropriate mechanism rather than a generic one.
• Grant the least privilege that works — Give code and callers the narrowest permissions, scopes, and lifetimes that let them do their job, and deny everything else by default.
• Parameterize instead of concatenating untrusted values — Pass untrusted values as bound parameters to prepared statements and never concatenate them into a query, command, or path string.
• Redact secrets before they reach any sink — Redact or omit secrets and sensitive fields before logging, serializing, or including them in an error message, rather than relying on downstream filtering.
• Validate external data at the boundary — Validate the shape, type, and range of external data at the point it enters the system, and reject anything that does not match before it reaches business logic.

Never

• Never treat data that crossed a system boundary — a request, a file, a queue message, a third-party response — as safe; validate it before use.

Prefer

• Prefer defaults that fail closed — deny by default, escape on output, and reject malformed data — so a missing check errs toward safety rather than exposure.

Avoid

• Avoid writing passwords, tokens, keys, or personal data into logs, error messages, or exception traces, and redact them before any output.

Escalate to user when

• Escalate to the user when the task appears to require relaxing a security control — disabling validation, widening access, or storing a secret in plaintext — and confirm before doing it.

Quick recipe

1. Identify every point where external data enters and every secret or sensitive field the code touches, so you know where to validate and what to redact. (verify: You can name each entry boundary and each sensitive value the change handles.)
2. Validate each input against an allowlist at its boundary, bind untrusted values as parameters, escape for the output context, and redact secrets before any sink. (verify: Every external value is validated before use, no untrusted value is concatenated into code, and no secret reaches a log or error message unredacted.)

Anti-patterns

See references/anti-patterns.md.

Common mistakes

1. Relying on a blocklist of bad values — Filtering out a fixed list of known-bad strings or characters lets any unlisted variant through. Fix: Validate against an allowlist of what is permitted, and escape or parameterize for the target context instead of stripping bad input.
2. Secrets leaking through exception traces — Passing a secret as a function argument can leak it into an exception stack trace or debug dump when that function throws. Fix: Wrap secrets in an opaque value object whose string form is redacted, and never interpolate a raw secret into an error message.
3. Validating after the value has already been used — Validating external data only after it has already been used in a query, path, or command leaves the dangerous operation exposed. Fix: Validate at the boundary before the value is used anywhere, and reject invalid data before any downstream operation runs.

Version notes

• Security-first discipline is version-agnostic (PHP >=7.4) — Treating external data as hostile and choosing safe defaults is a strategy that applies to any PHP version; it constrains how the agent reasons about trust, not which language features it uses, so it holds from PHP 7.4 upward.

Security

• Not applicable — no I/O, auth, or untrusted input.

Testing

• Activation and decision behavior are verified in eval/scenarios/ai-rules/strategy-security-first.yaml.

Additional resources

• references/anti-patterns.md
• references/examples.md
• references/pitfalls.md
• references/recipes.md
• references/version-differences.md

Knowledge graph

Related: ai-rules/strategy-minimal-diff, security/sql-injection-prevention