Blog / English
MCP in production: connecting tools is easy; controlling authority is the real problem
Connecting AI to GitHub, a database, and Slack creates an impressive demo.
Giving that AI authority over all three creates a system that needs architecture.
The Model Context Protocol, or MCP, reduces the effort required for AI applications to discover tools, resources, and input/output contracts. That standardization is powerful. It also makes it easy to confuse integration with governance.
A successful tool call proves connectivity. It does not prove the agent should see that data, perform that action, or keep that permission tomorrow.
MCP standardizes the door. Your company still decides who gets the key
In simple terms, MCP lets a host connect models to servers that expose resources and tools. The protocol organizes discovery, messages, contracts, and transport.
That solves an important engineering problem. The difficult work begins next:
- who may invoke each tool;
- which user or service the agent represents;
- which data may enter the context;
- which actions require approval;
- how long credentials remain valid;
- which evidence must be recorded;
- how to contain an error or malicious instruction.
The protocol transports capability. Architecture defines authority.
The most expensive mistake is authorizing an agent like a trusted employee
An agent does not receive instructions only from your team. It also processes issues, documents, pages, logs, messages, and tool descriptions. Some of that content may be wrong or designed to influence its behavior.
When one identity can read data, modify code, approve changes, and publish results, an external instruction can cross the entire workflow. The problem is larger than prompt injection. It is the combination of untrusted content and broad authority.
“The user authorized the agent” is therefore not a sufficient policy. Authorization must answer five separate questions.
The five dimensions of authority
1. What can it see?
Limit context by project, repository, directory, tenant, data type, and purpose. Reading a schema does not imply reading production records. Reading an issue does not imply access to every attachment.
2. What can it do?
Grant permissions by capability: read a file, edit a branch, open a PR, run a migration, or send a message. Broad scopes such as “full GitHub access” hide actions with very different consequences.
3. Whom does it represent?
Avoid shared credentials. Every call should preserve the identity of the responsible user, agent, or service. Without identity, an audit trail becomes a list of actions with no accountable actor.
4. For how long?
Short-lived credentials reduce the impact of leaks and forgotten access. A twenty-minute task does not need a token that remains valid for months.
5. Under which condition?
Reading may be automatic. A reversible local change may only need a log. Production, external communication, and destructive operations should require approval when the action is about to happen.
Autonomy is not the absence of limits. It is freedom inside an observable contract.
A permission ladder for agents
| Level | Capability | Minimum control |
|---|---|---|
| 1 | read authorized context | data scope, redaction, and access log |
| 2 | propose a change | isolated output, diff, and no write credential |
| 3 | edit a local environment | sandbox, tests, and local rollback |
| 4 | open a PR or act in staging | dedicated identity, per-tool policy, and audit trail |
| 5 | external or production action | temporary credential, action-time approval, and reversal plan |
An agent should move up this ladder because the task requires it, not because the configuration makes it convenient. Its authority should expire when the task ends.
Four shortcuts that look efficient
One token for everything
This is simple until nobody can tell which service should accept the token. The MCP specification requires audience validation and prohibits improper token passthrough. Each resource must recognize credentials intended for it.
Treating the tool description as policy
A description helps the model choose a function. It must not grant access. Authorization belongs in a deterministic layer outside the text interpreted by the agent.
Approving everything at the beginning of a session
Authorizing a connection does not approve every future action. Consent must follow consequences: publish, delete, send, or change production.
Logging everything without a policy
Complete logs can leak secrets and personal data. Record the tool, identity, scope, time, authorization decision, and outcome. Protect or remove sensitive content that the audit does not need.
The minimum contract for every tool
Before an MCP server reaches production, document:
- the tool's purpose;
- the data it reads and writes;
- external effects and reversibility;
- the identity used for execution;
- the least set of permissions;
- the condition for human approval;
- timeout, usage limits, and expiration;
- fields recorded for audit;
- treatment of untrusted content;
- rollback or containment.
If a tool cannot complete this contract, it is not ready for production authority.
Where ArchGenerator.com fits
Your team can keep using the coding AI and MCP servers it already chose. ArchGenerator.com keeps the definitions that should not be scattered across prompts and configuration files in a company-owned home.
Discovery and SPEC define the agent flow, actors, data, constraints, and acceptance criteria. Architecture decisions record trust boundaries, identity, and permissions. Reports help observe the implementation and link findings to evidence. The SDD Kit carries the contract into the AI that will perform the coding.
This separates responsibilities: MCP connects; the coding tool implements; ArchGenerator.com organizes intent, architecture, specification, and governance.
You do not need to reduce agent autonomy. You need to stop autonomy from becoming invisible authority.
Try ArchGenerator.com by modeling one critical MCP flow. Record who can see, act, approve, and prove every step. When the next server is connected, your team will have a decision standard—instead of another key whose reach is difficult to explain.