Security acceptance criteria living in a separate document, referenced occasionally but never built into a feature's actual definition of done, tend to get skipped under deadline pressure, since nothing in the team's normal workflow forces a check against them. Building specific, testable security criteria directly into the same acceptance criteria a feature already gets measured against folds security verification into the normal development process instead of treating it as an optional add-on step.
Write criteria that are specific enough to test directly
A criterion like "the feature handles authorization correctly" can't be tested directly, since it never specifies what correct authorization actually looks like for this specific feature. A criterion like "a request from a user without approval permission is rejected when attempting an action above the configured threshold" can be tested directly, with a clear pass or fail outcome. Write every security acceptance criterion at this level of specificity, connecting to the same specificity principle covered in security requirements guidance.
Derive criteria directly from the feature's security requirements
Each specific security requirement written during the requirements stage, covered elsewhere, should translate into one or more specific acceptance criteria verifying that requirement is actually satisfied in the implementation. This direct traceability from requirement to criterion makes sure nothing gets lost between what was specified and what actually gets verified before release, and it makes checking for gaps easy by comparing the requirements list against the acceptance criteria list directly.
Include criteria for the negative case, not only the positive case
For every security control, write acceptance criteria covering both the positive case, the control correctly allows a legitimate action, and the negative case, the control correctly blocks an illegitimate one. Teams verifying only the positive case, confirming the feature works for legitimate use, systematically miss verifying the control actually blocks what it's supposed to block, which is often the more important half of the verification for a security-relevant criterion specifically.
Include criteria for failure and degraded behavior explicitly
Following fail-safe design guidance running throughout this content series, write specific acceptance criteria for degraded conditions: "when the approval service is unavailable, the action is held rather than executed." This criterion category frequently goes missing from acceptance criteria sets focused only on normal operation, and its absence is a common reason fail-safe intentions never actually get verified before release.
Include criteria for logging and traceability
Write specific acceptance criteria confirming required logging actually happens: "every tool call above the approval threshold produces an audit record including identity, decision, and outcome." This turns logging into a verified, testable requirement rather than an assumption it happens correctly just because logging code exists somewhere in the implementation.
Assign clear ownership for verifying each criterion
For every security acceptance criterion, identify who's responsible for verifying it before release, whether through automated testing, a manual review step, or a combination. Criteria with no assigned verifier tend to stay unverified, since ambiguous ownership produces the same gap covered in policy enforcement guidance: a rule that exists with no clear path to confirming it actually holds.
Integrate criteria into the same tracking system as functional requirements
Rather than keeping security acceptance criteria in a separate document from functional acceptance criteria, integrate them into the same tracking system, the same ticket, the same definition of done, so a feature can't get marked complete without addressing both categories together. This integration is what actually changes behavior. A separate security checklist sitting alongside, rather than within, the normal workflow tends to get treated as optional supplementary material instead of a genuine release blocker.
Review and update criteria as the feature evolves
When a feature gains new capability, a new tool, an expanded data source, revisit its security acceptance criteria to add coverage for that new capability, rather than applying the original criteria set indefinitely as the feature outgrows what those criteria were ever designed to cover.
Where TELEON fits
For acceptance criteria specifically covering tool authorization, approval workflows, and audit logging, TELEON's policy enforcement and audit trail, applied through the gateway or supported middleware, provide the implementation that these criteria verify against, once the criteria themselves are written and integrated into the feature's release process.
Writing the specific criteria, deriving them from requirements, and integrating them into the team's actual workflow remains process and engineering work that has to be done directly by the team building each feature.
A short checklist
- Write criteria specific enough to test directly, with a clear pass or
fail outcome.
- Derive criteria directly from the feature's own security requirements.
- Include criteria for both the positive and negative case for every
control.
- Include explicit criteria for degraded and failure conditions.
- Include criteria confirming required logging and traceability actually
occurs.
- Assign clear ownership for verifying each criterion before release.
- Integrate security criteria into the same tracking system as
functional criteria.
- Review and update criteria as a feature's capabilities evolve.
Security acceptance criteria for an AI feature earn real influence when they are specific, testable, and integrated directly into the feature's own definition of done, rather than existing as a separate, easily skipped checklist that competes with the team's actual workflow instead of being part of it.