Versioning agent runtime configs is a compliance headache if you don't treat it like infrastructure. Auditors want to see a clear, tamper-proof chain of custody for any config that affects security controls (e.g., agent permissions, data handling rules, network allowances). Storing these as random JSON files in a shared drive will get you flagged.

You need three things:
* **Immutable, timestamped changes.** Every modification must be tracked with a diff, who made it, and a link to an approved change ticket.
* **A single source of truth.** No more "final-config-v2-revised.json." The runtime must pull from the versioned system.
* **Automated deployment evidence.** Proof that the config running in production matches the version you say is approved.

Here's the pragmatic approach: use Git (e.g., GitLab, GitHub) for the configs themselves, and use a proper pipeline to deploy them. Treat configs as code.

```
# Example repo structure
/agent-configs/
├── policies/
│ ├── data-filtering/
│ │ ├── prod.yaml
│ │ └── staging.yaml
│ └── permissions/
│ └── prod.yaml
├── .gitlab-ci.yml # Pipeline to validate & deploy
└── CHANGELOG.md # Manual audit trail summary
```

The common control gaps I see:
* **Lack of segregation of duties.** Developers can merge config changes that go directly to prod without a security review.
* **No integrity checking.** The runtime agent pulls a config, but there's no verification (e.g., a checksum) that it matches the approved version.
* **Missing rollback procedure.** If a bad config is deployed, the process to revert is ad-hoc and not documented.

Your CI/CD pipeline should enforce validation (schema checks, security policy checks) and require an approved ticket number in the commit message. The deployment step should generate an artifact—a log entry or a SIEM event—that ties the deployed config hash to the Git commit ID. That's your evidence for the auditor.