So, the auditors just handed us a failure because we couldn't produce a verifiable approval record for a code change made by our CI/CD pipeline's automation agent. Apparently, "the service account made the commit" isn't an acceptable answer.
We have the standard setup: pipelines run as a non-human identity (like a GitHub App or a service account), they can auto-bump dependency versions, push build artifacts, or even apply hotfixes based on other approvals. The commit shows up under the agent's name. The logic is that the *merge approval* or the *pipeline trigger* was the real gate. But when asked to prove *who* authorized *that specific agent commit*, we're digging through disparate logs in Slack, Jira, and the CI system. It's a mess.
What I'm looking for is how teams are actually solving this in a way that satisfies checkbox-compliance (like SOC 2) without just giving a human service account to every bot. The vendor solutions I've seen either:
* Treat the agent as a "user" and force a separate approval on its actions (which defeats the automation),
* Or offer a glorified log aggregator that doesn't actually link the chain of custody.
Has anyone implemented something that provides a cryptographically sound, auditor-friendly link between a human approval and an automated agent's resulting code change? Specifically:
* How do you attribute the agent's commit to a human decision?
* Where do you store that attestation so it's immutable and part of the audit trail?
* Are you using a custom solution, or is there a tool that actually does this without being snake oil?
I'm skeptical of any platform that claims to "solve compliance" with more dashboards. I need to see the actual mechanism.
- Charlie
Trust but verify.
I've been reading up on this too, since we're getting ready for our own audit. Your point about the vendor solutions is exactly what I've seen. They either break the automation flow or just create another silo.
What about the approach of forcing the service account commit to include the approving human's identity in the commit message metadata, like a signed-off-by tag that's automatically populated from the merge approval? That at least creates a direct link in the git history itself, which is one source of truth.
Is there a reason that wouldn't work for the auditors, if you could clearly show the policy that the automation only runs after a human-approved merge?
It's a logical approach, but auditors often reject it because the metadata isn't cryptographically tied to the *action* itself. A `Signed-off-by` line is just text; it can be spoofed by the automation or added after the fact without a verifiable, time-stamped chain. The audit trail they want typically demands an immutable log where the human approval event *directly* authorizes the subsequent automated commit, with both events in the same system under a single transaction umbrella.
Your second question hits the core issue. Showing the policy is not enough; you must show an *enforced* and *logged* causal link. If your CI system can trigger a pipeline from a merge event without re-validating the approver's identity at that moment, the link is considered broken. The agent's commit is seen as a new, distinct action. Some teams address this by having the automation generate a commit but only after querying an audit API that returns the merge approval details, then embedding a *non-repudiable* token from that query in the commit. It's heavy, but it creates the direct proof.
CostCutter