What Belongs in an AI Approval Gate

An AI approval gate is the named, repeatable control that decides which AI-generated actions leave the building. It is not "human in the loop" as a vibe. It is six specific building blocks, with default decisions defined up front and a log entry every time it fires.

Short answer

An AI approval gate is a named checkpoint in a workflow that decides whether a specific AI-generated action should go out, be applied, be sent, or be committed. The gate has six building blocks. A trigger that says when it fires. An artifact the reviewer actually looks at. Criteria the reviewer checks. A named approver with a backup. A default decision when criteria are missing or the approver does not respond. A log entry every time the gate runs. The default decision is usually block, request more info, or escalate. Approve on silence is rarely the right default. The gate is the visible part of the team's stance on AI output liability. It is not a legal certification, but it is the operating surface where the company's policy, the security policy, and the customer's trust actually meet the AI output.

The problem with "human in the loop"

Most AI governance decks have a slide that says "human in the loop."

That sentence does not say who is in the loop, what they are looking at, what they are checking, what happens if they do not respond, or what gets logged. It does not say what the artifact is, what the criteria are, or how the team improves the loop over time.

The result is the worst kind of governance. The team believes it has a control. The reviewer believes the AI is the reviewer. The customer believes the company said it.

OWASP's GenAI Security Project puts the same point more sharply. LLM06:2025 Excessive Agency lists "Require user approval" as one of its eight preventions and adds that the approval routine should live in the downstream system or in the LLM extension that performs the action, not in the model's reasoning. The point is that authorization belongs to the system of record, not to the model.

A gate is the operational form of that prevention.

The six building blocks

1. Trigger

What causes the gate to fire. A clear trigger is the difference between a gate that runs and a gate that does not. Common GTM triggers:

• An AI agent is about to send a customer email.
• A campaign with AI-generated personalization is about to be scheduled.
• A sales engineer is about to send a security questionnaire answer to a prospect.
• A support AI is about to send a message that mentions money, contract, or escalation language.
• An RFP response draft is about to be sent to a prospect.
• A CRM record is about to be updated by an agent based on inferred information.

If the trigger is not specific, the gate will be skipped. "Review before sending" is a slogan. "Review before any external email sent by the AI agent" is a trigger.

2. Artifact

What the reviewer actually looks at. Not the raw prompt, not the chain of thought, not the full chat history. The artifact is the labeled payload that is about to leave the company.

For an outbound email, the artifact is the recipient, the subject, the body, the personalization inputs, and the source labels for any factual claim. For a CRM update, it is the field, the old value, the new value, the supporting record, and the reason for the change. For an RFP response, it is the question, the answer, the approved source for the answer, and the claim traceability.

If the artifact is hard to assemble, the reviewer will skip the review. The artifact should take less than a minute to produce.

3. Criteria

What the reviewer checks. A gate with 30 criteria will not get used. A gate with 5 to 8 criteria, mapped to the actual failure modes the team has seen or can credibly imagine, will.

Examples for an account research brief gate:

• Every factual claim has a source label.
• Personalization is built from approved CRM fields and approved public sources only.
• No inferred business problems about the recipient.
• No claims the reviewer cannot defend in a five-minute conversation.

Examples for a campaign QA gate:

• Consent and suppression fields are present and current.
• Source labels are visible on every claim.
• No blocked language (refund, contract change, legal commitment).
• Test send and tracking are in place.

Two different reviewers should reach the same decision on the same artifact. If they do not, the criteria are not specific enough.

4. Approver

A named human or role. Not "the team." Not "whoever is online." A specific person, with a small list of named backups and an explicit escalation path when the primary approver is unavailable.

The approver should also have the authority to make the call. A junior who has been told to "be careful" is not an approver. The reviewer who can stop a launch is the reviewer who can actually approve a launch.

OWASP's Excessive Agency guidance is explicit on this. The approver should sit in the downstream system, not in the model. In practice, that means the approver is the person who owns the workflow, the campaign, the deal, or the customer outcome, not the person who built the AI skill.

5. Default decision

What the gate does when criteria are missing, when the approver does not respond in time, or when the artifact is ambiguous. The default should be conservative: block, request more info, or escalate.

Approve on silence is rarely the right default. It is the default that turns a gate into a rubber stamp.

A few useful defaults:

• Block when any critical criterion is missing (no source label, no consent field, no named approver).
• Request more info when the artifact is incomplete but the criteria could be met.
• Escalate when the artifact is ambiguous or when the action is high-impact and the approver is unsure.
• Approve only when every criterion is met and the approver is the named one.

The default also tells the team what to optimize for. A conservative default makes the reviewer pick a real reason to approve. A permissive default makes the reviewer pick a real reason to block. The team that wants to ship faster usually wants the second one. The team that wants to ship safe usually wants the first one. Pick the default that matches the company's actual risk posture.

6. Log

What gets recorded each time the gate fires. Date, trigger, approver, decision, time to decide, criteria that almost failed, and the corrective action taken.

A gate that does not log is a gate that cannot improve. The log is the input to the next iteration of the workflow, the audit trail when something goes wrong, and the proof to a customer, a regulator, or a security team that the workflow was followed.

The log should be cheap to write and easy to read. A row in a spreadsheet, a row in a CRM activity log, or a row in the team's workflow tool. The format matters less than the discipline.

A GTM example: the account research brief

Take an account research brief. A BDR or sales engineer uses AI to assemble a research summary, with personalization inputs, before reaching out.

A prompt-only approach: paste the prompt, paste the result, send the email. The reviewer reads the email and decides.

A gate approach: the trigger is "any account research brief that will be used in an outbound email." The artifact is the brief, the source labels, the personalization inputs, and the email draft. The criteria are the four bullets above. The approver is the sales manager or a senior sales engineer. The default is block if any claim is unlabeled, or if personalization uses a non-approved field. The log is a row with the decision and time to decide.

The two approaches produce the same result when the AI is right. They produce very different results when the AI is confidently wrong.

The free public Strategic Account Research Brief Skill Library is a worked example of the gate in this workflow. The criteria are encoded as a reusable skill, the approver is named, and the default decision is conservative.

A GTM example: the security questionnaire answer

Take a security questionnaire. A sales engineer uses AI to draft an answer, with source labels, before sending.

A prompt-only approach: paste the question, paste the answer, send it. The reviewer skims the answer and decides.

A gate approach: the trigger is "any security questionnaire answer that mentions compliance, certification, encryption, or breach." The artifact is the answer, the source (an approved answer library entry, a policy doc, an internal SME), and the claim category. The criteria are: answer is from an approved source, no inferred claims, no invented certifications, no overpromised SLAs. The approver is the named security reviewer. The default is hold until the security reviewer confirms. The log records the decision and the source.

This is the same gate pattern, in a different workflow. The free Security Questionnaire Triage Skill Library is the worked example.

A short note on legal exposure

A confident AI output that reaches a customer is the company's statement. The Air Canada chatbot case (Moffatt v. Air Canada, 2024 BCCRT 149) is the cleanest public example. The British Columbia Civil Resolution Tribunal found that the airline owed a duty of care to keep the chatbot's representations accurate, and that "it should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot."

That is a tribunal decision, not a binding higher-court precedent. It does not mean every AI output is automatically the company's liability. But it does mean that "the AI said it" is not a defense, and that the company is on the hook for what reaches the customer.

A gate is the visible part of the team's stance on that exposure. It does not eliminate the legal risk. It does make the risk auditable, improvable, and defensible in front of a customer, a security review, or a regulator.

If the workflow creates real customer-impact risk, involve legal, privacy, or compliance counsel. A gate is the operating surface where policy meets the AI output. It is not a replacement for the policy.

Where the gate fits in the FORGE methodology

FORGE is the VibeSec framework for turning random AI usage into governed workflows. Six pillars: Baseline, Skills, Agents, Guardrails, Schedule, Capture.

The gate is a Guardrails artifact, but it touches the other five.

• Baseline. The gate exists to make a workflow visible. Without a baseline workflow, the gate is a fiction.
• Skills. The criteria can be encoded as a reusable skill (approved sources, blocked language, default decision). The free public GTM Skill Libraries are the worked examples.
• Agents. The agent is allowed to prepare the artifact. The agent is not the approver. The agent does not have the authority to send, update, or commit. The human approver is the only one with that authority.
• Guardrails. The gate is the named control surface for the workflow.
• Schedule. The gate has a review cadence. Quarterly is a reasonable default for most GTM workflows. Faster when tools or data sources change. Slower when the workflow is stable and the log shows the gate is doing its job.
• Capture. The log entry is the input to the next iteration. Without capture, the gate does not get better.

A practical next step

Pick one repeated GTM workflow where AI output is about to leave the building.

Do not start with the most dangerous one. Start with the one that has visible pain: account research, campaign QA, RFP response, security questionnaire, support reply, mutual action plan update.

Build the smallest useful version of the gate:

1. Name the trigger. "Any outbound email sent by the AI agent."
2. Define the artifact. The email plus the personalization inputs plus the source labels.
3. Pick 5 to 8 criteria. Map them to the failure modes the team has actually seen.
4. Name the approver. With a backup.
5. Set the default decision. Conservative, not permissive.
6. Log every decision.

If the team needs a starting artifact, the free FORGE AI Workflow Starter Kit captures the trigger, artifact, criteria, approver, default decision, and log for the team's first repeated workflow. If the team already has the workflow and needs the gate adapted to its tools, data sources, approvers, and review cadence, the Company-Specific Skill Library Manual is the next step.

A gate is a routine operating control. It is what safe AI adoption looks like in practice.

Sources

• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP: Top 10 for Large Language Model Applications 2025
• NIST: AI Risk Management Framework
• NIST: AI 600-1 Generative AI Profile
• Gardiner Roberts: Moffatt v. Air Canada, 2024 BCCRT 149 - can statements by client-facing AI chatbots bind their owners?
• VibeSec Advisory: Your AI Agent Needs an Action Approval Matrix Before It Gets More Tools
• VibeSec Advisory: Security Questionnaire AI Workflows Need Approved Sources, Not Memory
• VibeSec Advisory: AI Campaign QA Needs Guardrails Before Personalization
• VibeSec Advisory: Prompt Dumps Are Not Skill Libraries