A pull request adds a helpful setup step for an AI coding assistant. No application source changes. The description calls it a developer-experience improvement, and the reviewer sees a short configuration file beside some Markdown instructions.
Before approving it, the reviewer needs to answer a different question: what will this change allow to run on a colleague’s machine?
The issue has moved beyond hypothetical repository poisoning. In an October 8 analysis of agent-skill distribution, StepSecurity revisited the June Miasma campaign, which planted AI-tool and editor configuration in a Microsoft repository without modifying application source. The configuration was intended to trigger credential harvesting through developer tooling. The October publication describes an inventory product, but the underlying campaign illustrates a wider operational problem: merging a configuration change can distribute execution instructions to the people working in that repository.
StepSecurity also reports that the commit carried a skip-CI flag and a backdated timestamp, and that it moved code execution from package install to folder open. A control that runs only in the build pipeline never sees that path. The first reliable checkpoint is the pull request, and it needs a person who knows what the file can trigger.
I recommend giving these changes a named owner and an enforceable review path. An organization should be able to identify who approved a hook, what the approval covered and where the approved version is allowed to run.
Review the behavior behind the filename
A repository file can serve several purposes. It may describe a coding convention, direct an agent toward a script, register a tool or arrange for a command to run at a lifecycle event. Those differences matter more than the extension.
A Markdown instruction is not automatically executable code. It can nevertheless influence an agent that has permission to execute commands. A JSON setting may directly register a shell command. Review should establish the mechanism, the trigger and the authority available when it fires.
Skills show why the filename is a poor guide. StepSecurity notes that a skill’s allowed-tools field can let the agent use listed tools without a permission prompt during the turn that invokes the skill, and that Claude Code’s documentation says workspace trust does not gate that field. A SKILL.md file is Markdown, so in a pull request it tends to be reviewed like a README.
Anthropic’s current hooks reference states that command hooks run with the user’s permissions. It also distinguishes interactive workspace trust from noninteractive operation: settings-file hooks in a repository can run in a noninteractive session without the trust dialog shown to an interactive user. The exact behavior depends on the configuration surface and session type. A control tested at a developer’s terminal should therefore be retested in the automated workflow that uses the same repository.
The same page names practical mitigations. Before scripting a noninteractive run over a repository nobody on the team wrote, review its .claude settings files, start the run in bare mode or turn hooks off for that run. Administrators can also use the managed-hooks-only setting so that user, project, local and plugin hooks are blocked. Which of these fits depends on the organization’s tooling, and each should be tested rather than assumed.
For a proposed setup hook, the reviewer should be able to trace the command to its script and dependencies. If the script downloads another program, determine how that program is selected and verified. If it reads credentials or accesses the network, ask why the setup step needs those capabilities.
These questions should accompany the change while its author can explain the intent. Discovering them after distribution leaves every affected developer to make an individual trust decision.
Make ownership enforceable
Engineering productivity teams are often best placed to maintain shared coding-assistant configuration. Security should define the conditions that require a second reviewer, such as adding executable hooks, broadening network access or invoking a new external tool. The application team remains responsible for whether the integration belongs in its workflow.
This need not create an approval queue for every formatting preference. Define the behavioral changes that warrant scrutiny and route those changes to people who understand the tooling.
GitHub’s code-owner documentation explains how ownership rules work with required reviews. A CODEOWNERS file alone does not make its approval mandatory; the corresponding branch protection must require it. GitHub also recommends protecting the ownership file itself.
Apply the chosen mechanism to the agent configuration and the scripts it invokes. Protecting a settings file while leaving its referenced helper script outside the review rule creates an obvious gap. Check the effective rule with a sample pull request rather than relying on the presence of a policy file.
Allow legitimate changes to move quickly through a known path. The reviewer should receive a concise explanation of the trigger, required access and expected side effects. A hook that formats changed files should not need the same justification as one that contacts an external service or modifies a user’s global configuration.
Check what the developer environment actually loads
Repository review covers only part of the environment. Developers can also install shared skills, plugins and user-level configuration outside a project. An approved repository may therefore run alongside additional instructions that its maintainers have never reviewed.
Establish a baseline for the supported tools and launch methods. Record the origins and versions of approved additions, and provide a way to inspect the effective configuration. When local copies differ, compare the content before deciding that the difference is malicious or harmless.
Microsoft’s Workspace Trust guidance for Visual Studio Code describes Restricted Mode, which limits features that can execute workspace content. It also warns that a malicious extension can ignore that boundary. Workspace trust is a useful control within its documented scope; it should be paired with a deliberate extension policy and an environment appropriate to the repository being inspected.
Use unfamiliar repositories in an isolated environment without routinely mounted production credentials. Avoid treating a container as sufficient isolation if it inherits the developer’s secrets or access to the host. Review those connections explicitly.
For approved daily work, make the safe setup practical. Publish maintained configurations, explain how to request an addition and provide a clean inspection workflow. If compliance requires developers to reconstruct their environment manually every morning, it will be difficult to sustain.
Test the approval path before trusting it
Run a benign exercise in a disposable repository and isolated environment. Add a hook that writes a harmless marker file. Check whether the pull request reaches the intended owner, whether an unapproved change can merge and whether the installed tool permits the marker action under the documented launch conditions.
Repeat the exercise through the noninteractive route if the organization uses one. Then change only the referenced helper script. That second change tests whether the review boundary covers behavior as well as configuration.
The result should identify which controls prevented execution and which merely recorded it. A scanner alert, required review and runtime restriction perform different jobs. Record the gaps without presenting one as a substitute for all the others.
Three questions make a workable first review. Who can merge a change to the files that steer our coding assistants? Does that rule also cover every script those files call? Which of our automated jobs run the assistant over code we did not write, and do they apply the same trust checks as a developer’s terminal?
For security leadership, the useful measure is whether changes capable of altering execution reach the right reviewer before distribution, and whether the working environment matches the approved scope. Start with one supported coding tool and one engineering team. Ask them to demonstrate who can change its behavior, how that change is approved and what happens when someone tries to bypass the process.
No Responses