The interesting part of the design is where the ceiling sits. The tool allowlist is declared in the Actor's input schema under `resourceType: "mcpConnector"`, and Apify's MCP proxy enforces it by filtering `tools/list` and rejecting calls outside the declared set [3][6]. So the restriction is not a promise made by the Actor's own code. It is applied on the path between the Actor and GitHub.
That matters because the author is explicit that the code itself stays untrusted: any allowed tool can be misused [11]. The claim being made is narrower and more useful than "this Actor is safe". It is that credential exfiltration and unlimited GitHub access are no longer preconditions of running the workflow [11]. The effective permission is the intersection of the schema allowlist, the connector's own permissions, and the scope of the underlying GitHub token [7]. Three layers, and the tightest one wins.
The credential handling is the part I would copy. At runtime the Actor gets a connector ID, the proxy base URL, and its own run token, and never sees the GitHub PAT or OAuth token held in the connector [8]. Compare that with the alternative the author names: pass a GitHub token into code you did not want handling tokens, or hand-copy repository contents into Actor input and hand-carry results back [5]. The connector fires at two boundaries, reading `package.json` and then searching for and writing the issue [4].
The server URL is pinned with a wildcard, `https://api.githubcopilot.com/mcp*`, which covers a trailing slash on the official endpoint and will not accept a different hostname [3][9]. That is the config line doing the work. A hostname wildcard broad enough to match an attacker-controlled host would undo the rest of it.
Then there is `confirmWriteTarget`. Dry run is the default, and a write run has to supply the exact `owner/repo` string [10]. The author is careful to say this is not a substitute for GitHub authorization, since the connector still enforces the caller's real permissions [10]. It is a guard against a toggled checkbox posting into the wrong repository. Cheap, and it addresses the failure mode that actually happens.
On the results: 16 advisory rows against a fixture repo with three intentionally old npm packages, on 8 August 2026 [1][2]. That is roughly five advisories per package, which is what a deliberately stale fixture is for. Do not read it as a base rate for your own tree. The number that transfers is the issue count, not the advisory count: after three runs, including one on published build 1.2.1, the repository still held exactly one issue [2][12]. For that to hold on your repo, `search_issues` has to reliably find the prior issue under your labelling and title conventions, and your triage issue has to be the only plausible match. Idempotency here is a search query, and search queries drift.
Three tools is also a real cost. No branch, no file edit, no merge, no other GitHub tool at all [3]. The Actor cannot bump a version or open the fix PR. It produces a source-linked review queue and a human does the rest [4]. Whether that is a feature depends on whether you were going to review the bot's PRs anyway.
