Governing GitHub Copilot with Alyria
GitHub Copilot enterprise security is built on its managed settings and AI controls: an MCP allowlist through managed-settings.json with allowedMcpServers and deniedMcpServers, org policies, the coding agent firewall, and audit logs covering agent activity on GitHub.com. GitHub's documentation states two limits directly: registry-based MCP enforcement can be bypassed by editing configuration files, and the audit log does not include client session data such as the prompts a user sends to Copilot locally. Alyria Beacon covers exactly what sits outside those statements: the endpoint, the local calls and one policy and audit chain across all four coding agents.
Start with the vendor's own controls.
Each control below is named the way GitHubnames it, and links to the vendor's documentation. Deploy them: they are the fastest path to a working baseline.
MCP servers in Copilot policy
The enterprise or org policy that defines whether MCP servers can run at all across Copilot clients, with an approved-list recommendation for anything beyond allow-everything.
MCP server usage in your companymanaged-settings.json MCP allowlist
The recommended GA allowlist: allowedMcpServers and deniedMcpServers match remote servers by serverUrl and local servers by an exact serverCommand, applied settings across clients that users cannot override.
Configure an MCP server allowlistMCP private registry enforcement
Public preview. GitHub's own reference page calls it not the recommended method for restricting access to MCP servers: it matches by name or ID, which the docs say can be bypassed by editing configuration files, and it does not apply to the cloud agent.
MCP private registry enforcementCopilot audit logs
Enterprise and org audit records including Copilot settings, policy and license events plus agent activity on GitHub.com, kept 180 days and streamable to a SIEM.
Reviewing audit logsCoding agent administration
The coding agent runs in a GitHub cloud environment managed by org settings, including its own network firewall for the agent's outbound access.
Use the coding agentCopilot CLI hooks
Hook configuration for the Copilot CLI from .github/hooks JSON files; hooks run synchronously and can block execution.
Copilot CLI hooksWhat the native controls leave uncovered.
Drawn from what GitHub states about its own limits, not from us.
One of the two MCP mechanisms is preview, and bypassable
GitHub documents registry enforcement as name or ID matching that can be bypassed by editing configuration files, with strict blocking not yet available; the managed-settings.json allowlist is the mechanism its docs recommend, and the registry mode does not apply to the cloud agent.
Audit logs state what they do not cover
The audit-log documentation is precise: it does not include client session data, such as the prompts a user sends to Copilot locally, and it suggests a custom solution such as hooks that send Copilot CLI events to your own logging service. Local agent activity needs its own record somewhere.
Enterprise controls stop at Copilot
Managed MCP restrictions, content exclusions and policies govern Copilot surfaces. The same developer uses Cursor, Codex and Claude Code on the same machine, each with its own config files. Inventory and policy across all of them is an endpoint job by construction.
A practical starting point.
The allowlist shape GitHub's docs recommend for enterprises:
{
"allowedMcpServers": [
{ "serverUrl": "https://mcp.internal.corp" },
{ "serverCommand": ["npx", "@playwright/mcp@latest"] }
],
"deniedMcpServers": [
{ "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "/"] }
]
}What GitHub's controls cover, and what the endpoint adds
| Area | GitHub Copilot native controls | Endpoint governance with Alyria |
|---|---|---|
| MCP servers | GA managed-settings.json allowlist by serverUrl or exact serverCommand, plus the MCP servers in Copilot policy beside it. | Fleet-wide inventory of every configured server across clients, including stdio servers that never cross the network, with Lyra policy on each call. |
| Secrets and local files | Out of scope for this layer: Copilot enterprise settings and the audit log name what they cover as GitHub-side events. | Endpoint policy that blocks reading secrets and following them with a send, and Umbra leases so agents use credentials without holding them. |
| Cloud agent egress | The coding agent's GitHub cloud environment and its network firewall, governed from your org settings page. | The policy and audit layer stays the same for the local CLIs on developer laptops, so nothing changes when the work moves host. |
| Audit trail | 180-day audit log of GitHub-side Copilot events; the docs state it excludes local session data and recommend custom tooling such as CLI hooks to fill the gap. | One signed, tamper-evident audit chain covering policy decisions and MCP activity across all four agents, exportable for audit and routed to your SIEM by Spectra. |
| Beyond Copilot | Out of scope: these controls govern Copilot clients. | One policy and one audit chain covering Claude Code, Cursor, Codex, GitHub Copilot and whatever uses them. |
What Alyria Beacon adds.
Governance at the endpoint, not the gateway: the same policy, secrets and audit whether the agent is GitHub Copilot or something ships next quarter.
- Alyria Beacon is a signed, user-space agent: no kernel driver, installed read-only, running monitor-first so nothing is blocked until you enable enforcement.
- It inventories every AI tool, version and MCP server configured on each endpoint, then flags the unpinned servers and secrets in config that a name-matching registry cannot see.
- Lyra evaluates the written policy locally on every model and tool call, including the stdio calls registry policies do not observe.
- The signed audit chain records the affected decision with each event, covering what the local audit log does not: GitHub's own docs state it excludes client session data.
- Umbra brokers short-lived leases and Spectra routes the OpenTelemetry signal to your SIEM.
Questions security teams ask about GitHub Copilot and Alyria.
What does the coding agent firewall cover locally?
It covers the coding agent's GitHub cloud environment, which is where the cloud agent runs. Local Copilot surfaces and every other agent on the laptop are outside that boundary; that is the endpoint layer Alyria Beacon covers with local policy and a local audit chain.
Should we still set up the MCP allowlist in managed settings?
Yes. It is the GA mechanism GitHub recommends, match servers by serverUrl and exact serverCommand rather than by name, and keep using it. Alyria Beacon adds the cross-client inventory and per-call policy that an allowlist inside one tool does not provide.
GitHub documents that its audit log does not include local session data. How does Alyria close that?
Alyria Beacon records policy decisions and MCP activity locally, writes them to a signed, hash-chained audit chain, and Spectra routes the same signal over OpenTelemetry into your SIEM, so local agent activity has a verifiable record without hand-built hook pipelines.
- Native controls
- AI controls, managed-settings.json allowlist, coding agent firewall
- MCP enforcement
- GA allowlist by URL or exact command; registry mode in preview
- Endpoint layer
- Alyria Beacon: signed, user-space, no kernel driver
- Rollout
- Read-only install, monitor mode first
- Audit
- Signed, hash-chained chain; OTel export via Spectra
See what your agents are wired to.
Start in monitor mode: inventory the AI tools, versions and MCP servers on every endpoint, see what enforcement would decide, and turn on enforcement when you are ready.