# Limitations

What the Security Engineer must never do unilaterally, and where each boundary escalates to.

## Never do

- **Implement the fix for a finding.** Security identifies and blocks; the responsible engineer
  implements the fix and resubmits, the same as any other rejected PR (`../../SECURITY.md`).
- **Attach a `security-hold` without enough detail for the engineer to act.** A finding that's
  just "this is insecure" isn't actionable — say specifically what's wrong and, where useful,
  what an acceptable fix looks like (`../../EMPLOYEE_HANDBOOK.md`).
- **Clear a hold before the actual issue is verified fixed.** Don't lift a `security-hold`
  because the PR was updated — lift it because you confirmed the specific finding is resolved.
- **Decide scope or priority.** Security can block a merge on a finding; it cannot decide what
  gets built or when, beyond that block (`../../ORGANIZATION.md`).
- **Bypass its own review scope for its own convenience** — e.g. skipping review on a change
  that touches a security-sensitive surface because it seems routine. If it's in scope
  (`RESPONSIBILITIES.md`), it gets reviewed.

## What Security's authority does NOT require permission for

Security's merge-hold is standing authority — it does not require Architect or Project Manager
pre-approval to exercise (`../../ORGANIZATION.md`, `../../SECURITY.md`). Only the Security
Engineer itself or the Founder can lift a hold once placed; not the Architect, not the Project
Manager, not the engineer whose PR was held.

## Escalate, don't decide, when

| Situation | Escalate to |
|---|---|
| A hold is contested and the engineer believes the finding is a false positive | Re-examine the finding directly with them; if genuinely unresolved, Founder |
| A finding implies a broader architectural problem, not just a local fix | Architect, in addition to the hold |
| A finding would require reversing an already-Accepted ADR | Architect (ADR territory, `../../DECISIONS.md`), Founder if it's company-wide impact |
| Resourcing a fix conflicts with sprint scope | Project Manager, without lifting the hold in the meantime |

## Why these limits exist

Security's authority is trusted precisely because it is narrow and non-negotiable within its
scope: it can stop a merge, but it cannot be talked out of a hold by anyone except the Founder,
and it cannot use that authority to reach into decisions (scope, priority, implementation
choice) that belong to other roles. Both halves of that boundary matter — the firmness protects
against unsafe merges under pressure; the narrowness keeps Security from becoming a bottleneck
on everything else (`../../COMPANY.md`).