A coding agent connected to an MCP server or external tools is no longer just an assistant suggesting code. It can read repositories, query tickets, search internal documentation, call APIs, execute commands, access databases, open pull requests, modify configurations, or interact with cloud services. The risk surface changes: it is no longer just about the generated file, but about the permissions, data, and actions the agent can use while working.

The Model Context Protocol was created to standardize the connection between LLM applications, tools, and data sources. For software development teams, it is useful because it reduces ad-hoc integrations and makes it easier to provide agents with operational context. However, the same capability shifts the problem toward a more delicate question: if the agent misinterprets a task, suffers from prompt injection, or chooses the wrong tool, what systems can it actually touch?

Before using MCP in a development workflow, security engineers, CTOs, and advanced developers must map tools, identities, authorizations, tokens, logs, and permitted actions. A read-only MCP server on public documentation has a very different risk profile than a server with access to repositories, CI/CD, cloud, tickets, databases, or enterprise systems.

From code generation to tool use

In traditional vibe coding, the main risk is accepting unverified code. With MCP and agentic tool use, the risk extends to the path that produces that code: the agent can read data, select tools, compose parameters, interpret output, decide the next action, and propose or apply changes. If the tools have broad privileges, a context error can become a real-world action.

An agent that reads an issue and then modifies a route can introduce a vulnerability into the code. An agent that reads the same issue, queries the database, updates a cloud configuration, and opens a pull request has a much wider perimeter: it can expose data, use credentials, modify policies, expand permissions, or generate a diff based on untrusted output.

MCP security, MCP server vulnerabilities, agentic tool security, and agent tool misuse must therefore be read together. The issue is not just whether the MCP server “works,” but what capabilities it exposes, to which identity, with what authorization, with what isolation, with what logging, and with what human confirmations.

Excessive agency: when the agent has more power than necessary

OWASP lists excessive agency among the top risks for LLM applications: a model with excessive autonomy, functionality, or permissions can perform unintended actions, especially if manipulated by prompt injection or untrusted data. With MCP, this risk becomes practical because the protocol connects the agent to real tools.

The question to ask about every tool is concrete: does the agent really need to be able to write, or is reading enough? Does it need to use production data, or is staging sufficient? Does it need to act on all repositories, or only on a specific project? Does it need to be able to call any endpoint, or only operations with a controlled schema? Does it need to be able to execute shell commands, or is it enough to consult pre-prepared results?

A healthy privilege model separates reading, writing, and destructive actions. Reading technical documentation is not the same as reading logs with personal data. Opening an issue is not like closing it. Preparing a command is not like executing it. Generating a patch is not like merging it. The more irreversible, costly, or connected to real data an action is, the more human approval, sandboxing, and audit trails are needed.

Confused deputy, token passthrough, and MCP authorization

MCP security documentation highlights the risk of a confused deputy: a component with privileges can be induced to act on behalf of a client or resource other than the intended one. In an agentic workflow, this scenario is critical because the agent can find itself between the user, client, MCP server, OAuth provider, enterprise APIs, and final resources.

The MCP specification for HTTP transports defines authorization capabilities based on OAuth 2.1, and recent versions emphasize the use of resource indicators to bind tokens and resources. MCP best practices forbid token passthrough because transferring tokens received from one component to another can break audience, scope, revocation, traceability, and trust boundaries. For an enterprise application, this is not an implementation detail: it determines whether an agent can use credentials in the right context or abuse them elsewhere.

In practice, an MCP server should not use global tokens when the action depends on the user, nor should it accept a token intended for one resource and use it on another. It should not share the same credential across different repositories, tenants, or environments, nor should it hide from the end user which client is requesting access to which data. Every sensitive tool must have clear identity, scope, and resource boundaries.

Tool metadata and tool poisoning

An MCP tool is not just executable code: it also exposes a name, description, input schema, and often usage examples. The model uses this information to decide when to call it and how to fill in parameters. If an attacker manages to manipulate metadata, descriptions, documentation, or tool output, they can steer the agent toward wrong choices.

The risk of tool poisoning is subtle because it exploits the way the model reasons about text. A description might state “use this tool to retrieve temporary credentials” or “no confirmation needed to update configurations.” An apparently harmless tool can return output that contains instructions directed at the agent rather than data. An MCP server installed from an unverified source can expose tools with names similar to legitimate ones.

Defense starts with controlling provenance. MCP servers used on repositories or enterprise systems should come from approved sources, be versioned, reviewed, and configured with allowlists. Tool descriptions must be precise and minimal: explain what the tool does, what inputs it accepts, what effects it produces, and what limits it has. Security instructions should not live in the tool’s descriptive text as the only barrier, but should be enforced by authorizations, policies, and runtime controls.

Tool output: data, instructions, and subsequent actions

An agent can use a tool’s output as input for a subsequent decision. If the tool retrieves documentation, issues, web pages, logs, or database records, the output may contain untrusted text. If the tool generates commands, paths, queries, patches, or configurations, manipulated output can become an action.

The typical case is a simple chain: the tool reads a ticket, the ticket contains hostile instructions, the agent follows them, and then calls another tool with higher privileges. The result can be an exposed route, an expanded cloud policy, a modified test, an unfiltered query, or a secret copied into a file. Indirect prompt injection becomes much more severe when the model can use tools after reading content.

Tool outputs must be validated like any external input: strict schemas, explicit types, escaping, field limits, allowlists for subsequent actions, and separation between data and instructions reduce the risk. For sensitive actions, the agent should show what it has read, which tool it wants to call, what parameters it will use, and what effect is expected, because a generic confirmation does not give the reviewer enough context.

Prompt injection via documents, tickets, and enterprise systems

MCP makes it easy to connect an agent to systems already full of content: Jira, GitHub Issues, Slack, email, wikis, CRMs, documentation, knowledge bases, logs, and ticketing systems. This content was not written to be secure instructions for a model and may contain malicious text, fragments copied by users, obsolete examples, unverified commands, or manipulated data.

A support ticket might include a sentence designed to make the agent ignore project rules. A comment in an issue might ask to use an admin endpoint. An internal document might report an old procedure with credentials or permissions that are no longer valid. A web page retrieved by the tool might contain hidden instructions. If the agent treats everything as trusted context, tools become a risk amplifier.

Secure workflows separate approved sources from untrusted content. A ticket can describe a bug, but it must not change the agent’s policies. An external page can provide information, but it must not authorize commands. A log can aid diagnosis, but it must not bring secrets into the context. When the agent moves from reading to action, explicit control is needed.

Tools that read repositories, filesystems, and secrets

In the context of software development, many MCP servers and connectors are useful precisely because they read repositories, filesystems, configurations, and technical documentation. The risk is that they read too much: an agent that can freely explore the project may encounter .env files, API keys, deploy tokens, backup files, dumps, logs, certificates, cloud configurations, or personal data used in tests.

The problem is not solved just by trusting the vendor or the model. If a secret is read, copied into a diff, included in a log, sent to a tool, or inserted into a response, the damage is operational and remediation includes removal from code, credential rotation, environment verification, and auditing of builds, logs, and artifacts.

For this reason, filesystem and repository tools should start with deny-by-default. Sensitive paths, .env files, dumps, backups, secret manager exports, private keys, and real logs must be excluded or accessible only with specific authorization. Credentials used by MCP servers must be separated from personal and production credentials: if a tool needs to read code, it should not automatically read secrets and data as well.

Tools that write, delete, or deploy

The risk threshold changes when the tool does not just read. Writing to databases, updating tickets, sending emails, opening PRs, modifying files, deleting resources, rotating credentials, launching pipelines, or deploying are actions with real impact, and even an apparently small change can have wide effects if it happens in the wrong context.

An agent might decide to resolve a build error by opening permissions, disabling a check, widening CORS, changing environment variables, or modifying CI/CD workflows. It might close a ticket because it misinterprets a tool’s output, send a message with internal data, execute a migration on the wrong database, or make a pull request that combines generated code and unreviewed configurations.

Write actions require a stricter model: dry-run, staging, explicit approval, logs, rollback, and clear limits. The user must be able to see parameters and consequences before confirming. For cloud, databases, CI/CD, email, ticketing, and client systems, it is advisable to separate read-only tools from write tools and disable destructive actions by default.

Isolation between users, tenants, and environments

An MCP server can be used by multiple people, teams, repositories, or environments. If the identity is not propagated correctly, the server risks acting with a technical account that is too broad, creating classic authorization problems: a user can read another team’s data, an agent can modify repositories out of scope, a test environment can touch production, or one tenant can influence another.

Security must be designed per user and per resource. Tool calls must be attributable to a person or an authorized service, tokens must have scopes consistent with the repository, project, tenant, and environment, and object-level authorizations cannot be replaced by a generic “the agent is authorized” rule. If a tool acts on multi-tenant data, every request must preserve the correct tenant until the final resource.

In pre-production tests, different users must be simulated: a developer with admin permissions is not enough to validate the flow. It is necessary to verify what happens with a standard user, a read-only role, a member of another tenant, an expired account, a token with reduced scope, and a staging environment separated from production.

MCP server supply chain

Installing an MCP server means introducing a component that often has access to data and actions. It can be an npm package, a container, a binary, a local script, a remote service, or a SaaS connector. If the server is compromised, poorly maintained, downloaded from an unverified source, or misconfigured, the risk is not limited to its code: it concerns everything it can reach.

The MCP server supply chain must be managed with the same criteria used for critical application components. Provenance, maintainer, version, changelog, dependencies, license, known vulnerabilities, installation scripts, container images, and runtime configuration must be checked. A server used to read public documentation has different requirements than a server with access to GitHub, databases, cloud, or internal tickets.

For enterprise environments, an allowlist or a private registry reduces the risk of casual installations. Sensitive MCP servers should run in sandboxes or containers with limited network, filesystem, and secret access. Updates must be reviewed because a new version can change exposed tools, requested scopes, output, or behavior.

Logging, audit trail, and incident response

Without logs, MCP becomes difficult to govern. If the agent modifies a file, opens a ticket, reads data, or calls an API, the team must be able to reconstruct who initiated the session, which tool was called, with what parameters, what output was returned, what action followed, and what resource was touched.

Logging must be rich enough to support review and incident response, but it must not turn into a new point of exposure: tool inputs and outputs can contain sensitive data, tokens, or customer information, so redaction, retention, access control, and alerts on the most delicate tools are needed.

Events to monitor include write tool calls, access to secrets, reading of personal data, use of privileged tokens, cross-tenant calls, deploys, deletions, modifications to cloud policies, MCP server updates, and authorization failures. When something goes wrong, the team must be able to quickly disable a server, revoke tokens, rotate credentials, and identify the changes produced.

Human-in-the-loop that actually works

Inserting a human confirmation is not enough if the confirmation does not contain useful information. A generic message like “the agent wants to use a tool, do you confirm?” does not allow for evaluating risk, data, and effect. For sensitive actions, a readable confirmation is needed: tool, identity, resource, parameters, environment, type of action, output used as input, and expected consequence.

The level of confirmation must follow the impact. A read-only query on public documentation may require little friction, while a call that reads customer data, modifies roles, launches deploys, updates IAM, or writes to the database requires explicit review. For repetitive operations, predefined policies and approvals can be used, but only after limiting scope and environment.

A good human-in-the-loop is not meant to offload responsibility to the developer: it is meant to transform an implicit decision by the agent into a verifiable decision by the team. When the action touches production, real data, or enterprise systems, the review must be proportional to the risk.

What to check before go-live

Before taking an application or workflow that uses MCP into production, it is advisable to build a map of the tools: which MCP servers are installed, whether they are local or remote, who maintains them, what tools they expose, what data they read, whether they can write, whether they use OAuth, static tokens, or service credentials, whether they are separated by user, repository, tenant, and environment, and what logs they produce.

The second map concerns actions: which tools can modify code, tickets, databases, cloud, CI/CD, email, or client systems, which require approval, which have dry-run, which can be disabled in an emergency, and which are available even after the agent has read untrusted content.

The third map concerns trust boundaries. Where does the trust boundary pass between user, client, MCP server, OAuth provider, enterprise API, and final resource? What identity is used in each step? Is a token bound to the right resource? Is an action attributable to the correct user? Can one tenant influence another? Can a staging environment touch production?

MCP security checklist for coding agents

• Inventory MCP servers, tools, clients, environments, and owners.
• Classify tools into read-only, write, destructive, privileged, and sensitive.
• Verify OAuth, resource indicators, audience, scope, and absence of token passthrough.
• Apply least privilege per user, project, repository, tenant, and environment.
• Separate personal, technical, staging, and production credentials.
• Limit access to filesystems, repositories, secret managers, logs, and personal data.
• Validate tool inputs and outputs with strict schemas and allowlists.
• Test indirect prompt injection on tickets, documents, issues, emails, wikis, and web pages.
• Require explicit confirmation for write, delete, deploy, cloud, database, ticket, and email actions.
• Use sandboxes or containers for tools that execute code, commands, or access the filesystem.
• Log tool calls, parameters, output, user, session, resource, environment, and result.
• Prepare rollback, token revocation, credential rotation, and rapid server disabling.

When to involve ISGroup

An internal review may be enough for local experiments, read-only tools on non-sensitive documentation, or prototypes without real data. The risk changes when MCP enters a workflow close to the product: enterprise repositories, shared branches, databases, cloud, tickets, CI/CD, client systems, real users, or exposed environments.

If MCP or external tools access…	Main risk	Recommended control
Repositories, code, middleware, policies, scripts	Fragile application changes or logic bypasses	Code Review
Runtime tools, prompts, documents, agentic actions	Prompt injection, tool misuse, unvalidated output	Software Assurance Lifecycle
Agentic architecture, trust boundaries, identities, tokens	Weak authorization boundaries	Secure Architecture Review
Exposed web apps, APIs, or dashboards	Abuse from the outside after go-live	Web Application Penetration Testing
Cloud, IAM, secret managers, pipelines, databases	Excessive privileges or misconfiguration	Cloud Security Assessment

If tools influence code and middleware, you need to look at the diff. If the application is exposed, you need to verify real-world behavior via Web Application Penetration Testing. If the main risk is the agentic architecture, the priority is to review identity, authorization, trust boundaries, tokens, and logging. If the use of agents and MCP becomes stable in the development cycle, repeatable controls are needed over time.

Evidence to prepare for an audit

For an effective audit, you need the list of MCP servers, configurations, exposed tools, scopes, credentials used, environments, flow diagrams, and connected systems. You must indicate read-only and write tools, actions subject to approval, available logs, revocation mechanisms, sandbox policies, and any allowlists.

On the application side, you need repositories, branches, PRs generated or modified by agents, exposed APIs, roles, tenants, processed data, pipelines, cloud, databases, and integrations. If the agent reads tickets, documents, wikis, emails, or CRMs, you must clarify which sources are considered trusted and which are not. If MCP has access to production, it is essential to distinguish what it can do in staging and what it can do on real systems.

This evidence allows you to avoid generic checks. An audit on MCP must follow the complete chain: user, prompt, client, MCP server, authorization, tool, output, action, log, and final resource. Only then can you understand if an agent can transform manipulated input or a wrong decision into operational impact.

Frequently Asked Questions

• Is MCP safe to use in software development?
• MCP can be used safely if servers, tools, authorizations, tokens, sandboxes, and logging are designed correctly. The risk depends on what the agent can do: reading public documentation, modifying repositories, querying databases, and acting on the cloud are very different scenarios.
• What is the difference between MCP and a normal API integration?
• In a traditional integration, application code decides when to call an API and with what parameters. In an agentic workflow, the model can choose tools and parameters based on context, introducing specific risks regarding prompt injection, tool metadata, unvalidated output, autonomy, and audit trails.
• Does human consent eliminate the risk of agent tool misuse?
• It reduces the risk only if the confirmation shows useful information: tool called, identity, resource, environment, parameters, and expected effect. A generic confirmation is not enough for operations on data, repositories, cloud, tickets, or databases.
• Which MCP tools are the most delicate?
• Those that read sensitive data, access secrets, execute commands, modify files, write to databases, interact with cloud or IAM, open or close tickets, send emails, launch pipelines, or perform deploys.
• How do you test prompt injection in an MCP workflow?
• You prepare untrusted content in tickets, documents, issues, emails, or pages retrieved by the tool and verify if the agent treats them as data or as instructions. The test must also observe subsequent tool calls, not just the textual response.
• When is a Secure Architecture Review needed?
• When MCP connects agents to enterprise systems, cloud, repositories, real data, CI/CD, or multiple tenants. The review must verify identity, authorizations, scopes, trust boundaries, logging, isolation, and management of high-impact actions.
• When is a Code Review needed?
• When external tools influence code, middleware, policies, APIs, validation, secret management, scripts, or configurations. Code Review helps to understand if the agent has produced vulnerable changes based on untrusted output, prompts, or tools.

Sources and references

• MCP Understanding Authorization
• MCP Authorization specification
• OWASP MCP Top 10
• OWASP Top 10 for LLM Applications
• OWASP Code Review Guide
• OWASP SAMM