Domain 3 of 6 · Chapter 2 of 2

Implement guardrails and human-in-the-loop workflows

Unlock the complete study guide.

Bundled into the existing Developing in Agentic AI Systems premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • Four jobs a control can do: limit, block, gate, record
  • Where Copilot cloud agent's authority ends
  • Making the boundary enforceable at merge time
  • Choosing which tools an agent can even see
  • Controlling what the agent's execution environment holds
  • Limiting outbound traffic from cloud agent
  • Data-disclosure controls beyond the firewall
  • Permission rules in Copilot CLI
  • Built-in protections in Copilot CLI's shell and fetch tools
  • Hooks as policy: enforcement, and how it fails
  • Approval surfaces in VS Code
  • Limiting what a VS Code agent can reach
  • Environments: the human gate for production
  • Reading a guardrail scenario under exam conditions

What each control does, where it is configured, and where its scope ends

ControlJobWhere it is configuredWhat it actually stopsWhat it does not stop
Copilot instructions fileNone: describes a limit`.github/copilot-instructions.md` in the repositoryNothing: it supplies no enforced merge-time approval boundary and binds no other contributorThe agent, a hurried human, or any other contributor making the change; it only steers work that will be reviewed anyway
CODEOWNERS + Require review from Code OwnersGateCODEOWNERS file plus a rulesetMerging a change to a claimed path without a designated owner's approvalThe change being proposed, and any path not claimed by an owner entry
Ruleset requiring code scanning / Code Quality resultsBlockRepository rulesetsMerging without the required security or quality results presentExecution during the run; the results arrive after the code exists
Custom-agent `tools` listLimitCustom agent configurationThe agent choosing a tool that is not on the list (empty list disables tools)Anything when omitted or set to `["*"]`, which enables all available tools
Copilot CLI `--deny-tool`BlockCLI invocation / permission rulesThe matching call, taking precedence over `--allow-tool` and even `--allow-all`Targets outside the literal pattern — `write(PATH)` supports no globs
`preToolUse` hook returning denyBlockHook files (CLI and cloud agent) or `settings.json` (CLI only)The tool call, before any side effect, with a stated decision reasonAnything when the hook times out, or when an HTTP endpoint is unreachable — both fall through
`postToolUse` hookRecordSame hook sourcesNothing: it runs after a successful operationThe destructive command it was added to catch
Policy hooks (machine-wide)BlockMachine-wide CLI policy locationA denied tool call, with no opt-out through `disableAllHooks` from ordinary hook sourcesAnything in Copilot cloud agent, which does not support policy hooks
VS Code tool selection (Configure Tools)LimitEditor settingsThe agent choosing a capability that is not enabledExecution of an enabled tool, which approval settings govern separately
`chat.tools.terminal.autoApprove` `false` entryGateEditor settingsSilent automatic execution of the matching commandThe command itself — a human can approve it; parsing is best-effort, not a security boundary
`chat.tools.edits.autoApprove` glob set to falseGateEditor settingsA matching sensitive-file edit being applied before someone approves itEdits to paths no glob matches
`chat.agent.networkFilter` denied domainsLimitEditor settingsAgent fetch and browser access to denied domains; denials beat the allow listActions performed on an allowed API domain — allowing is not read-only
Cloud-agent firewall URL / domain ruleLimitCloud agent firewall configurationEgress from processes started by the agent's Bash tool in the Actions applianceMCP servers, configured setup steps, and processes outside that appliance
Agents secrets vs Actions secretsLimitRepository or organization secret storesCloud agent reading Actions secrets and variables at allMisuse of a value deliberately placed in the Agents store
Environment required reviewers (+ Prevent self-review)GateActions environment protection rulesThe targeting job starting, and the initiator approving their own deploymentDeployment by an administrator, unless bypassing protection rules is disallowed
Environment deployment branch restrictionsBlockActions environment protection rulesRuns from ineligible branches or tags deploying to the environmentAn eligible branch carrying an unwanted change — that is what reviewers are for
Verified agent commits and linked session logsRecordAutomatic on cloud-agent commitsNothing; it establishes origin, integrity and an auditable execution recordAn incorrect or unsafe change — provenance is not review

Decision tree

What must this control achieve?Name the outcome before naming a feature Make it impossiblelimit or block Require a human decisiongate Explain it afterwardsrecord Where does the action happen?match the surface, not the wording Is a human present in-session?cloud agent turns ask into deny Session logs, verified commits,and telemetry records A change that lands in the repoRuleset requiring code scanningor Code Quality results A tool call during a runRemove it from the tools list,or deny it (deny beats allow) Data leaving the boundaryFirewall URL rule, network filter,Agents vs Actions secret store no (cloud) yes (e.g. VS Code) Required review (CODEOWNERS +owner review) or a protectedenvironment with reviewers andPrevent self-review; disallowadministrator bypass Tool confirmation: edit theparameters before Allow; gatesensitive edits before they apply WarningA record prevents nothing; neveranswer a prevention need with it Then check the scope of whatever you choseFirewall misses MCP servers and setup steps. Sandbox misses built-in file tools.Content exclusion misses editor Edit and Agent modes. Hook timeouts fail open.A false auto-approve entry asks; it does not forbid. Prefer the narrowest fitone MCP tool over a server,a URL rule over a domain rule,read-only over read/write
Cheat sheet

Cheat sheet

  • Hidden issue or comment text is filtered before reaching the cloud agent.
  • Only repository writers can direct cloud-agent work by hand
  • Cloud-agent write authority is scoped to its working branch
  • Cloud-agent pull requests retain a human merge boundary
  • Delegating a pull request does not evade separation of duties
  • Unattributed cloud-agent pull requests can require an additional approval
  • Approving workflow execution is separate from approving a merge
  • Combine CODEOWNERS with required owner review for sensitive configuration
  • An explicit tools list narrows custom-agent capabilities
  • Select an individual MCP tool rather than an entire server
  • The execute tool alias grants command execution
  • Subagent delegation is itself a capability to scope
  • The built-in GitHub MCP server does not imply enterprise-wide authority
  • The built-in Playwright MCP server is scoped to localhost
  • Use the secret store that matches the intended trust boundary
  • Setup-workflow token permissions and cloud-session credentials are separate
  • Use fresh execution environments for cloud-agent work
  • Organization runner policy can constrain cloud-agent execution placement
  • Keep sensitive MCP inputs in the secure credentials store
  • Explicit CLI denials take precedence over broad permissions
  • CLI MCP permission patterns can target one tool
  • A path-scoped write denial leaves unrelated writes available
  • Match a permission rule to the capability being constrained
  • Read-looking commands can become dangerous through environment overrides
  • Use preToolUse for policy enforcement before a tool runs
  • An ask decision requires an interactive approval path
  • Leave routine actions to normal permissions when policy does not match
  • Any preToolUse denial blocks the tool across matching hooks
  • Policy hooks cannot be disabled by ordinary hook opt-out
  • Use the hook event supported by the execution surface
  • Command-hook errors fail closed for preToolUse
  • A timed-out hook falls through to normal permission processing
  • HTTP hook failures do not automatically deny a tool call
  • Emit one parseable final decision object from a hook
  • Configuration validity determines whether your hook files load at all
  • Enabling a tool does not approve its execution
  • Review the exact tool inputs at the approval boundary
  • A false terminal auto-approval rule requests review rather than forbidding execution
  • Automatic terminal approval must cover every subcommand
  • Protect sensitive files before edits are applied
  • Manage individual grants instead of resetting all trusted operations unnecessarily
  • An environment gate applies to jobs that target that environment
  • Protected environment secrets are released only after the gate passes
  • Restrict which branches and tags are eligible to deploy
  • Automate validation and gate the consequential promotion step
  • Define the evidence a deployment reviewer must evaluate
  • Review an untrusted workspace before enabling its agents
  • Changed MCP configuration requires renewed trust
  • Trusted Domains does not approve incoming user-generated content
  • Pre-approve a trusted endpoint without automatically trusting its responses
  • Network-domain denials take precedence over allowed domains
  • Allowing a domain does not restrict the operations performed there
  • Cloud-agent internet restrictions reduce information-leakage exposure
  • Verified agent commits establish provenance rather than technical correctness
  • Use the session evidence linked from an agent-authored commit
  • Treat full telemetry content capture as a data-disclosure decision
  • Require security results through repository rules rather than agent discretion
  • Permission-deciding HTTP hooks require encrypted transport
  • The location of disableAllHooks determines which hooks it disables
  • Best-effort command parsing cannot enforce complete terminal isolation
  • Grant external reference-folder access without granting external writes
  • Copilot CLI web_fetch accepts web protocols rather than local-file URLs
  • A hostname does not bypass web_fetch private-address protections
  • Redirects are revalidated rather than inheriting unrestricted trust
  • Terminal sandbox restrictions follow child processes, not built-in file tools
  • Confine a local MCP server with explicit filesystem and network grants
  • Do not treat an untrusted MCP tool's behavior description as authorization
  • Match cloud-agent firewall protection to the process launch path
  • Use a URL allowlist rule when only one dependency path needs access
  • Apply content exclusion policies to sensitive-file context in Copilot app and CLI
  • Configure required reviewers and prevent self-review for independent deployment approval
  • Disallow administrator bypass when deployment protection must remain mandatory
  • Enforce the telemetry destination and lock content-capture policy centrally
  • Reassess tool permissions before accepting automation events from users without write access

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in