Model Context Protocol (MCP) is a standard way for AI agents and AI-enabled development tools to connect with external tools, data sources, and systems. Instead of hardcoding every integration into an assistant, MCP lets a tool expose capabilities that an agent can discover and call through a consistent interface.
For security teams, MCP matters because it turns AI from a text generator into an actor. A coding agent can ask for repository context, query logs, open tickets, call a deployment tool, or request temporary cloud access. That makes MCP useful, but it also creates a new control plane that needs identity, authorization, approval, logging, and policy.
How MCP works
An MCP setup usually has three parts:
- MCP client: The AI application or coding agent that wants to call tools.
- MCP server: The integration layer that exposes tools, prompts, resources, or workflows.
- External system: The destination system, such as a cloud account, database, ticketing system, CI/CD platform, or security graph.
The MCP server defines what the agent can do. For example, one MCP server might expose a read-only cloud inventory lookup. Another might expose a just-in-time access workflow that grants short-lived credentials after policy checks and approval.
The primitives MCP exposes
MCP standardizes a small set of capability types that a server can offer to a client. Understanding them helps clarify where the security boundaries sit:
- Tools are actions the agent can invoke — query a database, open a ticket, list cloud resources, request access. Tools are the highest-risk primitive because invoking one has an effect on an external system.
- Resources are data the agent can read — a file, a log stream, a record. They look passive, but resource content flows into the model’s context and can carry instructions, so it is not “safe” simply because it is a read.
- Prompts are reusable templates a server can offer to structure how the agent uses it.
A server can expose any combination of these. The practical takeaway is that the interesting security decisions are per-tool and per-resource: which tools an agent may call, and whether the content of a resource can be trusted once it enters the model’s context.
Transport and where servers run
MCP servers commonly run as local processes that the client launches and talks to over stdio, or as remote services reached over a network transport. The local model is why a misconfigured server is dangerous: it typically runs with the developer’s own privileges and no sandbox, so a server given a broad file mount or a long-lived credential can reach far more than the immediate task requires. The distinction between “the protocol” and “how a given server is run and scoped” is the single most important thing to hold onto — MCP itself is neutral; the risk lives in configuration and privilege.
Why MCP changes cloud security
Before AI agents, most access programs were designed for humans, services, and CI/CD jobs. MCP adds another identity category: an agent acting on behalf of a human. That agent may be able to reason across code, infrastructure, logs, and tickets faster than a person can, but it still needs boundaries.
Security teams should answer four questions before allowing MCP-connected agents into cloud workflows:
- Who is the agent acting for?
- What tool or resource is the agent allowed to call?
- What action is safe without approval?
- Where is the audit trail stored?
Without these answers, MCP integrations can quietly become shared service accounts with better language skills.
MCP security best practices
Use least privilege by default. MCP tools should expose narrow actions, not broad admin interfaces. A tool named request_prod_db_access is easier to govern than a generic run_cloud_command function.
Broker credentials just in time. Avoid placing long-lived cloud keys, database passwords, or SaaS tokens inside the agent environment. Instead, require the agent to request scoped credentials through a broker.
Tie every action back to a human. If an AI coding agent reads a secret, deploys a change, or requests production access, the audit log should show the agent identity and the operating human.
Gate risky actions. Read-only lookups may be allowed automatically. Destructive actions, production changes, data access, and privilege escalation should require approval or be blocked by policy.
Treat tool responses as untrusted. The content a server returns enters the model’s context and can steer the agent’s next step. An MCP setup that reads a web page, a README, or a third-party record can ingest an indirect prompt-injection payload, so the defense cannot rely only on trusting the server — it has to constrain what the agent is allowed to do afterward.
MCP identity: the missing category
Most access programs were built around a handful of identity types: human users, service accounts, and CI/CD jobs. An MCP-connected agent does not fit cleanly into any of them. It is not a human, but it acts with human intent. It is not a static service account, because it reasons and chooses its own next action. It is not a pipeline job, because it is interactive and open-ended.
This matters because the controls you already have often assume one of the old categories. Role assignments, session logging, and approval workflows that key off a human user do not automatically cover an agent, and a service account the agent shares hides the operating human from your audit trail. The durable fix is to treat the agent as its own non-human identity — one that is always tied back to the human it acts for — and to broker its access just in time rather than let it hold standing credentials. That keeps the four questions above answerable: who is it acting for, what may it call, what is safe without approval, and where is the evidence.
How Cloudanix helps
Cloudanix uses MCP to support agentic JIT access. AI coding agents can request temporary cloud, database, Kubernetes, or SaaS access through Cloudanix instead of receiving standing credentials. Cloudanix evaluates policy, scopes the credential, records the operator, and preserves evidence.
Because this runs on the same unified asset graph as Cloudanix’s cloud, identity, and code controls, an agent’s MCP access is not a separate silo — the credential it requested, the resource it touched, and the human it acted for are all connected, so approvals and audit reflect real blast radius rather than a disconnected log line.
This connects MCP to broader controls across Coding Agent JIT, Coding Agent Guardrail, Non-Human Identity, and Just-In-Time Access.
Frequently asked questions
Is MCP a security product?
No. MCP is an integration protocol. Security comes from how MCP tools are designed, authorized, logged, and governed.
Does MCP require agents to hold cloud credentials?
It should not. A safer pattern is to let the agent request short-lived, scoped credentials through a JIT broker.
Is MCP only for coding agents?
No. MCP can connect many AI assistants to tools and data sources, but coding agents are one of the clearest use cases because they interact with repositories, infrastructure, and deployment workflows.
What is the biggest MCP security risk?
The biggest risk is turning MCP into an ungoverned automation channel where agents can call powerful tools without identity, approval, or audit controls.
