TL;DR: Two pre-trust execution flaws in Claude Code could let a malicious repository trigger arbitrary code before the trust dialog, according to Sonar. The case shows that agentic AI security still depends on classic configuration hygiene, not just prompt-injection defenses.
At a glance
What this is: Sonar reports that two pre-trust code execution flaws in Claude Code allowed malicious repositories to bypass the trust dialog and run arbitrary commands on a developer system.
Why it matters: This matters because AI coding agents inherit the security properties of the surrounding developer environment, so configuration trust, startup sequencing, and guarded execution paths become governance issues for AI agent programmes as well as traditional software tools.
Context
Claude Code is a developer-facing AI coding tool that becomes materially riskier when it can read project files, inspect repository metadata, and execute helper commands before a trust decision is enforced. The security gap is not exotic prompt abuse but unsafe pre-trust behaviour in the local execution environment.
In agentic workflows, the boundary between the AI system and the developer workstation matters as much as model behaviour. If configuration files or project settings can trigger code before approval, then the control objective shifts from after-the-fact detection to hard-gating dangerous actions before they start.
Key questions
Q: What breaks when AI coding agents can act before a trust prompt appears?
A: The security boundary breaks because the human approval step is no longer the first meaningful control. If the agent can load configuration, call APIs, or send data before consent, then prompt-based approval becomes advisory rather than preventative. Teams need controls that operate before execution begins, not after the agent has already touched sensitive resources.
Q: Why do configuration files create risk in AI coding agents?
A: Configuration files can behave like executable input when they influence helper processes, Git behaviour, hooks, or startup scripts. In AI coding tools, that matters because the agent often processes repository data before a user has trusted the workspace, so the file itself becomes part of the attack surface.
Q: How do security teams know if AI quality gates are actually working?
A: A useful gate should catch the same regression before merge that would otherwise show up in production. If failing traces are routinely converted into tests and future pull requests are blocked by those tests, the gate is doing real control work. If the same errors keep reappearing, the control is only reporting, not governing.
Q: Should organisations treat AI agent permissions differently from normal developer tooling?
A: Yes, because AI agents often combine file access, command execution, and repository context in one workflow. That increases the blast radius of a trust bypass, so permission scope, startup sequencing, and local execution paths need to be governed as a single risk surface rather than separate implementation choices.
Technical breakdown
Pre-trust command execution in developer tools
Claude Code’s trust model depends on a simple premise: the tool should not execute risky repository-driven behaviour until the user approves the workspace. The article shows how that premise failed when Git metadata and local settings were processed before the dialog appeared. In practice, that means a tool can appear to be permission-gated while still reaching code paths that run commands, query repository state, or spawn helper processes. This is a sequencing problem, not a novel AI problem, which is why it is easy to miss during agent design reviews.
Practical implication: Treat pre-trust startup paths as security-critical code and block any repository-supplied execution until explicit approval is complete.
Why git config and project settings can become execution vectors
Git supports local configuration entries that can influence command behaviour, including options that point to external programs. If a tool invokes Git commands in an untrusted folder before trust is granted, those commands can trigger arbitrary execution through configuration values in the repository. The article also shows the same pattern inside the tool’s own project settings, where startup scripts and hooks run from local JSON configuration. The technical lesson is that configuration is often operational code, especially in agentic tooling where helper commands are common.
Practical implication: Review repository and local configuration as executable input, not as passive metadata.
Agentic workflows widen the blast radius of old trust bugs
AI coding agents do not create new classes of filesystem or command-line risk, but they widen the impact of old assumptions because they sit closer to code, credentials, and developer context. When a tool has access to repositories, shells, and local settings, a single trust bypass can become a full workstation compromise rather than a narrow application defect. That makes the surrounding identity and authorisation model important: the agent must inherit only the minimum access needed, and privileged operations should wait for an explicit trust boundary to be crossed.
Practical implication: Constrain agent privileges and defer any command-bearing capability until the workspace trust decision is enforced.
Threat narrative
Attacker objective: The attacker’s objective is to run arbitrary code on the victim developer’s machine before trust is granted, turning a malicious project into a workstation compromise.
- Entry occurs when a developer opens an untrusted repository or project folder with Claude Code running inside it.
- Credential or command access is gained through pre-trust processing of repository Git settings or local Claude project settings that can invoke external commands.
- Privilege escalation occurs when those commands execute before the trust dialog, giving the attacker code execution on the developer machine.
- Impact is full compromise of the developer environment, including potential exposure of local credentials, source code, and adjacent development systems.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Pre-trust execution is the real governance failure: the bug is not that Claude Code can run commands, but that dangerous commands were reachable before the trust decision became effective. That breaks the basic assumption that user approval is a hard gate. For agentic AI governance, the control question is whether any repository-controlled input can trigger code before the workspace is trusted. Practitioners should treat the startup sequence as a security boundary, not an implementation detail.
Old configuration hygiene now sits inside AI agent risk management: the article is a reminder that agentic AI inherits decades of developer-tool attack surface, including Git config, hooks, and local project settings. The named concept here is pre-trust execution exposure, which is the point where a tool consumes attacker-controlled configuration before policy can intervene. That failure mode belongs in AI agent governance reviews as much as in endpoint and developer tooling hardening. Teams should assume configuration files can be hostile until proven otherwise.
Identity and authorisation controls still matter around AI agents: a coding agent with broad local access turns a trust bypass into a high-value access problem because the agent often sits near credentials, repositories, and build pipelines. This is where NHI and agentic AI governance intersect: the agent’s own permissions, the local environment’s trust model, and the command execution path all need separate controls. The practitioner conclusion is simple: if the agent can run before trust, the authorisation model is incomplete.
Prompt injection is not the only AI security story: this case shows that attention on LLM-specific attacks can obscure more conventional weaknesses in execution flow and configuration parsing. The named concept is configuration-triggered agent compromise, and it matters because it produces a compromise path that does not depend on model manipulation at all. That means security teams need both AI-specific safeguards and classic secure development controls. The practical outcome is to review agent startup behaviour with the same scrutiny applied to any privileged local tool.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Pre-trust execution exposure: the practical governance problem is not model behaviour alone, but whether attacker-controlled repository content can trigger commands before a trust decision is enforced. That boundary needs to be explicit in coding-agent policy, otherwise the agent becomes a vehicle for workstation compromise rather than a controlled assistant.
AI coding agents should be assessed as privileged local software, not just as model wrappers. Their risk profile depends on startup sequencing, repository parsing, and helper execution paths, which means agent governance and developer workstation controls now overlap in the same operating model.
For practitioners
- Enforce a hard pre-trust execution boundary Move every command-bearing or helper-loading action until after explicit workspace trust is confirmed, including startup scripts, repository inspection, and local settings parsing.
- Audit local configuration as executable input Review Git config, hooks, project settings, and environment helpers as potential code paths, then disable any repository-controlled execution in untrusted folders.
- Limit agent privileges before approval Run coding agents with the narrowest possible local permissions so a trust bypass cannot immediately reach credentials, shells, or development secrets.
- Test trust gates against real startup paths Reproduce how the agent behaves on first launch in a malicious repository, including command invocations that happen before the user accepts the trust prompt.
Key takeaways
- Claude Code’s trust bypass shows that agentic AI security still fails when classic configuration flaws are left reachable before policy gates are applied.
- The issue is operational, not theoretical, because repository-controlled settings can turn a trusted developer workflow into arbitrary command execution.
- Hard-gating startup behaviour, repository metadata, and helper scripts before trust is granted is the control that limits this class of compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The trust gate functions as an authentication boundary for workspace access, which the flaw bypassed. |
| NHI-10 — Human Use of NHI | The agent operated with human-mediated approval but still executed attacker-controlled paths before confirmation. | |
| Recommendation — Enforce workspace trust as a mandatory control boundary before any command-bearing action can run. Separate human approval from execution paths so local configuration cannot act before explicit trust. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The agent’s effective privilege expanded through pre-trust command execution and local project settings. |
| Recommendation — Limit agent privilege escalation paths that arise from repository-controlled startup behaviour. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Successful pre-trust code execution can lead directly to credential access and movement within the developer environment. |
| Recommendation — Map agent startup abuse to credential-access and lateral-movement techniques in your detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether execution permissions are enforced before untrusted content is processed. |
| Recommendation — Apply PR.AA-05 to ensure untrusted workspace content cannot gain execution rights before approval. | ||
Key terms
- Pre-Trust Execution: Code or commands that run before a user has approved a workspace, repository, or project context. In agentic tools, this creates a hidden execution channel because safety prompts arrive too late to block malicious configuration or helper logic.
- Trust Dialog: A user prompt that asks whether to trust a folder, repository, or other workspace before an agent acts on it. In practice, it is only effective when it clearly describes the permissions it grants. If the dialog is vague or hides the real effect, it cannot serve as a reliable security boundary.
- Configuration-triggered code execution: A failure mode where settings, hooks, or repository metadata cause a program to run commands as part of normal operation. In agentic tools, these paths are dangerous because the configuration itself may come from an untrusted project.
- Agent startup path: The sequence of actions a software agent performs when it first opens a project or session, including loading settings, inspecting files, and invoking helper commands. If that path is not tightly gated, it can become an attack surface before policy enforcement begins.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect agent permissions, machine identity governance, and secrets management to the controls their programmes already depend on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org