Yes. Any file that tells a coding agent how to behave, what it may run, or which hooks fire on its actions changes what the agent does on a developer machine. Give those files owners, require review for changes, and keep them in version control like source code.
What counts as an agent control file
Names differ by tool, so describe the function instead of the filename:
- Project instruction files that the agent loads at the start of a session.
- Settings files that list allowed commands or tools.
- Hook definitions that run scripts before or after agent actions.
- Tool server configuration that lists which servers to start and with what arguments.
- Shared prompt or skill libraries that teams copy between projects.
All of these live in the repository or in a home directory, and all of them can be edited by someone who is not thinking about security.
Why they are a risk surface
The MCP security guidance describes a case where an attacker places a malicious startup command in a client configuration, so that connecting a server runs attacker chosen code. That is a configuration file acting as an execution path. A hook script is similar by design: it runs commands automatically.
An instruction file is softer but still matters. A line granting blanket permission to run installs, or telling the agent to skip confirmations, quietly raises autonomy for every developer who opens the project.
Treat them like code
| Practice | How |
|---|---|
| Ownership | Add the files to the code owners list, with a security reviewer for permission related ones |
| Review | Required approval on changes, with the diff visible |
| History | Version control, no unreviewed local overrides in shared settings |
| Baselines | A standard, approved template new projects start from |
| Scanning | A check that flags broad permissions, disabled confirmations, and new servers |
| Notice | Alert when a pull request touches these files |
Review questions
When someone changes a control file, ask:
- Does this grant a new command, tool, or server? Is it needed?
- Does it turn off a confirmation or a check?
- Does it run a script? Read the script.
- Does it load content from the network at startup?
- Would this still be acceptable if a stranger wrote it?
The inherited config problem
A developer clones a repository, opens it with an agent, and the agent honors the project's instruction file and settings. That means a hostile contribution can influence the tools of everyone who pulls. Guard against it by having your tool ask for trust before honoring project level settings, by reviewing these files in dependencies you vendor, and by treating repositories from outside your organization as untrusted until read. Check whether your tools support a trust prompt and test it.
Keep an inventory
Search your repositories for the control files, count them, and note which differ from the approved template. This is a ten minute scan that often finds surprising permissions. Pair it with agent tool permission manifests so the intended permissions are written down once.
A short policy sentence
"Files that configure AI agents are executable policy. They are reviewed, owned, and versioned like code." If your engineering standards fit on a page, this belongs on it.
Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: reviewing a changed settings file
A pull request touches an agent settings file. The diff adds three lines:
| Line change | Question | Finding |
|---|---|---|
| Allow a package install command without prompting | Is it needed? | The project already pins dependencies, so installs should be reviewed |
| Add a hook that runs a script after each edit | What does the script do? | It calls a formatter, then uploads a report to an external host |
| Add a tool server entry with a startup command | Who maintains it? | A personal repository with no history |
The reviewer asks for three changes. Remove the auto install, because installs are in the always prompt tier. Replace the upload step with a local report. Remove the server entry until it goes through the vetting steps. The pull request is approved after revisions.
Notice how none of these lines would trigger a normal code scanner. They look like configuration. That is why they need a human reviewer who knows what each line grants.
A baseline template
Give new projects a starting file that encodes your policy. A good baseline:
- Lists allowed commands by name, with nothing broad.
- Leaves installs, new hosts, and pipeline edits as prompt required.
- Contains no hooks by default.
- References the approved server list rather than defining servers inline.
- Links to the policy page and names the owning team.
Keep the baseline in a shared template repository and update it through reviewed pull requests. Then a scan can flag projects that drift from it.
Detecting drift automatically
| Check | What it finds |
|---|---|
| Compare project settings to the baseline | Added permissions and removed prompts |
| Search for hook definitions | Scripts that run automatically |
| Search for tool server entries | Servers outside the approved list |
| Look at recent changes to these files | Who changed what and when |
Run these checks in continuous integration and on a schedule. Alert the owning team on any difference.
The trust prompt
When a developer opens a repository for the first time, a well designed tool asks whether to trust the project's own settings. Make sure your tool does, and set the default to not trusting. Cloning a stranger's repository and letting its configuration steer your tools is a risky habit, since the project author decides the permissions.
Policy sentence for developers
"Anything that configures an AI agent is executable policy. Changes are reviewed by the owning team, and permission changes are reviewed by security." Short rules like this are easier to follow than long ones, and they give reviewers permission to ask hard questions.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice where a check can flag changes to sensitive files.
Quick check
Are instruction files really a security issue?
They can be. A line that raises permissions or skips confirmations changes agent behavior for every developer on the project.
Who should own them?
The engineering team that owns the repository, with security review for anything that changes permissions or runs scripts.
Should personal agent settings be allowed to override team settings?
Only to be stricter. Where your tool supports layering, let personal settings tighten limits but not loosen them.
Sources
Last reviewed: 19 October 2026.
