Pre-Tool Risk Gates for Agentic AI

Amazon Bedrock Guardrails meets GitHub Copilot policy and the refuse-or-proceed verdict in production agents.

§ IFrame

Today's Ops lesson named the small machine that sits between a strategy's intent and an executor's first slice send: the pre-trade risk gate, three numbers and one verdict. Today's Dev lesson named the Rust type-system idiom that makes the gate's invariants compile-time-checked. This lesson runs the same architecture through a different cohort of consumers — agentic AI systems on Amazon Bedrock and GitHub Copilot, where the gate sits between an agent's next tool call and the tool's actual invocation. The Ops gate asks: is this intent safe to forward to the venue. The agentic gate asks: is this tool call safe to forward to the production system. The two questions share a verdict shape — proceed, proceed-with-clip, refuse — and a discipline: every refusal carries structured reasons; every approval is logged with attribution; the consumer cannot silently miss a new terminal code.

The cert-prep frame here is dual. AIP-C01 (AWS Certified AI Practitioner) covers Bedrock Guardrails as a production-AI safety surface. GH-600 (GitHub Copilot certification, agent track) covers Copilot's policy and content-exclusion controls. Both certs touch the same architecture from different vendor angles; this lesson treats the architecture once and pivots between the two vendors' implementations.

§ IIDomain Foundations — Pre-Tool Risk Gates as Shared Substrate

A production agent is a program that emits structured tool calls — an action name plus an argument dictionary — and consumes the tool's results before emitting the next call. The agent's edge over a no-tool LLM is the tool calls; the agent's risk over a no-tool LLM is the same tool calls. A pre-tool risk gate sits between the agent's emitted call and the tool's runtime, and asks four questions on every call.

First, is the tool the agent named one the agent is authorized to invoke at all. The authorized set is not the union of all tools wired into the runtime; it is the subset the agent's owner has explicitly granted to this agent in this context. A code-review agent is granted read_repository_file and post_review_comment; it is not granted force_push_main_branch, even if the underlying tool exists and could be wired.

Second, are the arguments the agent passed conformant to the schema, in range for the policy, and free of injection. A post_review_comment whose body contains a base64-encoded credential exfiltration string is schema-conformant and policy-failing. A write_to_s3 whose key path traverses outside the allowed prefix is schema-conformant and policy-failing. The argument check is not just JSON-schema validation; it is policy validation against a deny-list and an allow-list specific to the agent's role.

Third, is the call within the rate, cost, and side-effect budgets the operator allocated to this session. An agent that has consumed ninety percent of its session token budget cannot continue a generation loop indefinitely; an agent that has already written nineteen files to S3 should not write a twentieth without operator surface; an agent that has invoked a paid external API forty times should not invoke a forty-first when its session cap is forty.

Fourth, does the call's intended effect conform to the explicit human-in-the-loop boundary. Some tools require human approval before invocation regardless of context; the gate must surface the approval request, suspend the agent, and resume only on approval signal. The boundary is the most important verdict the gate emits because it is the boundary the agent cannot reason past.

The four questions compose the pre-tool gate's verdict. Like the pre-trade gate's verdict, it is one of three terminal codes — proceed, proceed-with-clip (argument sanitization or budget reduction), refuse — plus a fourth structurally distinct: pause-for-approval. The fourth is the agentic-AI-specific addition. The pre-trade gate has no analog because a trading executor never asks a human for approval mid-intent; an agent on a code review or production data write does.

§ IIICert-A Flavor — Amazon Bedrock Guardrails and Agent Tool-Use Approval

AIP-C01's coverage of Bedrock Guardrails spans five filter classes and one orchestration construct. The five filters are content filters (sexual, violence, insults, misconduct), denied-topics (operator-named topic specifications the model must refuse), word filters (block-list and profanity), sensitive-information filters (PII detection and redaction), and contextual grounding checks (response must be supported by the supplied context above a configurable threshold). Each filter applies on both the input prompt and the output response, with configurable strength levels and structured violation records the operator can read in the audit log.

For the cert exam, the operator should know: Guardrails are a separate Bedrock resource, not a per-model setting; they are invoked via the ApplyGuardrail API or via attachment to an InvokeModel / Converse call; they emit GuardrailTrace records that include the violation category, the matched filter, and the redacted output; pricing is per Guardrail invocation and per filtered topic, distinct from model inference pricing. On the exam, a question about a customer wanting to prevent specific topics from being discussed maps to denied-topics; a question about preventing PII leakage maps to sensitive-information filters; a question about preventing hallucinated assertions on a RAG corpus maps to contextual grounding checks.

The orchestration construct is Bedrock Agent Tool-Use with approval gates. Bedrock Agents declare their tools through an Action Group schema (OpenAPI specifications); each action can be marked requireConfirmation: ENABLED, which causes the agent runtime to suspend the agent's reasoning loop, surface the action and its arguments to the calling application, and only resume on approval. The pattern is the production-grade implementation of the fourth question — pause-for-approval — directly in the Bedrock runtime.

For the exam: when an agent's reasoning loop is paused for approval, the application receives a returnControl event in the agent response; it must invoke the agent again with the approval signal and the resumed-execution token; the agent then either continues with the approved tool call or branches based on the denial.

§ IVCert-B Flavor — GitHub Copilot Policy and Content Exclusions

GH-600's coverage of agentic Copilot spans the same architecture from the IDE-and-CLI side. Copilot's policy surface has three layers. The first is the organization-level content-exclusion policy — administrators declare path globs (src/secrets/**, config/production/*.env) that Copilot will not read for context and will not suggest completions inside; the policy is enforced at the IDE-extension boundary and the API-key boundary. The second is the Copilot Workspace / agent-mode allowlist — the set of repositories and actions the agent is permitted to take when operating in autonomous agent mode (file edits, branch creation, pull-request opening, comment posting); allowlisted actions can be further narrowed to require human review before commit-push. The third is the Copilot Chat policy — what Copilot can answer about, governed by organization-level content policies and the same denied-topics architecture as Bedrock.

For the exam, the operator should know: content exclusions are configured per-repository or organization-wide in Copilot administration settings; they appear to Copilot as an empty context for the excluded paths (Copilot does not "see" the file content), not as a refusal post-hoc; allowlisted agent actions are recorded in the audit log with the actor (the human invoking the agent), the agent identity, the action taken, and the result; Copilot Workspace's autonomous mode emits structured task records with the agent's reasoning chain, every tool call, and every refusal.

A subtle exam point: Copilot's content-exclusion policy applies at the context-assembly boundary, not the inference boundary. A developer who pastes an excluded file's contents into the chat manually has supplied that content; Copilot's policy does not redact what the user explicitly types. The exclusion is about automatic context inclusion, not about user-controlled content. This is the same distinction Bedrock Guardrails make between input filtering (applies to the user's prompt) and output filtering (applies to the model's response).

§ VPractice Scenario — A Code-Review Agent Through Both Gates

A production agent reviews pull requests in a financial-services repository. The agent is implemented as a Bedrock Agent with three tools (read_pull_request_diff, post_review_comment, request_human_approval) and is invoked from a GitHub Action that runs on each PR event. The agent's reasoning loop produces tool calls; both gates filter them.

Step one: the agent sees a PR diff that contains a file under src/secrets/. The Copilot content-exclusion policy intercepts the context assembly; the agent receives an empty context for that file. The agent reasons over only the non-excluded files and emits a post_review_comment call with the comment body. The Copilot gate passes the call to the Bedrock runtime.

Step two: the comment body, after Bedrock's input-side Guardrails, contains a sentence the contextual-grounding filter flags as below-threshold — the agent has asserted a fact about the function that is not supported by the diff context. Bedrock returns a GuardrailTrace flagging the grounding failure; the gate's verdict is refuse for that comment. The agent reasons again with the grounding feedback and emits a revised comment that is supported by the diff.

Step three: the revised comment is approved by the input-side Guardrails. Bedrock invokes the tool — but the tool is wired to call GitHub's API to post the comment, and the GitHub Action's Copilot policy requires human approval before any code-review comment is posted on this repository's PRs. Bedrock's requireConfirmation: ENABLED flag on post_review_comment triggers the pause-for-approval verdict. The GitHub Action surfaces the proposed comment to the human reviewer. The reviewer approves. Bedrock resumes; the comment posts.

Step four: every step is recorded — Bedrock's Guardrail trace, the agent's reasoning chain, the pause-for-approval record, the human's approval signal, the resulting comment ID. The audit pipeline lesson from 2026-05-28 named the integrity guarantee that protects this record. The provenance lesson from 2026-06-03 named the supply-chain signature that protects the agent's container image. The pre-tool gate sits inside that protected envelope.

§ VIConnection to Today's Ops + Dev Lessons

The Ops gate's three numbers — regime score, catalyst discount, capital-at-risk ceiling — map to the pre-tool gate's four questions — authorized-tool, argument-conformance, budget-residual, human-approval-boundary. The verdict shapes are nearly identical: proceed, proceed-with-clip, refuse; the agentic gate adds pause-for-approval as a fourth. The Rust newtype-and-closed-enum discipline applies symmetrically — a Bedrock action implementation can be written in Rust with each guardrail-violation reason as an enum variant the consumer must exhaustively match, and an ApprovalRequired { intent, approval_request_id } variant for the pause case. The operator who has internalized the pre-trade pattern in the morning ships the pre-tool pattern in the afternoon without architectural retraining.

§ VIIPractice Questions

§ VIIIClosing

The architecture is the architecture. A trading executor that has a pre-trade risk gate and a code-review agent that has a pre-tool risk gate are running the same small machine, parameterized by different domains. The cert exam will ask about the parameterizations — which Bedrock filter handles which class of safety, which Copilot policy controls which boundary, what fields a Guardrail trace emits, when a returnControl event fires — and the operator who has internalized the architecture answers the parameterization questions without re-deriving the architecture from each cert's vocabulary.

The discipline is operational, not theoretical. Every production agent that has caused harm has done so through a tool call the gate should have refused, a budget the gate should have consumed, an approval the gate should have surfaced, or an authorization the gate should have lacked. The cert vocabulary names the controls; the operator's job is to wire them into the runtime before the agent ships, not after the first incident.

Examine well. Reflect on this.