Config-to-exec surfaces in developer tools are the real AI risk

At a glance

What this is: This analysis argues that config-to-exec surfaces across developer tools, not MCP alone, are the real AI-era execution risk.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern AI agents and developer automation that can turn repository content into privileged local execution.

By the numbers:

• The report cites zero-click prompt injection to local RCE in Windsurf, identified as CVE-2026-30615.

👉 Read ARMO’s analysis of config-to-exec risk in AI-era developer tools

Context

Config-to-exec surfaces are files or settings whose contents are treated as commands by tools on a developer machine. The article’s core point is that this pattern predates MCP and already exists in hooks, dev containers, package scripts, and editor tasks, which makes the primary security problem governance of execution trust rather than a single protocol flaw.

For IAM, PAM, and NHI programmes, the intersection is real because AI coding agents and developer automation can write files that trigger local execution, persist on endpoints, or reach external services with credentials. That means the control problem spans human review, machine identity, and runtime authorisation, not just code scanning. The article’s starting position is atypical only in how clearly it separates protocol rhetoric from actual execution risk.

Key questions

Q: What breaks when config files can trigger shell execution in developer tools?

A: The security boundary breaks when a file that should describe settings instead becomes a command channel. A repository clone, dependency install, or folder open can then lead to local code execution, persistence, or credential exposure. The failure is not the file format alone, but the lack of a reliable trust gate between untrusted content and operating-system execution.

Q: Why do AI agents make config-to-exec surfaces riskier for enterprises?

A: AI agents can write or modify files faster than humans can review them, then trigger those files through normal tooling. That compresses the attack window and bypasses assumptions built around human intent. The result is delegated authority without sufficient containment, which creates both identity and endpoint risk.

Q: How should security teams measure whether trust controls are actually working?

A: Security teams should measure trust controls through a small set of operational indicators that show scope, compliance, lifecycle performance, and anomaly trends. The key is to pair each metric with an owner and a response threshold so the number drives action rather than reporting theatre. If a metric cannot change a decision, it is not a control indicator.

Q: Who is accountable when an AI agent plants a host-executed task file?

A: Accountability should sit with the team that defined the agent's allowed write and execution boundaries, not only with the end user. If the platform permits agent-written configuration to trigger host execution, the control owner has failed to separate content generation from execution trust. That is a governance design issue, not just an operational mistake.

Technical breakdown

Config-to-exec surfaces in developer tooling

Many developer tools treat configuration as executable intent. JSON files, hooks, package scripts, and editor task definitions are parsed and then handed to the operating system, which is why a change in a repository can become a command on the host. The technical issue is not the file format itself, but the trust boundary crossing from untrusted content to shell execution. MCP, Jupyter kernelspecs, Dev Containers, npm scripts, Git hooks, and Docker plugins all follow variations of the same pattern, with different approval gates and different amounts of friction before execution.

Practical implication: Map every file that can become execution and treat it as a privileged control surface, not just a configuration artifact.

Why trust gates differ so much across tools

The difference between a tolerable surface and a dangerous one is usually the strength of the trust gate. Some tools revalidate on content change, others rely on one-time workspace trust, and some expose no trust prompt at all. That matters because the real question is not whether a command can run, but whether a human or policy re-approves the command when the underlying file changes. In agentic workflows, the trust gate must survive automated edits, repository cloning, dependency installs, and repeated execution without assuming the first approval still applies.

Practical implication: Prefer controls that re-check content integrity on every meaningful change, not only at first use.

Why AI agents expand the attack path

An AI agent can write to files that were originally intended for human-authored configuration, then trigger them through normal developer workflows. That turns prompt injection, untrusted repository content, and dependency abuse into a local execution chain. The risk is amplified when the agent has write access to hooks, container configs, plugin directories, or shell-invoking package metadata. In practice, this is an identity and privilege problem as much as an application-security problem, because the agent is acting with delegated authority that can outlive the original task context.

Practical implication: Constrain what agents can write, where they can write it, and what execution paths they are allowed to trigger.

Threat narrative

Attacker objective: The attacker wants to convert trusted developer workflows into host-level execution and persistence that can be used for theft, propagation, or supply-chain compromise.

1. Entry occurs when a developer opens a repository or accepts AI-generated edits that place malicious content into config-to-exec surfaces such as tasks, dev containers, scripts, or hooks.
2. Credential or command execution follows when the tool parses that content and passes it to the operating system, turning a trusted file into shell activity on the host.
3. Impact is local code execution, persistence, credential exposure, or downstream compromise of the developer workstation and connected software supply chain.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Config-to-exec is the more useful concept than MCP vulnerability: the real governance problem is any file or setting that becomes shell execution after parsing. That category includes repository files, dependency scripts, editor tasks, dev containers, and plugin directories, which means the risk surface is much larger than one protocol. Practitioners should manage execution trust as a cross-tool control plane, not a product-specific exception.

AI agents expose the delegated-authority gap in developer tooling: human review assumptions fail when an agent can author, modify, and trigger command-bearing files faster than a person can inspect them. That creates an identity and privilege problem because the agent is effectively acting with borrowed authority across local execution boundaries. NHI governance, PAM-style restrictions, and scoped write access now need to extend into developer workstations and automation pipelines.

The trust gate, not the file format, is the decisive control: some surfaces re-prompt on content changes, some rely on workspace trust, and some have no meaningful gate at all. That variation explains why similar-looking files can have very different risk profiles. The field should stop debating whether a given format is inherently vulnerable and start standardising approval, revalidation, and runtime lineage controls across every execution surface.

Runtime visibility becomes the backstop for everything upstream misses: if a JSON parser spawns a shell, the decisive evidence is process lineage, not the file extension. That is why execution telemetry, endpoint controls, and policy around high-risk directories matter even when a tool claims the behaviour is expected. Practitioners should assume the attacker is looking for the least supervised config-to-exec path, then close the ones that can silently persist.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Forward look: Read OWASP Agentic AI Top 10 for the control patterns most relevant to agent write access and execution trust.

What this signals

Config-to-exec governance will become a standard part of agentic AI security programmes. The more AI agents participate in development workflows, the more organisations will need controls for write scope, execution gating, and runtime lineage across endpoints. NIST Cybersecurity Framework 2.0 remains a useful organising layer for this work because it forces teams to connect governance, protection, detection, and response.

Agent identity is becoming a workstation security issue, not just a platform issue. When an agent can create scripts, hooks, or container files, its effective privilege reaches beyond the repository. That is where identity governance meets endpoint and developer platform controls, and where programs should start treating write permissions as an access-management problem.

The strongest programmes will treat approval as perishable. A trust decision made at clone time should not automatically survive later file edits, new dependencies, or agent-driven modifications. If your process cannot explain who approved a command-bearing file, when it was revalidated, and what runtime actions followed, the control is not mature enough for agentic workflows.

For practitioners

• Inventory all config-to-exec surfaces Create a controlled list of every repository, editor, package-manager, container, and plugin path that can trigger command execution on developer endpoints. Include .vscode/tasks.json, .devcontainer/, .git/hooks/, package.json scripts, .docker/cli-plugins/, and any agent-managed config files.
• Restrict AI agent write paths Deny AI coding agents write access to hook directories, plugin folders, and shell-invoking project files unless a specific task requires it. Use least privilege so delegated automation cannot turn a prompt into persistent execution.
• Revalidate trust on file change Prefer mechanisms that re-check integrity when a configuration file changes, rather than relying on a one-time approval. Content-hash-based gates reduce drift and help prevent stale trust from surviving later edits.
• Monitor process lineage from parsing apps Alert when JSON- or config-parsing processes spawn shells, installers, or networked child processes. Runtime detection should treat that lineage as a high-signal event even if the tool’s behaviour is documented.

Key takeaways

• The article’s central warning is that config-to-exec paths across developer tooling matter more than the MCP label attached to one of them.
• The evidence points to a broad attack surface, including zero-click local RCE, poisoned registries, and multiple Critical and High CVEs across developer tools.
• Teams should respond by narrowing write paths, revalidating trust on change, and monitoring runtime lineage wherever configuration can become execution.

Key terms

• Config-to-exec Surface: A configuration file, hook, or metadata path that a tool interprets as executable instructions. The security risk appears when untrusted content crosses into command execution without a fresh trust check or containment boundary.
• Trust Gate: The approval step that determines whether a tool should execute content drawn from a file, repository, or agent action. Strong trust gates revalidate on change, record the decision, and limit what the approval actually authorises.
• Execution lineage: Execution lineage is the path that shows how a dependency moves from source code or build input into runtime use. It connects inventory to behavior, which is what security teams need when deciding whether a component is merely present or actually capable of creating risk.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full article

ARMO's full blog post covers the operational detail this post intentionally leaves for the source:

• The article's per-surface comparison of trust gates across MCP, dev containers, hooks, and package scripts
• The specific CVE references and tooling examples that illustrate each execution path
• The discussion of how prompt injection interacts with developer workstation trust decisions
• The practical hardening recommendations the author proposes for developers and AI-agent workflows

👉 The full ARMO post covers the attack surfaces, trust-gate comparisons, and hardening guidance in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps practitioners connect delegated access decisions to the controls their programme already owns.