Stop coding agent settings from drifting by writing the approved baseline as a file in version control, enforcing it centrally where the tool allows, and comparing real machines to it on a schedule. Treat each exception as temporary with an expiry date. Drift is normal, so plan to detect it.
What drift looks like
A developer widens the command allow list to finish a task and never narrows it. A tool update adds a new capability that defaults to on. A teammate copies a settings file from a blog post. Six months later the pilot's careful configuration describes almost nobody's actual setup.
Four steps to control it
1. Write the baseline. Capture approved settings as a file: allowed commands, file scope, network allow list, approval rules, connected tool servers. Keep it in a repository with code owners, so changes need review.
2. Enforce centrally where you can. Some tools support organization level settings that users cannot override. Use them for the items that matter most, such as network limits and tool server lists. Where a tool lacks this, say so in your risk record and compensate with environment controls.
3. Check actual state. Collect the effective settings from machines or from the tool's admin view on a schedule, and diff them against the baseline. Weekly is a reasonable start for a pilot, monthly later.
4. Handle exceptions with an expiry. Record who asked, why, who approved, and when it ends. When it expires, the setting returns to the baseline unless renewed.
What belongs in the baseline
| Setting group | Examples |
|---|---|
| Filesystem scope | Project only, no home directory reads |
| Commands | Allow list, ask for others |
| Network | Registry and git host only |
| Tool servers | Approved list, no ad hoc additions |
| Approvals | Which actions prompt |
| Telemetry | Action records on, destination set |
| Version | Minimum approved version |
The version row matters. Tools get security fixes, and an old version is a setting too. Record a minimum and a review date.
Detect the unapproved
Discovery helps with tools you did not approve at all. Look at package manager records, extension inventories, network destinations, and expense claims. An amnesty with a simple path to approval beats a ban. See should we ban shadow AI or run an amnesty.
Make the right path easy
Settings drift partly because the approved setup is a hassle. Provide a one command setup that applies the baseline, and keep it current. If the baseline blocks a common task, change the baseline through review instead of waiting for people to work around it.
Report on it
A simple number helps: the share of checked machines that match the baseline. Report it with the top three deviations and their owners. Do not turn it into a punishment chart, or people will stop being honest about their setups.
Safeguard offers asset discovery and policies, and compliance and evidence automation for recording baseline checks.
Quick check
How often should the baseline change?
When tools change or incidents teach you something. Each change goes through review like code.
What if the tool cannot be centrally managed?
Document the gap, rely on environment controls, and weigh that gap when deciding whether to approve the tool.
Last reviewed: 19 October 2026.
