MCP for Business: Connecting Agents with Control

What Is MCP

MCP defines a client-server architecture for connecting AI applications to data and capabilities. Its usual building blocks are:

• Host: the application that runs the AI experience.
• MCP client: maintains the connection to a server.
• MCP server: exposes the capabilities.
• Resources: queryable content.
• Tools: executable operations.
• Prompts: reusable templates or workflows.

The protocol standardizes the communication, but the organization remains responsible for which server it installs, what data it exposes and what actions it authorizes.

MCP vs. a Conventional API

MCP does not replace the underlying API: it usually wraps it and adds a layer that also needs governing.

Server Inventory

Every MCP server needs its own record, covering at least:

• Owner and repository.
• Version and vendor.
• Transport and location.
• Resources, tools and prompts it exposes.
• Target systems.
• Data and its classification.
• Credentials and scopes.
• Authorized users and agents.
• Logs and retention.
• Update and decommissioning process.

Local servers installed by users count toward this inventory too. Connections to unapproved servers should be blocked whenever the risk warrants it.

Trust Model

A server is not trusted simply for appearing in a registry, nor is a client trusted simply for being corporate. Both parties must authenticate, the version must be validated, and the exposed capability must be limited.

A threat can compromise any link in the chain:

• The MCP server.
• The package or dependency.
• The client or the host.
• The model that decides which tools to use.
• The retrieved content.
• The downstream system.
• The delegated credentials.

The threat model must cover the whole chain, not just the server.

Authorization

The official MCP documentation defines authorization for HTTP transports following OAuth 2.1 conventions. Implementations should avoid static, broad-scope tokens.

The core principles are:

1. User and service authentication.
2. Tokens with the correct audience.
3. Minimum scopes.
4. Short lifetime and rotation.
5. Clear consent.
6. Revocation and deprovisioning.
7. Separation of environments.
8. Never forwarding tokens to unauthorized destinations.

Over STDIO transport, credentials usually come from the environment. They must be isolated and never exposed in prompts, logs or insecure configuration files.

Per-Tool Permissions

A server with access to email should not expose a single blanket permission such as "manage email." At minimum, it should separate:

• Search.
• Read.
• Create draft.
• Send.
• Delete.
• Manage rules.

Each tool must define its arguments, limits, recipients, volume and approval requirements. Read operations do not imply write permission.

Deterministic Validation

The model can propose a call, but deterministic code must be the one validating, among other things:

• Schema and types.
• Identity and scope.
• Allowed resource.
• Business rules.
• Quantity limits.
• Context and environment.
• Idempotency.
• Approval requirements.

An instruction contained in a document or in a tool's response can never expand permissions on its own.

Specific Risks

Confused Deputy

A server uses its own authority to execute a request the user could not perform directly. This is mitigated by binding the token, the user, the resource and the purpose of the call together.

Token Passthrough

Reusing the token received on downstream services can break audience checks and access control. The server should use proper flows and destination-specific credentials for each target.

Indirect Prompt Injection

A resource contains malicious instructions that lead the agent to call tools it should not. Retrieved content is always treated as untrusted data, and any resulting action requires an external policy check.

Tool Poisoning

A tool's description or behavior can mislead the model. That is why tools should only be allowed from a signed or approved catalog, and any change must be reviewed.

SSRF and Local Access

A server that accepts URLs or paths can end up reaching the internal network or files it should not. This is mitigated with allow-lists, input normalization and isolation.

Supply Chain

Reference implementations are not necessarily production-ready. The code, dependencies, signing, SBOM, updates and overall package security must all be reviewed.

Enterprise-managed authorization

The enterprise-managed authorization extension aims to stop each person from authorizing servers on their own, without a central policy. It allows corporate identity, onboarding, offboarding and consistent controls to be integrated across the whole organization, which fits well with a corporate AI gateway approach that centralizes governance over these connections.

The organization should centralize:

• The server catalog.
• Identity providers.
• Policies and scopes.
• Approvals.
• Revocation.
• Observability.
• Exceptions.

Human Approval

Not every tool needs human confirmation. The control matrix should weigh the impact and reversibility of each action:

The approval screen must always show the action, the arguments, the affected system, the consequences and the source that triggered it.

Logging

The trace of every call should include:

• User, agent and server.
• Version.
• Tool invoked.
• Redacted arguments.
• Policy applied.
• Approval.
• Response.
• Error and retry.
• Latency and cost.
• Correlation ID.

Sensitive data must be minimized in the log. Logs need to support incident investigation without becoming an indiscriminate copy of the underlying information.

Availability and Idempotency

Timeouts and retries can duplicate actions. That is why every write operation must use an idempotency key, alongside call limits, circuit breakers and compensation mechanisms.

If the server goes down, the agent must fail safely: report the incident, avoid fabricating a result, and avoid falling back on an alternative tool with broader privileges.

Lifecycle

Admission

Review of the server's owner, code, vendor, data, tools and threats.

Pilot

Test environment, synthetic accounts and permissions limited to read-only.

Production

Pinned version, monitoring, SLA and rollback plan.

Change

Review of any new tool, scope or dependency before it is approved.

Decommissioning

Revoke tokens, remove the configuration, retain evidence and confirm deletion.

Testing

Before signing off on an MCP server, it is worth checking at least:

• A user without permission.
• A token with the wrong audience.
• A tampered tool.
• Out-of-range arguments.
• A resource carrying a prompt injection.
• An internal URL or a path traversal attempt.
• A downed server.
• A malformed response.
• A duplicated call.
• The offboarding process.

This kind of adversarial testing is exactly the territory covered by an AI Red Teaming exercise applied to the agent and MCP server layer.

60-Day Plan

Days 1-15

Inventory, a scoped use case and a threat model.

Days 16-30

Authorization, scopes, catalog and policies.

Days 31-45

Validation, approval, logging and adversarial testing.

Days 46-60

Pilot, metrics, fixes and limited production.

Common Mistakes

1. Installing community servers without review.
2. Using broad-scope personal tokens.
3. Trusting tool descriptions at face value.
4. Mixing read and write permissions.
5. Approving actions without showing the arguments.
6. Forwarding tokens to downstream systems.
7. Not validating URLs or paths.
8. Logging secrets.
9. Retrying calls without idempotency.
10. Not revoking access when a server or user is decommissioned.

Checklist

• Catalog and owner defined.
• Versions and code reviewed.
• Authorization and audience correct.
• Minimum scopes and tools.
• Validation outside the model.
• Approval matched to impact.
• Secrets and network isolation.
• Correlated, minimized logs.
• Idempotency and limits in place.
• Injection and supply-chain testing.
• Revocation and decommissioning planned.

FAQ

Is MCP secure by default?

No. It provides mechanisms and a specification, but real security depends on the authorization, implementation and policies each organization applies.

Does it replace OAuth?

No. For HTTP transports, MCP defines an authorization framework aligned with OAuth 2.1, not an alternative to it.

Can it be used read-only?

Yes, and it is a good starting point. In that case, the catalog should be limited to resources and non-destructive tools.

Is a reference server production-ready?

It should not be assumed. The official repository itself warns that reference implementations are educational and require a security assessment before being taken to production.

At Summum IA we design the catalog, authorization, policies and testing needed to integrate MCP without silently expanding privileges. If your company wants to connect AI agents to internal systems with this level of control, our MCP integration for business service supports every phase, from the initial inventory through to limited production.