A modern coding agent is no longer limited to completing a line of code. Depending on its configuration, it can read the repository, edit files, execute commands, query APIs, open issues, access databases, call external tools, and install dependencies.
This change alters the security question.
Previously, an AppSec team could concentrate much of its control on relatively well-known artifacts: code, dependencies, images, pipelines, and repositories. With agents connected to tools, skills, and MCP servers, some decisions now take place even before the code reaches a commit.
The problem is no longer just:
Is the code produced by AI secure?
It now also includes:
Can we trust the tools, instructions, permissions, and integrations that helped produce that code?
Why MCP Has Entered the AppSec Conversation
The Model Context Protocol (MCP) allows applications and agents to connect to external resources and tools through a standardized interface.
In practice, this can bring the agent closer to systems such as:
- Code repositories;
- Issue trackers;
- Databases;
- Internal APIs;
- Cloud services;
- Documentation;
- File systems;
- Terminals and development tools.
This capability is useful precisely because it allows the agent to act with more context. However, the same benefit increases the impact of an insecure configuration.
The MCP specification itself treats tools as a surface that requires caution. Its security documentation highlights risks related to authorization, token theft, confused deputy, redirections, and trust in integrations.
The Risk Is No Longer Theoretical
A research study published by Snyk in June 2026 analyzed nearly 10,000 development environments. Within the sample analyzed, 50.8% of developers had at least one MCP Server installed.
Among developers with MCP servers, 1 in 7 had at least one security finding.
This number should be interpreted correctly: it is vendor research based on the sample observed by Snyk itself, not a universal estimate of the entire market.
Even so, the signal is important. MCP, coding agents, and skills are already present in real-world environments at a scale large enough for AppSec to treat them as part of the development surface.
NIST's 2026 report on AI agent security found broad agreement among commenters that agents introduce specific risks and that traditional cybersecurity principles remain relevant, but need to be adapted to the agentic model.
Three Surfaces That Need to Be Governed
A practical way to organize the problem is to separate the risk into three questions.
1. What Does the Agent Use?
Before executing any task, the agent may depend on:
- MCP Servers;
- Tools;
- Skills;
- Plugins;
- Models;
- Libraries;
- Documentation;
- External services.
The organization needs to know where these elements came from, who approved them, what they can do, and how they will be updated.
A known MCP Server should not be treated as permanently trustworthy simply because it was approved once. Changes in version, maintainer, configuration, or backend can alter its risk.
2. What Can the Agent Do?
Permission is one of the main differences between a passive assistant and an agent.
Consider two scenarios:
- 01Restricted assistantreads code and suggests a change
- 02Human reviewdeveloper decides what to apply
In another scenario:
- 01Autonomous agentreads code and context
- 02Toolsexecutes terminal commands and calls APIs
- 03Dependenciesinstalls components
- 04Systemsaccesses cloud or repositories
- 05Deliveryopens PR and triggers pipeline
Both use AI, but the operational risk is completely different.
The greater the autonomy, the more important the following become:
- Least privilege;
- Segregation of duties;
- Token scope;
- Credential expiration;
- Human approval;
- Audit trail;
- Execution limits.
3. What Does the Agent Generate?
Even when tools and permissions are controlled, the generated code still needs to go through the normal engineering controls.
This includes:
- Review;
- SAST;
- SCA;
- Secret scanning;
- Testing;
- IaC analysis when applicable;
- Pipeline policies;
- Artifact validation.
The adoption of agents does not eliminate AppSec. It adds a new layer before the controls that already existed.
Prompt Injection Changes in Impact When the Agent Has Tools
Prompt injection in a chatbot without access to systems can produce an incorrect response.
In an agent connected to tools, the consequence can be greater.
A malicious instruction can be found in:
- External documentation;
- An issue;
- A comment;
- A web page;
- A tool description;
- A file inside the repository itself;
- Context returned by another integration.
If the agent interprets the instruction as a legitimate part of the task and has permission to act, the problem is no longer exclusively about content and starts to involve execution.
For this reason, agentic security cannot rely solely on “a better prompt.” It is necessary to combine technical authorization boundaries, source trust, action validation, and observability.
Dependencies Installed by Agents Deserve the Same Controls as Human-Selected Ones
Another point of attention is software installation.
A developer may consciously choose a library. An agent may recommend or install a dependency as part of a larger task.
In both cases, the package enters the same Software Supply Chain. Therefore, the rules should not depend on who executed the command.
- 01Requesthuman or agent requests a dependency
- 02Sourcevalidate registry, namespace, and identity
- 03Riskvulnerability, malware, policy, and trust signals
- 04Installationallow, block, quarantine, or review
- 05Buildexecute with controlled identity and permissions
- 06Evidencerecord version, source, and decision
Control needs to remain at the ingestion point and in the pipeline, not only in the intent of the user or the agent.
A Real Case: When MCP Enters the Supply Chain
In September 2025, Postmark reported a malicious npm package called postmark-mcp that impersonated a legitimate Postmark integration.
The package appeared legitimate across 15 versions. In version 1.0.16, it added a backdoor that secretly BCC'd emails to an external server.
The case shows that the risk is not limited to the agent's behavior or the permissions granted to a tool. The MCP Server used by the agent can itself become a compromised component of the software supply chain.
For AppSec teams, this expands the question from "what vulnerabilities exist in this component?" to "where did this component come from, who published it, what does it execute, and what resources will the agent be able to access through it?"
What AppSec Should Start Inventorying
Before purchasing a new tool, an organization can start with visibility.
Some simple questions:
- Which coding agents are authorized?
- Which MCP Servers exist on endpoints?
- Who can install new servers, skills, or plugins?
- Which systems can each integration access?
- Are permissions read-only whenever possible?
- Are tokens personal, shared, or specific to a workload?
- Is there expiration and rotation?
- Can the agent execute shell commands without approval?
- Do dependency installations go through the same repositories and policies as the rest of the company?
- Is there enough logging to reconstruct what the agent did?
- Does code created or modified by an agent go through the same gates as human-created code?
- Is there a simple process for quickly revoking an integration?
If these answers depend on each developer's memory, there is already a governance gap.
A Minimum Architecture for Corporate Use
There is no single valid design, but a defensible architecture tends to separate trust and execution.
- 01Approved agentknown identity and configuration
- 02MCP and toolscatalog, source, and controlled permissions
- 03Authorizationleast privilege and short-lived credentials
- 04Executionlimits and approval for critical actions
- 05Dependenciesingestion through corporate sources and policies
- 06Codereview and AppSec controls
- 07Pipelinebuild, evidence, and promotion
- 08Observabilitylogs, detection, and response
The goal is not to require manual approval for every simple action. It is to define which actions can happen automatically and which cross a risk boundary that requires additional control.
Agentic Security Should Not Become a Silo
There is a risk of creating a new isolated discipline called “AI Security” and repeating problems that AppSec has already learned to solve.
Identity, least privilege, trusted source, dependency validation, segregation, observability, and response remain relevant.
What changes is where these controls are located.
Part of the risk now emerges:
- In the developer's local environment;
- In the agent configuration;
- In the integration with tools;
- Before the commit;
- During automated decision-making.
Therefore, the most sustainable path is to extend the existing AppSec program to cover the new surface, rather than creating parallel governance without integration.
The Practical Test
Choose a coding agent used by the company and try to answer:
Which systems does it access, with which identity, through which tools, under which policies, and with what evidence?
If the answer cannot be obtained quickly, the problem is not necessarily the AI.
It is a lack of visibility into a new boundary of the Software Supply Chain.
Sources and References
- Model Context Protocol — Specification 2026-07-28
- Model Context Protocol — Authorization Security Considerations
- Model Context Protocol — Security Best Practices
- NIST — Summary Analysis of Responses Regarding Security Considerations for AI Agents
- OpenSSF — Securing Agentic AI
- Snyk Research — What nearly 10,000 developer environments reveal about agentic development risk
- Postmark — Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark
Does your AI-enabled development environment already have defined trust boundaries?
Xmart supports the assessment of architecture, governance, AppSec, and Software Supply Chain controls in modern development environments.
