Reviewing AI Coding Assistant Configuration Before It Runs

Configuration changes can give an AI coding assistant new instructions, tools, or commands to run on a developer’s machine. That makes the pull request a security checkpoint, even when the application’s source code hasn’t changed.

The Miasma campaign illustrates the risk. In an October 8 analysis of agent skill distribution, StepSecurity revisited a June campaign that placed AI tool and editor configuration in a Microsoft repository. The changes left application code untouched but were intended to trigger credential theft through developer tooling. StepSecurity reported that the commit used a skip-CI flag and a backdated timestamp, while shifting execution from package installation to opening a folder.

That shift matters operationally. A control that checks only build pipelines can miss behavior triggered when a developer opens a project. Teams need to know who reviews configuration that affects assistant behavior, what that review covers, and where the approved version can run.

Review the behavior, not the file extension

Assistant-related files can contain simple guidance, point to scripts, register tools, or configure commands to run at particular events. Their names and formats don’t tell reviewers enough. The key questions are what the configuration causes, when it takes effect, and what permissions it can use.

Markdown instructions aren’t executable by themselves, but they can guide an assistant that has permission to run commands. A JSON setting, by contrast, may register a shell command directly. Reviewers should trace the full path from configuration to action, including the trigger and the authority available at that moment.

Skills show how easily behavior can hide in a familiar format. StepSecurity notes that a skill’s allowed-tools field can let an agent use listed tools without a permission prompt during the turn in which the skill is invoked. Claude Code’s documentation also says workspace trust doesn’t gate that field. A SKILL.md file may look like ordinary project documentation, but its effect depends on how the assistant interprets and acts on it.

Claude Code’s hooks reference says command hooks run with the user’s permissions. It also describes a difference between interactive and noninteractive sessions: hooks in a repository’s settings files can run in a noninteractive session without the trust dialog an interactive user would see. Behavior depends on the configuration surface and how the assistant is launched. A setup that appears safe in a developer’s terminal may behave differently in an automated job.

The documentation outlines practical ways to limit exposure when running noninteractive sessions over repositories the team didn’t create: review their .claude settings files, use bare mode, or turn hooks off for that run. Administrators can set managed-hooks-only to block user, project, local, and plugin hooks. Teams should test the selected control in the sessions they actually use.

For each proposed hook, a reviewer should be able to follow the command to its script and dependencies. If the script downloads software, the review should establish how the source is chosen and checked. If it accesses the network or reads credentials, the author should explain why the setup task requires that access.

Assign owners and enforce the review

Engineering productivity teams often maintain shared assistant settings, while security teams can define which behavior changes need a second reviewer. Those might include adding executable hooks, expanding network access, or introducing an external tool. The application team still needs to decide whether the integration belongs in its workflow.

Clear thresholds can keep routine edits from becoming a bottleneck. A formatting preference may need a different review from a hook that contacts an external service or changes global user settings. Reviewers should receive a concise description of the trigger, permissions, and expected side effects.

GitHub’s code-owner rules can route changes to designated reviewers, but a CODEOWNERS file doesn’t require approval by itself. Branch protection must require the review, and GitHub recommends protecting the ownership file as well.

The review boundary should include both assistant configuration and every script it invokes. Requiring approval for a settings file while leaving its helper script outside the rule leaves the behavior exposed to unreviewed changes. Test the effective policy with a sample pull request to confirm the intended reviewers must approve it before merge.

Account for the developer’s full environment

Repository files are only one source of assistant behavior. Developers may also install shared skills, plugins, and user-level settings outside a project. As a result, a repository that has passed review can still run alongside configuration its maintainers haven’t seen.

Set a baseline for the supported tools and the ways teams launch them. Record approved additions and their versions, and make it possible to inspect the configuration that actually loads. If a local copy differs from the approved one, compare the contents before deciding what the difference means.

Visual Studio Code’s Workspace Trust guidance describes Restricted Mode, which limits features that can execute workspace content. The guidance also warns that a malicious extension can ignore that boundary. Trust controls can reduce some risks within their documented scope, but teams should pair them with an extension policy and an environment suited to the repository under review.

Unfamiliar repositories should run in an isolated environment that doesn’t routinely expose production credentials. A container can still inherit secrets or connect to the host, so teams need to inspect those links rather than assume the container provides isolation.

For regular work, a secure setup needs to be practical. Publish maintained configurations, document how developers can request additions, and provide a clean way to inspect unfamiliar projects. A process that requires everyone to rebuild their environment by hand each morning will be difficult to maintain.

Test the rules under real launch conditions

Teams can exercise their controls in a disposable repository and isolated environment. Add a benign hook that writes a marker file, then check whether the pull request reaches the right owner, whether an unapproved change can merge, and whether the installed assistant allows the action under the documented launch conditions.

Repeat the exercise through any noninteractive workflow the organization uses. Then change only the helper script the hook calls. That tests whether the approval rule follows the behavior as well as the configuration that points to it.

Record which controls stopped the action and which only generated a report. Scanners, required reviews, and runtime restrictions address different parts of the problem; a result from one shouldn’t be treated as proof that the others are working.

A useful first review can focus on three questions: Who can merge changes to files that steer the coding assistants? Does the review rule cover every script those files call? Which automated jobs run an assistant over code the team didn’t write, and do those jobs apply the same trust checks as a developer’s terminal?

Start with one supported assistant and one engineering team. Have them demonstrate who can change its behavior, how approval works, and what happens when someone attempts to bypass the process. The goal is a review path that catches execution changes before they reach developers, backed by an environment that stays within the approved scope.