Teams treat npm packages and SaaS OAuth apps as dependencies. MCP servers deserve the same posture: named owners, reviewed scopes, and a reason to exist. Industry buyers already evaluate agent platforms on permissions, audit and spend; the tool layer is where those controls live.
Blog · 2026-10-27
MCP servers are dependencies: allowlist and scope them like production integrations
Model Context Protocol servers reach trackers, databases and cloud consoles for coding agents. Treat each server as a credentialed dependency — allowlist, least privilege, review — before you call it productivity.
Agents without tools are chat; tools without review are risk
Coding agents earn their keep when they can open tickets, query a schema or inspect a deploy. That reach usually arrives through MCP-style tool servers — not through the model weights alone.
If a human needed the same API key with the same privileges, you would run an access review. An agent holding it should not skip the queue.
Inventory what the agent can actually call
List every MCP server (or equivalent tool bridge) in use: local IDE plugins, cloud agent runtimes, CI bots. For each, record tools exposed, credentials used, data classes reachable and who approved it.
Classify by blast radius. Read-only docs search is not the same as a server that can mutate production cloud resources or message customers.
Shadow MCP configs on laptops are the cousin of unmanaged agents — inventory them before you ban everything and drive the work underground. Related baseline: unmanaged AI agents as insider risk.
Allowlist beats kitchen-sink tool racks
Default-deny tool connections. Approve a shortlist that matches the jobs agents are hired for — not every public server that demos well.
Prune ruthlessly. Teams that cut tool counts often see fewer wasted tool calls and smaller prompt schemas without losing the workflow. Fifteen tools that nobody uses are fifteen chances to over-share credentials.
Document the allowlist in the same place you document approved SaaS. Agents and humans should not invent new bridges in a Friday Slack thread.
Least privilege for every server credential
Issue unique, revocable credentials per MCP server — not a shared human SSO session pasted into a config file. Prefer read-only tokens where the job is inspection; escalate write access only for named workflows with review.
Separate environments. A server that can touch staging should not quietly hold production roles. Broker short-lived tokens when you can; long-lived keys in agent profiles are classic secret debt.
Cloud identity and spend caps still apply when the caller is an agent rather than a person — see agent-ready cloud controls.
Review MCP servers like third-party Actions
Ask who maintains the server, what network it can reach, whether tool descriptions can be poisoned, and how you will pin or mirror versions. Novelty in the critical path is unpaid risk.
Human checkpoints on high-blast-radius tools
Encode which tool calls are auto-allowed, which need a human click, and which are forbidden. Put that in the gateway or agent policy — not only in a guideline PDF.
01
Mutating cloud, deploying, or messaging customers should fail closed without approval. Read-only exploration can stay faster.
02
Test refusal. An agent that cannot be stopped from calling a dangerous tool is not autonomy; it is negligence with a friendly chat UI. Product-built agents need the same checkpoint mindset as feature work — suggest, do not silently decide.
What to put in the brief and the SOW
Name approved MCP servers (or tool bridges), banned data classes, credential owners and how exceptions expire. Keep it short enough that squads will follow it.
Ask partners how agents will reach your systems: client-owned credentials, allowlists, and audit of tool calls — not a shared vendor laptop with every integration enabled.
Include token and spend expectations. Tool-heavy agents burn budget on schemas and retries; measure that beside model cost so FinOps is not surprised.
How Three Index scopes agent integrations
Our AI & ML work designs copilots and agents with scoped tools, evaluation and human checkpoints — in repositories and cloud accounts you keep.
API development and DevOps and cloud habits — least privilege, audit, short-lived identity — apply to MCP-style bridges the same way they apply to partner APIs and CI.
We favour boring allowlists over demo-ready kitchen sinks. Speed that skips review is not delivery discipline.
Send a brief listing the tools your agents already call and the actions they can take. We will propose an allowlist, scopes and approvals that match the blast radius you actually have.
FAQ
Short answers related to this article.
What is an MCP server in a product team context?
A Model Context Protocol server exposes tools an AI agent can call — issue trackers, databases, cloud APIs, browsers. Each connection carries credentials and blast radius like any other production integration.
Why not connect every useful MCP server by default?
Tool schemas consume context and tokens, widen the attack surface, and often over-privilege the agent. A short allowlist with scoped credentials beats a kitchen-sink setup that nobody reviews.
How can Three Index help with agent tool access?
We design AI features and delivery rails with scoped tools, human checkpoints and client-owned repos — so agent integrations stay inside identities and policies you control.
Why Three Index
AI-first software development company in Ahmedabad. Founded 2020. Fifty-plus IT professionals. Five hundred-plus projects shipped.
We are a software engineering company: large enough to staff serious products and small enough that the people who wrote a module can still explain it. See how we operate, our AI development work, browse case studies, read the FAQ, or join the team.
Tell us what you are trying to build.
Send a short description of the project. You will get a reply from someone technical — with questions worth answering, not a brochure.