Audit Copilot Cloud Agent Config with the REST API

GitHub added a public-preview REST API on May 18, 2026 for auditing a repository's Copilot cloud agent configuration. The endpoint matters because Copilot cloud agent is no longer just an editor-side assistant setting. It can inherit repository-level MCP servers, enabled review tools, workflow approval policy, and firewall configuration. Those are exactly the surfaces a security reviewer or platform owner needs to inspect before scaling agent adoption.

This article is a practical audit workflow, not a claim that Effloow accessed a live GitHub organization. Effloow Lab ran a bounded OpenAI API check against a synthetic Copilot cloud agent configuration and saved the public lab note at /lab-runs/github-copilot-cloud-agent-config-audit-api-2026. The model classified broad MCP tool access, disabled dependency checks, disabled Actions workflow approval, write-capable ticketing tools, and wildcard firewall allowlists as items worth reviewing. That is useful as a prompt harness for triage, but it is not a substitute for a real repository API call.

Use this tutorial to build a small audit script, define the fields your reviewers care about, and decide when Copilot cloud agent is ready for a repository versus when it needs narrower permissions.

Primary sources for this guide include GitHub's May 18, 2026 changelog announcement, the Copilot REST API index, the cloud agent repository management endpoint, GitHub's Copilot cloud agent overview, the MCP and Copilot cloud agent guide, the repository MCP configuration docs, the cloud agent firewall docs, and GitHub's enterprise agent management docs.

What You'll Build

You will build a repository-level audit that calls GitHub's Copilot cloud agent configuration endpoint and turns the response into a governance checklist. The current documented endpoint is:

GET /repos/{owner}/{repo}/copilot/cloud-agent/configuration

GitHub's REST documentation for API version 2026-03-10 says the endpoint is in public preview and returns Copilot cloud agent configuration for a repository, including MCP server configuration, enabled review tools, Actions workflow approval settings, and firewall configuration. The same docs list token options and say fine-grained tokens need "Copilot agent settings" repository permission with read access. Classic OAuth app tokens and classic personal access tokens needrepo` scope.

The audit output should answer five questions:

• Which MCP servers can the agent use?
• Are tools explicitly allowlisted or broadly exposed?
• Are CodeQL, Copilot code review, secret scanning, and dependency vulnerability checks enabled?
• Is Actions workflow approval required?
• Is the firewall enabled, and how broad is the custom outbound allowlist?

This is valuable for buyers because it turns "we enabled coding agents" into inspectable policy. If a vendor cannot show the configured tool surface, workflow policy, and network boundary, the agent rollout is not ready for broad adoption.

Prerequisites

You need a GitHub repository where Copilot cloud agent settings are relevant, a token allowed to read the configuration, and a GitHub plan/context where Copilot cloud agent can be enabled. GitHub's Copilot cloud agent docs say the agent is available for paid Copilot plans, while Copilot Business and Enterprise users need an administrator to enable the relevant policy. Repository owners can also opt repositories out.

For a local audit script, install only standard tooling:

bash
mkdir copilot-agent-config-audit
cd copilot-agent-config-audit
touch audit-copilot-agent-config.sh
chmod +x audit-copilot-agent-config.sh


Expected output:

text
audit-copilot-agent-config.sh is executable


You also need a token in your shell. Do not paste it into source control:

bash
export GITHUB_TOKEN="ghp_or_fine_grained_token_here"
export OWNER="your-org"
export REPO="your-repo"


Expected output is intentionally silent. If you print secrets during setup, fix the script before using it with any real repository.

Step 1: Call the Configuration Endpoint

Start with the smallest possible curl command. GitHub recommends Accept: application/vnd.github+json and the X-GitHub-Api-Version header for REST calls.

bash
curl -sS -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/repos/${OWNER}/${REPO}/copilot/cloud-agent/configuration"


Expected success shape, based on GitHub's documented default example:

json
{
"mcp_configuration": null,
"enabled_tools": {
"codeql": true,
"copilot_code_review": true,
"secret_scanning": true,
"dependency_vulnerability_checks": true
},
"require_actions_workflow_approval": true,
"is_firewall_enabled": true,
"is_firewall_recommended_allowlist_enabled": true,
"custom_allowlist": []
}


Expected failure modes include 401 for missing authentication, 403 for insufficient access, 404 when the resource is not visible to the token, and 500 for server-side errors. The endpoint is public preview, so treat the schema as something your script should validate defensively rather than assume forever.

Step 2: Normalize the Fields for Review

The raw JSON is useful, but reviewers need a stable summary. Save the response to a file and extract only the fields that affect governance.

`bash
curl -sS -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/repos/${OWNER}/${REPO}/copilot/cloud-agent/configuration" \

copilot-cloud-agent-config.json

jq '{
has_mcp_configuration: (.mcp_configuration != null),
enabled_tools,
require_actions_workflow_approval,
is_firewall_enabled,
is_firewall_recommended_allowlist_enabled,
custom_allowlist
}' copilot-cloud-agent-config.json
`

Expected output:

json
{
"has_mcp_configuration": true,
"enabled_tools": {
"codeql": true,
"copilot_code_review": true,
"secret_scanning": true,
"dependency_vulnerability_checks": false
},
"require_actions_workflow_approval": false,
"is_firewall_enabled": true,
"is_firewall_recommended_allowlist_enabled": true,
"custom_allowlist": ["api.internal.example"]
}


That sample is illustrative. Do not copy it into an audit report as live evidence. In your own script, the exact values must come from the API response you saved.

Step 3: Audit MCP Tool Scope

GitHub's MCP docs say repository MCP configuration on GitHub applies to both Copilot cloud agent and Copilot code review. The same docs state that once MCP servers are configured for a repository, the specified tools are available to Copilot cloud agent during assigned tasks, and Copilot can use available tools autonomously. That makes MCP scope the first thing to review.

GitHub also documents default MCP servers. The GitHub MCP server is scoped to the source repository by default, and the Playwright MCP server is configured to access local resources in the agent environment by default. Custom MCP servers need more scrutiny because they may connect to ticketing systems, internal APIs, cloud logs, browser tools, or deployment systems.

A simple MCP extraction step:

bash
jq '.mcp_configuration' copilot-cloud-agent-config.json


Questions to ask:

• Does any server use tools: ["*"] when a named tool allowlist would work?
• Does any server expose write-capable tools, such as ticket comments, deployment triggers, issue edits, or database mutations?
• Are secrets passed through the approved Copilot agent secret mechanism rather than hardcoded values?
• Does the server's purpose match the repository's security classification?
• Is the same MCP configuration also acceptable for Copilot code review, since repository settings can apply to both?

Effloow Lab's synthetic OpenAI check flagged tools: ["*"] and a write-capable tickets/comment tool as review items. That is a reasonable triage heuristic, but the severity in a real audit depends on the MCP server implementation, token scope, logging, and business context.

Step 4: Audit Workflow Approval and Security Tools

GitHub's configuration endpoint returns enabled_tools and require_actions_workflow_approval. Those fields should not be treated as decoration. They decide whether the agent is surrounded by review and security controls or operating with a thin safety layer.

Create a local policy file:

json
{
"required_enabled_tools": [
"codeql",
"copilot_code_review",
"secret_scanning",
"dependency_vulnerability_checks"
],
"require_actions_workflow_approval": true
}


Then compare the API response:

`bash
jq -r '
.enabled_tools as $tools |
[
"codeql",
"copilot_code_review",
"secret_scanning",
"dependency_vulnerability_checks"
][] as $name |
"($name)=($tools[$name])"
' copilot-cloud-agent-config.json

jq -r '"require_actions_workflow_approval=(.require_actions_workflow_approval)"' \
copilot-cloud-agent-config.json
`

Expected output in a conservative repository:

text
codeql=true
copilot_code_review=true
secret_scanning=true
dependency_vulnerability_checks=true
require_actions_workflow_approval=true


If dependency vulnerability checks are disabled, document why. If Actions workflow approval is disabled, document which workflows the agent can create or modify, who reviews them, and how failed or suspicious workflow changes are detected. In many organizations, turning this into a binary pass/fail check is appropriate for production repositories.

Step 5: Audit Firewall and Network Allowlist

GitHub's firewall docs say Copilot's internet access is limited by a firewall by default. The docs also warn that disabling the firewall allows Copilot to connect to any host and increases exfiltration risk. The recommended allowlist can permit common package registries, operating system package repositories, container registries, certificate authorities, and browser-download hosts for Playwright MCP.

Extract the network fields:

bash
jq '{
is_firewall_enabled,
is_firewall_recommended_allowlist_enabled,
custom_allowlist
}' copilot-cloud-agent-config.json


Expected conservative result:

json
{
"is_firewall_enabled": true,
"is_firewall_recommended_allowlist_enabled": true,
"custom_allowlist": []
}


Custom allowlists are not automatically bad. A private package registry, internal documentation host, or artifact mirror may be necessary. The audit question is whether the allowlist is minimal and explainable. Prefer exact hostnames over broad wildcards when possible. If a wildcard is needed, record the owner, reason, expiration date, and the data types reachable at that domain.

Step 6: Turn the Response Into a Reviewer Checklist

The audit script should produce a checklist that security, platform, and repository owners can read without parsing raw JSON. A simple scoring model is enough:

text
PASS: firewall enabled
PASS: recommended allowlist enabled
REVIEW: custom allowlist contains wildcard host
FAIL: dependency vulnerability checks disabled
FAIL: Actions workflow approval disabled
REVIEW: MCP server exposes wildcard tools
REVIEW: MCP server exposes write-capable ticketing tool


Effloow Lab's API-backed simulation produced the same kind of classification from a synthetic response. The useful part was not that a model found a novel vulnerability. It was that the model turned machine-readable policy into repository-owner questions:

• What specific GitHub MCP tools are required?
• Can tools: ["*"] be replaced with an explicit allowlist?
• Should ticketing access be read-only?
• How is the MCP token provisioned, scoped, rotated, and revoked?
• Why are dependency vulnerability checks disabled?
• Should Actions workflow approval be required?
• Are custom firewall hosts the minimum required outbound destinations?

That pattern is the buyer-facing artifact: a repeatable audit prompt plus source-backed policy rules. For a customer project, Effloow would replace the synthetic JSON with live API output gathered by the customer's authorized environment.

Common Mistakes

The first mistake is treating Copilot cloud agent as a single on/off switch. GitHub's enterprise management docs separate enterprise policy, organization policy, repository-level configuration, MCP policy, third-party agent policy, and local IDE agent behavior. Disabling or restricting one agent type does not automatically govern every other agent path.

The second mistake is reviewing MCP configuration only for whether it connects. For governance, a successful connection is not enough. You need tool names, write capabilities, token scope, data classification, and audit logs.

The third mistake is allowing broad network access because setup is easier. The firewall exists to reduce data-exfiltration risk. If an agent needs external hosts, the allowlist should explain why those hosts are required.

The fourth mistake is pasting model-generated findings into a compliance report without tying them back to source fields. A model can help summarize. The evidence remains the API response, GitHub's documented behavior, and the repository owner's policy decision.

FAQ

Q: Is GitHub's Copilot cloud agent configuration API generally available?

GitHub's May 18, 2026 changelog and REST docs describe the repository configuration endpoint as public preview. Build audit scripts defensively and pin the REST API version header.

Q: Can this endpoint prove that Copilot cloud agent is safe?

No. It exposes important configuration fields, but it does not prove runtime behavior, prompt quality, MCP server internals, token scope, or whether reviewers will enforce policy. It is one part of a broader governance workflow.

Q: Should every repository require Actions workflow approval?

For sensitive production repositories, requiring approval is the safer default. Some low-risk repositories may choose otherwise, but the decision should be documented because workflow changes can affect CI, deployment, scanning, and supply-chain behavior.

Q: Is tools: ["*"] always wrong for MCP?

Not always. If the server exposes only a tiny, read-only surface, wildcard tools may be acceptable. In most real audits, an explicit tool allowlist is easier to review and safer to explain.

Key Takeaways

GitHub's Copilot cloud agent configuration endpoint gives teams a concrete way to audit repository-level agent settings instead of relying on screenshots or tribal knowledge. Start with the REST response, normalize the fields, and review MCP servers, enabled security tools, workflow approval, and firewall settings as separate controls.

The strongest buyer proof is not a flashy demo. It is an audit artifact that says what the agent can access, which tools it can call, which workflows need approval, which hosts it can reach, and which settings still need owner sign-off. That is how agent adoption moves from experiment to governed rollout.

Bottom Line

Use the Copilot cloud agent configuration API as the first gate in an agent governance review. It will not replace runtime testing, but it exposes the fields a serious buyer should ask about before enabling repository-scale automation.