Strong Gates for Unattended Paths

The less a path is watched by a human, the more it should be bound by structure. The greatest safety mechanism in a conversation is a human being present, and because that's never written down anywhere, it silently drops away the moment things go unattended.

Problem

While a conversation is happening, a human notices right away if something dangerous occurs. Because they can notice, the gate is allowed to stay thin. But the moment the same agent runs unattended, this premise disappears. No one is watching the screen. No one is there to stop it mid-way. And the trigger condition itself can become someone else's input — an issue comment, an external event payload. Bring the same thin gate from a conversation into an unattended path, and an inversion occurs: the path with the least oversight ends up with the strongest authority.

Context

Applies when:

• Automated runs, scheduled runs, event-triggered paths
• Unattended paths where a change or a PR gets created before human approval
• Paths where someone else's input gets mixed into the trigger condition (an issue comment, an external event payload)

Does not apply when:

• A human is watching every single step of a conversation. Thickening the gate here just doubles the human's own judgment and adds friction

Boundary with neighboring patterns:

• Bounding Permissions by Structure — that pattern deals with execution permission (what can be run), this pattern deals with the approval and merge path (who can approve and merge). There's a junction, though — on an unattended path, "which tools can be used" also gets narrowed (Practice section). One application of that pattern shows up inside this one.
• Diff Review and Incremental Adoption — this pattern deals with the structure of the path; that pattern deals with how the human receives it
• Separating Mechanical Gates from Semantic Gates — that pattern deals with which kind of gate (mechanical or semantic) something lands on; this pattern deals with which path gets a heavier gate
• Failure as Institutional Memory — a failure on an unattended path doesn't stop at an instruction. Instructions are non-deterministic, and there's no human watching either. What stops it is structure

Solution

The thinner the oversight on a path, the stronger the gate needs to be — but intuition often points the other way: "conversation is a hassle so a thin gate is fine; unattended is automation, so it should be free to move." But the thinner the oversight, the fewer levers remain to stop damage other than structure.

Why does this work? The greatest safety mechanism in a conversation is a human being present. This is never written down — no spec says "the safety of this conversation depends on a human's eyes."

Whatever isn't written down, no one notices when it drops away during unattended operation. Designing an unattended path is the work of filling, with explicit structure, the hole left by this implicit mechanism's absence.

There's one more thing: an unattended path adds a danger a conversation doesn't have. The trigger condition becomes someone else's input. On a path triggered by an event, the contents of an issue or a comment can become part of the prompt — meaning an attacker can write the input.

This doesn't happen in a conversation, because the person writing the input is you. So "it was safe in conversation, so it's safe unattended" doesn't hold. It isn't that the amount of danger stays the same while oversight just drops — the kind of danger is increasing too.

The kinds of gates form layers as in the diagram above — who can trigger it, where they can write, what they can execute, who can approve, who can merge. Each additional layer tightens the ceiling on damage one more notch.

Structure works because instructions get forgotten, but structure doesn't. "Don't do anything dangerous" is an instruction, and it only ever works non-deterministically. "This can only push to this one branch" is structure — whether it's kept isn't even a question.

Trade-offs

Advantages

• Even on a path with no oversight, the ceiling on damage is set by structure. It works not as an expectation of "it was supposed to be kept," but as a boundary that can't be crossed in the first place
• Doesn't depend on human attention. Even when a conversation's safety mechanism (a human being present) is gone, structure takes its place

Costs

• Friction increases. Waiting for approval happens, and workflows don't run automatically. The point of going unattended was automation, and the gate stops that very automation. This tension never goes away.
• Settings that loosen the gate are often provided, and the premise collapses the moment they're loosened. The official docs themselves leave room for relaxation, in the form of "off by default, but can be enabled" (Official, source in the Practice section)

GitHub Copilot in Practice

Copilot isn't a single product. What corresponds to this pattern lives mainly in cloud agent. Everything below is about cloud agent specifically, and isn't extended to VS Code or Copilot CLI.

Three categories — product default, repository-setting-derived, and default-but-changeable

Source: Copilot cloud agent risks and mitigations (retrieved 2026-07-16). The source text separates three different origins. Don't lump this together as "Copilot is safe" — the page's own title is "risks and mitigations."

Product default (can't be changed) Official:

• Limits who can trigger the agent. Only users with write access to the repository can trigger Copilot cloud agent to work. Comments from users without write access are never presented to the agent.
• Limits the branch the agent can push to. Copilot cloud agent only has the ability to push to a single branch. ... In other cases, a new copilot/ branch is created for Copilot, and the agent can only push to that branch. ...
• Limits the agent's credentials. Copilot cloud agent can only perform simple push operations. It cannot directly run git push or other Git commands.
• Requires human review before merging. Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human. Copilot cloud agent cannot mark its pull requests as "Ready for review" and cannot approve or merge a pull request.
• Prevents the user who asked Copilot cloud agent to create a pull request from approving it. This maintains the expected controls in the "Required approvals" rule and branch protection.

Derived from repository settings (layered on top) Official:

The agent is also subject to any branch protections and required checks for the working repository.

Default but changeable (can be loosened) Official:

By default, workflows are not triggered until Copilot cloud agent's code is reviewed and a user with write access to the repository clicks the Approve and run workflows button. Optionally, you can configure Copilot to allow workflows to run automatically.

Mapping each line above onto the layers in Solution's diagram:

Layer	Where it appears in the source text
Who can trigger	Only users with write access ... can trigger
Where they can write	only ... push to a single branch (copilot/)
What they can run	cannot directly run git push or other Git commands
Who can approve	cannot mark ... "Ready for review" / user who asked ... from approving
Who can merge	must be reviewed and merged by a human

Automations — the most unattended path of all

The Automations section of the same source lists mitigations for paths where a human doesn't trigger each individual task. This is where this pattern's main battlefield is Official:

• Work is attributed to the person who created the automation. Pull requests opened and code pushed by an automation are attributed to the user who created the automation. As when that user creates a pull request themselves, they can't approve it, which preserves the expected "Required approvals" controls.
• You control which tools an automation can use. When an automation is triggered by an event, input from untrusted users could become part of the prompt. To limit the impact of prompt injection, you choose exactly which tools an automation can use, so it can only take the actions the task requires.
• Events from untrusted users are ignored by default. Automations ignore events triggered by users without write access to the repository by default, with a setting to opt in.
• Workflows still require human approval. An issue or pull request opened by an automation could trigger another automation. ... GitHub Actions workflows don't run on a pull request until a user with write access approves them, which prevents workflows from running automatically as part of such a chain.

"You control which tools an automation can use" is the spot where Bounding Permissions by Structure (narrowing execution permission) shows up inside this pattern. The more unattended the path, the narrower the means of execution itself get pulled in. "Workflows still require human approval" is also a design that stops chaining — because a PR opened by an automation can trigger another automation. Unattended paths can chain, a point that doesn't arise in conversation.

Mitigations for prompt injection are stated explicitly too Official:

To mitigate this risk, GitHub filters hidden characters before passing user input to Copilot cloud agent: For example, text entered as an HTML comment in an issue or pull request comment is not passed to Copilot cloud agent.

Not a gate, but auditability is stated as a design element of unattended paths too Official:

Copilot cloud agent's commits are signed, so they appear as "Verified" on GitHub. This provides confidence that the commits were made by Copilot cloud agent and have not been altered.

What to watch for on review — .github/workflows/

Source: Reviewing Copilot's output (retrieved 2026-07-16) Official:

GitHub Actions workflows can be privileged and have access to sensitive secrets. Inspect the proposed changes in the pull request and ensure that you are comfortable running your workflows on the pull request branch. You should be especially alert to any proposed changes in the .github/workflows/ directory that affect workflow files.

This is directed at the human standing at the who-can-merge layer, warning that unattended output can include a workflow that runs automatically next. The same page also states the means to push back Official:

To request changes from Copilot on its pull request, mention @copilot in a comment, or push commits directly to the branch.

Also Known As

Name	Source
Strong Gates for Unattended Paths	Descriptive — this catalogue's descriptive name; no primary source uses it

Individual gates have established names — branch protection, Required approvals, the Approve and run workflows button (all sourced in the Practice section). What has no name is the design principle itself — varying gate strength with the amount of human oversight. But products implement this principle as a default — the three categories above are a real instance of it. The principle has no name, but its implementation does.

Related

• Separating Mechanical Gates from Semantic Gates — that page draws "which kind of gate something lands on" from the same cloud agent source (CodeQL, Advisory Database, secret scanning, Copilot code review as a second opinion). This pattern draws "the structure of the path" (who can trigger, where they can push, who can merge) from the same source. It's fine for the citations to overlap — the roles differ
• Failure as Institutional Memory — a failure that happens on an unattended path doesn't stop at an instruction. What stops it is structure
• Bounding Permissions by Structure — execution permission is that pattern, the approval and merge path is this pattern. "Which tools can be used" is the junction point that shows up inside an unattended path's gate (Practice section)
• Diff Review and Incremental Adoption — the structure of the path is this pattern, how the human receives it is that pattern
• If reading just one more next: Bounding Permissions by Structure — next is implementing an unattended path's gate through the structure of permissions