What can an agent actually do with github-mcp-server, and who decides?

[javmann100]

I maintain an open-source project called mnki that puts a verification step in front of an MCP tools/call, so a client can see what an agent was authorised to do before the server runs it. I'm not selling anything today; I'm trying to find out whether "which server can do what, for whom" is a real problem for people who publish servers, or whether I've invented it.

One line in your README stood out to me: "2. Any applicable policies enabled". That is the closest thing I have seen to an answer inside the server itself, and I would like to understand where it stops.

If you have 20 minutes I'd like to hear how you think about it and what users ask you. If it's easier to try than to talk: npx mnki-cli scan lists every MCP server configured on a machine and mnki protect --mode observe records what would have been denied without changing anything (https://mnki.com/docs/integrations).

Either way, thank you for github-mcp-server.

[TongyiDai]

This is a real boundary, and the current server answers only part of it.

For github-mcp-server today, effective authority is the intersection of four layers:

1. Registered surface: --toolsets / --tools decide which operations the model can see.
2. Server mode: --read-only removes write tools even if explicitly requested.
3. GitHub credential: the PAT, OAuth token, or GitHub App installation determines repositories and API permissions; SSO and organization policies apply on top.
4. GitHub resource rules: repository permissions, branch rulesets, required reviews, and similar controls can still reject the API operation.

Lockdown mode is different: it filters untrusted public-repository content to reduce prompt-injection exposure. The README explicitly says it is not an authorization boundary and does not reduce what the credential itself can read or write.

What is not represented is “agent A, acting for principal P, may call tool T only with constraints C for this task.” If two agents share the same server process and credential, GitHub sees the same authenticated principal; the server does not natively distinguish their delegated authority, attach per-call budgets, or issue a signed decision receipt.

So a verification layer is complementary if it sits before tools/call and fails closed. The hard requirements I would test are: an unforgeable caller identity, constraints over arguments rather than tool names alone, protection against confused-deputy reuse of a stronger credential, deterministic policy versioning, and an append-only evidence record that never logs secrets. It should also treat the GitHub token as an upper bound, never as proof that a particular agent was delegated every action the token permits.

Current controls: https://github.com/github/github-mcp-server/blob/main/docs/policies-and-governance.md