# An AI guardrails checklist for release review

Canonical: https://aiguardrails.dev/guides/ai-guardrails-checklist/
By AI Guardrails. Reviewed 2026-11-09.

Use this AI guardrails checklist to review one workflow before release. Name the workflow and the version under review. For each item, record evidence, an owner and a result: pass, fail, not tested or not applicable. A checked box without evidence is difficult for the next person to verify.

This is a practical release worksheet. It does not certify security or replace a review of the application's particular risks. A public writing assistant and an agent that can change production systems need different controls.

## Describe what the workflow can reach

Use the [LLM security map](https://aiguardrails.dev/guides/llm-security/) to record the model, data sources, tool services and output destinations. Include background jobs, stored memory and logs. Mark where data or instructions arrive from people or systems you do not control.

Record these workflow details:

- The user's task and the expected result.
- The data sources the application may read.
- The permitted actions and their targets.
- The outcomes that must be prevented.
- The team that owns the policy and handles failures.

Keep the prohibited outcomes observable. "Do not disclose another account's records" is testable. "Act responsibly" leaves the reviewer guessing what evidence would satisfy the requirement.

The [OWASP agent security guidance](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) covers tool security, memory, human review and testing. Use those areas to check whether your workflow map has omitted a path.

## Verify data and output controls

| Review item                                     | Evidence to attach                                     |
| ----------------------------------------------- | ------------------------------------------------------ |
| Retrieval respects the current user's access    | Allowed and denied record-access tests                 |
| Only necessary data reaches the model           | Example outbound payload with synthetic data           |
| Personal data handling covers every destination | Redaction tests for output, tools and logs             |
| Structured results match the expected contract  | Schema tests, including extra and missing fields       |
| Text is safe to render in the interface         | Output-handling tests for the actual renderer          |
| Sources support claims that need evidence       | Reviewed answer examples with their retrieved material |

Inspect a full request trace using synthetic values. A private field can be absent from the visible answer yet remain in an intermediate tool result or diagnostic export.

If a control does not apply, explain why. A workflow with no tools can mark action approval as not applicable. Record that assumption so adding a tool later triggers a new review.

## Verify action authority separately

List each operation the agent can invoke and its target scope. Confirm that the execution service checks permission using trusted identity and resource state. Test a direct call that bypasses the chat interface.

For approval-required actions, retain an example showing the proposed operation, reviewer decision and executed values. Confirm that changed arguments, expired approvals and a different target cannot reuse the old decision.

[OWASP's authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends checking permissions on every request. Include queued actions and retries in your evidence, because they may run after the initial session's state has changed.

Review repeated effects too. Record limits for tool calls, elapsed time or resource use where the workflow needs them. Show how a person can stop future actions and how an already running action is reported.

## Require outage and recovery evidence

Disconnect a guardrail dependency in a test environment. Show what the user sees and verify whether the protected system received a request. Repeat with a malformed decision and an approval that expires while waiting.

Test the return to service. A queue should not silently release obsolete actions after a long outage. Record which requests need fresh evaluation or a new user decision.

Keep denied actions, evaluation failures and unknown execution outcomes distinct in monitoring. [OWASP's logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) recommends useful security events while limiting sensitive data in the log. A complete raw transcript is rarely necessary to prove that a particular action was denied.

## Close the review with a specific release decision

Use a small record that the next reviewer can reproduce:

| Field     | What to record                                    |
| --------- | ------------------------------------------------- |
| Candidate | Application, model and policy versions            |
| Scope     | Workflow, tools and environments covered          |
| Evidence  | Test run identifiers and reviewed examples        |
| Gaps      | Failed or untested cases and their affected paths |
| Owner     | Person responsible for the release decision       |
| Follow-up | Trigger for the next review                       |

Define release conditions before looking at the [guardrail test results](https://aiguardrails.dev/guides/ai-guardrails-testing/). A failed authorization test should not disappear into an average score for helpful answers.

Review again when the workflow gains a data source, tool, permission or output destination. Keep previous records so a later incident can be traced to the configuration that actually ran, rather than the checklist someone most recently edited.

## Source documents
- [OWASP AI agent security cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html)
- [OWASP authorization cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [OWASP logging cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)