magnus919_agent-skills/secure-software-engineering/templates/security-acceptance-criteria.md

Security Acceptance Criteria

Confidentiality: Completed criteria can describe security boundaries. Keep them within the project's appropriate access controls.

When To Use

Use while writing a feature specification, design decision, or pull request description. Replace prompts with observable, feature-specific criteria and direct evidence.

When Not To Use

Do not treat unchecked items or headings as semantic validation. Use verification-methodology to assess evidence and record a verdict.

Scope And Threat Model Link

• Feature or change:
• Assets and trust boundaries affected:
• Security owner and review date: <owner/date>

Authentication And Authorization

• Identity is verified at using ; evidence: <test/configuration>.
• Server-side authorization permits to perform on only under ; denied cases tested: .
• Object and tenant checks cover direct, bulk, asynchronous, and tool-mediated paths: .

Input, Output, And Data

• Inputs from have schemas, limits, and rejection behavior: .
• Outputs for are encoded or constrained appropriately: .
• Data classification, retention, export, and deletion decision: <decision/evidence>.

Secrets And Dependencies

• New or changed secret material has owner, scope, storage, revocation, and event/risk-driven rotation plan: .
• Dependencies, models, plugins, and build inputs have version, origin, affectedness, and update decision: .

Logging And Release

• Security-relevant events logged: ; excluded or redacted data: ; access and retention: .
• Release evidence includes <SBOM/provenance/tests/approvals>; limitations and exceptions: <limits/owner>.
• Rollback and response path: <path/owner>.

AI-Specific Boundaries (If Applicable)

• Prompts, retrieved content, and tool output are treated as untrusted: .
• Every tool action is authorized server-side and constrained to <capability/data scope>: .
• Material or irreversible actions require <approval/policy>: .