Look for newly added SessionStart hooks, folderOpen tasks, always-apply rules, or repository-scoped files that launch shell commands without user confirmation. Repetition of the same hook pattern across multiple repos is a strong indicator of propagation rather than routine setup.
What makes a configuration look malicious rather than merely unusual?
Malicious assistant configuration usually stands out because it changes the assistant from a user-aided tool into an automatic execution path. Newly introduced hooks, rules, or repository-scoped instructions that run without confirmation are the clearest red flags, especially when they expand scope beyond the current project or silently persist across repos.
Context matters: a legitimate setup tends to be explicit, reviewable, and narrowly scoped. A malicious one often hides in places developers expect to trust, such as workspace metadata, agent instruction files, or config that appears to “improve productivity” while actually adding covert command execution.
Which config patterns deserve the closest review?
The highest-signal patterns are the ones that create unattended behavior. SessionStart hooks, folderOpen tasks, always-apply rules, and repository-scoped files that trigger shell commands are all worth immediate scrutiny when they were recently added or changed. The risk rises when the action is triggered by opening a folder, loading a workspace, or starting the assistant rather than by an intentional user action.
Also review whether the config introduces hidden reach into sensitive paths such as build scripts, credential stores, or environment files. If the assistant is being told to read broadly, act automatically, or chain multiple tools without a clear user prompt, the configuration is no longer just guidance, it is an execution policy.
Repetition across repositories is especially important. When the same hook pattern appears in multiple codebases, it suggests propagation, templating, or supply-chain style reuse rather than a one-off developer convenience. That makes the config more suspicious even if each individual file looks superficially ordinary.
What evidence separates benign automation from abuse?
Look for intent, placement, and blast radius. Benign automation usually has a clear operational purpose, lives in a known project convention, and is limited to low-risk actions. Malicious config often lacks documentation, arrives near a suspicious commit or dependency change, and aims to launch commands, exfiltrate data, or alter other assistant behavior without clear approval.
One useful test is whether the assistant would still behave safely if the file were opened by a fresh user who had never opted into that automation. If the answer is no, the configuration is using trust in the workspace or repo as the control plane. That is a common abuse pattern in AI Coding Agents Security Guide guidance, where instruction files and agent context can quietly expand execution authority.
Another tell is hidden coupling to credentials or cloud access. A config that appears to be about productivity but actually runs with developer tokens, local shells, or repository secrets should be treated as a security event, not a workflow tweak. For examples of this pattern, see Amazon Q MCP config vulnerability 2026 and Sentry MCP Agentjacking 2026, both of which show how configuration and tool output can be turned into execution paths.
Risk and Threat Considerations
Malicious assistant configuration is risky because it abuses trusted local context. Once a hook or rule is embedded in a repo or workspace, it can repeatedly trigger on open, sync, or agent startup, which makes the abuse durable and hard to notice in normal development flow.
Failure mechanism: An attacker plants or modifies assistant configuration so the tool automatically runs shell commands, broadens its scope, or follows hidden instructions whenever a developer opens the repository or starts the assistant.
Impact: The result can be credential theft, code tampering, unauthorized tool execution, and lateral propagation across repositories when the same pattern is copied or templated into other projects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Assistant config can expand tool and shell authority without confirmation. |
| ASI02 — Tool Misuse | Hooks and tasks can misuse tools to run commands or alter files unexpectedly. | |
| ASI10 — Rogue Agents | Repeated malicious config across repos can create persistent unauthorized assistant behavior. | |
| Recommendation — Restrict automatic execution paths and require explicit approval for new assistant privileges. Validate every tool invocation path and block hidden command execution in assistant config. Detect and remove unauthorized autonomous behaviors embedded in agent instructions. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Repo-scoped assistant config is code-adjacent and needs secure review before execution. |
| Recommendation — Review repository configuration changes with the same rigor as application code changes. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | New hooks and rules are configuration changes that need authorization and review. |
| AC-6 — Least Privilege | Malicious assistant config succeeds by granting broader execution than necessary. | |
| Recommendation — Approve and track assistant configuration changes before they can affect execution. Limit assistant execution privileges to the minimum required for the task. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Repository configuration that triggers commands is part of secure software design and review. |
| Recommendation — Treat assistant-triggering config as part of the application attack surface during review. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Shell commands launched from hooks map directly to command execution behavior. |
| Recommendation — Hunt for unexpected interpreter launches from workspace or repo configuration. | ||
Practitioner Guidance
What to verify: Treat any newly introduced assistant hook or always-apply rule as privileged code. Verify who changed it, why it exists, whether it was reviewed, and whether it is supposed to execute before any user confirmation.
What good looks like: Legitimate automation is narrow, documented, and easy to disable. It should not silently launch shells, access secrets by default, or survive copy-paste into unrelated repos without an explicit review step.
Practitioner takeaway: The most important judgement is not whether the config is “clever”, but whether it expands execution authority beyond what the developer knowingly approved. If it does, treat it as a security control failure until proven otherwise.
Related resources from NHI Mgmt Group
- Who is accountable when untrusted project configuration changes what an AI assistant sees?
- Who is accountable when an AI assistant follows malicious repository instructions?
- How can security teams tell whether AI assistant configuration is being abused?
- What are the signs that an AI assistant's command approval model is failing in practice?