如何在接入生产数据前划定 MCP 访问权限

The Model Context Protocol (MCP) makes it possible to give coding agents access to real systems. With the right server, an agent can read GitHub issues, inspect a Postgres schema, pull logs, query docs, or call internal tools from the same chat where it edits code.

That is useful. It is also where agent workflows start to feel dangerous.

The first MCP question should not be “What can I connect?” It should be “What is the smallest capability that helps the agent stop guessing without letting it change production state?”

If you are new to the concept, start with the site’s MCP setup page and the broader article on giving agents a pair of hands. This post is about the boundary that comes next: when a tool is helpful, when it is premature, and when it should require human approval.

For GitHub Copilot cloud agent, configure credentials in the dedicated Agents store and review MCP tool access separately.

What is the blast radius of tool access?

A chat-only agent can still write bad code, but its blast radius is usually limited to the files you accept. A tool-enabled agent can affect systems outside the editor. It can retrieve private data, create tickets, post messages, run queries, or trigger infrastructure changes depending on what you expose.

That does not mean MCP is unsafe. It means MCP design is security design.

Every tool should be judged by three questions:

• What can the tool read?
• What can the tool change?
• What is the worst plausible mistake?

The third question matters most. A tool that lists database tables has a different risk profile from a tool that runs arbitrary SQL. A tool that creates a draft pull request is different from a tool that merges to main. A tool that proposes a Slack message is different from one that posts directly into an incident channel.

Start with read-only tools

The safest useful MCP tools are read-only. They reduce hallucination without giving the agent authority to mutate systems.

Good early tools include:

• Read the database schema.
• Fetch recent error logs from an observability system.
• Search internal documentation.
• List open GitHub issues or pull requests.
• Read feature flag definitions.
• Fetch design tokens or component docs.

These tools help the agent answer questions it would otherwise guess. If it can inspect the schema, it is less likely to invent a column. If it can read the component docs, it is less likely to create a one-off UI pattern. If it can fetch recent errors, it can debug with evidence instead of guesswork.

Read-only tools are not risk-free. They can still expose sensitive information inside a model context window. But they are the right first step because they separate understanding from action.

Be careful with arbitrary query tools

Database tools deserve special caution. A read-only database user is safer than a write-capable one, but “read-only” still needs boundaries.

Prefer tools like this:

get_schema(tableName)
list_tables()
run_named_read_query(queryId, params)
explain_query(queryId, params)

Be slower to expose tools like this:

run_sql(sql)
run_shell(command)
execute_migration(path)

The difference is not cosmetic. A named query tool lets the team decide which questions are safe. An arbitrary SQL tool asks the model to decide what SQL is safe. That is too much trust for most production workflows.

If an agent needs data to debug a feature, give it a constrained path. For example, expose a tool that retrieves a sanitized order summary by ID, not a tool that can query every row in the orders table.

Use the proposal pattern for writes

When the agent needs to change something outside the repo, prefer proposed changes over direct execution.

Instead of letting an agent run a migration, ask it to generate the migration file. Instead of letting it post an incident update, ask it to draft the message. Instead of letting it change a feature flag, ask it to produce the flag update request with the old value, new value, reason, and rollback note.

That creates a useful human-in-the-loop pattern:

1. The agent gathers context with read tools.
2. The agent writes a proposed artifact.
3. A human reviews the artifact.
4. The normal deployment, approval, or operations process applies it.

This keeps the agent in the workflow without letting it bypass the workflow. The agent templates can help here because a good task brief should say whether the agent is allowed to edit files, run commands, or only propose a change.

A practical access ladder

Use this ladder to force an explicit decision about authority:

Level 1: Documentation and repo context

The agent can read docs, repo maps, component catalogs, and API references. This is the safest place to start and the easiest to justify.

Level 2: Observability and issue context

The agent can read logs, traces, error reports, and issue metadata. Keep PII out of tool responses where possible. Prefer summaries and redacted payloads.

Level 3: Constrained read-only production data

The agent can call named read queries with strict parameters and redaction. Use this for debugging only when docs and logs are not enough.

Level 4: Proposed writes

The agent can create migration files, draft messages, generate pull requests, or produce config changes, but a human applies them through normal review.

Level 5: Approved writes

The agent can perform limited writes only after explicit approval, with audit logs and rollback notes. This is not a day-one setup.

Levels 1 and 2 can support useful workflows without direct writes. Level 5 should exist only when a concrete use case justifies the added authorization, audit, rollback, and incident-response burden.

How do you know a tool is premature?

Do not give the agent database or infrastructure access just because the integration exists. Slow down when:

• The team cannot name the exact tasks the tool supports.
• The tool accepts arbitrary commands.
• The tool response includes secrets or unnecessary PII.
• There is no audit trail.
• There is no dry-run mode.
• The rollback plan is “ask the agent to fix it.”

That last one is especially important. If a tool can change state, the team needs an undo path that does not depend on the same agent making a second correct decision.

The useful default

Give agents more context before you give them more authority. Start with read tools. Add proposal tools when the workflow is stable. Reserve write tools for narrow, audited operations that humans explicitly approve.

MCP is at its best when it gives agents enough hands to stop guessing, not enough hands to bypass engineering judgment.