Skip to content

Latest commit

 

History

History
71 lines (50 loc) · 8.96 KB

File metadata and controls

71 lines (50 loc) · 8.96 KB
title Risks and mitigations for GitHub Copilot cloud agent
shortTitle Risks and mitigations
intro How do {% data variables.copilot.copilot_cloud_agent %}'s built-in security protections mitigate known risks?
versions
feature
copilot
contentType concepts
category
Learn about Copilot
Manage Copilot for a team
Roll Copilot out at scale
redirect_from
/copilot/concepts/agents/coding-agent/risks-and-mitigations

{% data variables.copilot.copilot_cloud_agent %} is an autonomous agent that has access to your code and can push changes to your repository. This entails certain risks.

Where possible, {% data variables.product.github %} has applied appropriate mitigations. This gives {% data variables.copilot.copilot_cloud_agent %} a strong base of built-in security protections that you can supplement by following best practice guidance.

Unvalidated code can introduce vulnerabilities

{% data reusables.copilot.cloud-agent-validation-tools-intro %} {% data variables.copilot.copilot_cloud_agent %}'s security validation does not require a {% data variables.product.prodname_GHAS_cs_or_sp %} license.

  • {% data variables.product.prodname_codeql %} is used to identify code security issues.
  • Newly introduced dependencies are checked against the {% data variables.product.prodname_advisory_database %} for malware advisories, and for any CVSS-rated High or Critical vulnerabilities.
  • {% data variables.product.prodname_secret_scanning_caps %} is used to detect sensitive information such as API keys, tokens, and other secrets.
  • Details about the analysis performed and the actions taken by {% data variables.copilot.copilot_cloud_agent %} can be reviewed in the session log. See AUTOTITLE.

Optionally, you can disable one or more of the code quality and security validation tools used by {% data variables.copilot.copilot_cloud_agent %}. See AUTOTITLE.

{% data variables.copilot.copilot_cloud_agent %} can push code changes to your repository

To mitigate this risk, {% data variables.product.github %}:

  • Limits who can trigger the agent. Only users with write access to the repository can trigger {% data variables.copilot.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. {% data variables.copilot.copilot_cloud_agent %} only has the ability to push to a single branch. When the agent is triggered by mentioning @copilot on an existing pull request, {% data variables.product.prodname_copilot_short %} has write access to the pull request's branch. In other cases, a new copilot/ branch is created for {% data variables.product.prodname_copilot_short %}, and the agent can only push to that branch. The agent is also subject to any branch protections and required checks for the working repository.
  • Limits the agent's credentials. {% data variables.copilot.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 {% data variables.copilot.copilot_cloud_agent %} must be reviewed and merged by a human. {% data variables.copilot.copilot_cloud_agent %} cannot mark its pull requests as "Ready for review" and cannot approve or merge a pull request.
  • Restricts {% data variables.product.prodname_actions %} workflow runs. By default, workflows are not triggered until {% data variables.copilot.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 {% data variables.product.prodname_copilot_short %} to allow workflows to run automatically. See AUTOTITLE.
  • Prevents the user who asked {% data variables.copilot.copilot_cloud_agent %} to create a pull request from approving it. This maintains the expected controls in the "Required approvals" rule and branch protection. See AUTOTITLE.
  • Requires an additional approval when a pull request isn't attributed to a person. When {% data variables.copilot.copilot_cloud_agent %} opens a pull request under its own app identity, one more approval is required before it can be merged, as long as the repository already requires at least one approval. This is enabled by default in rulesets, where administrators can turn it off, and always applies to branch protection rules. See AUTOTITLE.

{% data variables.copilot.copilot_cloud_agent %} has access to sensitive information

{% data variables.copilot.copilot_cloud_agent %} has access to code and other sensitive information, and could leak it, either accidentally or due to malicious user input.

To mitigate this risk, {% data variables.product.github %} restricts {% data variables.copilot.copilot_cloud_agent %}'s access to the internet. See AUTOTITLE.

AI prompts can be vulnerable to injection

Users can include hidden messages in issues assigned to {% data variables.copilot.copilot_cloud_agent %} or comments left for {% data variables.copilot.copilot_cloud_agent %} as a form of prompt injection.

To mitigate this risk, {% data variables.product.github %} filters hidden characters before passing user input to {% data variables.copilot.copilot_cloud_agent %}: For example, text entered as an HTML comment in an issue or pull request comment is not passed to {% data variables.copilot.copilot_cloud_agent %}.

Administrators can lose sight of agents' work

To mitigate this risk, {% data variables.copilot.copilot_cloud_agent %} is designed to be auditable and traceable.

  • {% data variables.copilot.copilot_cloud_agent %}'s commits are authored by {% data variables.product.prodname_copilot_short %}, with the developer who assigned the issue or requested the change to the pull request marked as the co-author. This makes it easier to identify code generated by {% data variables.copilot.copilot_cloud_agent %} and who started the task.
  • {% data variables.copilot.copilot_cloud_agent %}'s commits are signed, so they appear as "Verified" on {% data variables.product.github %}. This provides confidence that the commits were made by {% data variables.copilot.copilot_cloud_agent %} and have not been altered.
  • Session logs and audit log events are available to administrators.
  • The commit message for each agent-authored commit includes a link to the agent session logs, for code review and auditing. See AUTOTITLE.

Automations run without a person initiating each task

{% data variables.copilot.copilot_automations_cap %} run {% data variables.copilot.copilot_cloud_agent %} automatically, on a schedule or in response to events, without a person initiating each task. See AUTOTITLE. This introduces some additional risks, which {% data variables.product.github %} mitigates as follows.

  • Work is attributed to the person who created the automation. Pull requests opened and code pushed by an {% data variables.copilot.copilot_automation %} are attributed to the user who created the {% data variables.copilot.copilot_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 {% data variables.copilot.copilot_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 {% data variables.copilot.copilot_automation %} can use, so it can only take the actions the task requires.
  • Events from untrusted users are ignored by default. {% data variables.copilot.copilot_automations_cap %} 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 {% data variables.copilot.copilot_automation %} could trigger another {% data variables.copilot.copilot_automation %}. As with all {% data variables.copilot.copilot_cloud_agent %} work, {% data variables.product.prodname_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.