AI Coding Agents
Governance
Audit trails for coding agent changes
September 24, 2026 - 2 minute read
A coding agent audit trail should connect a requested change to the identity that executed it, the tools it used, the evidence it produced, and the human decision that allowed it to ship. A transcript alone is incomplete. It may show model output without proving which commit, checks, approval, or deployment followed.
OpenTelemetry describes a trace as a path through a system made of related spans. That model fits agent work when session events carry stable identifiers that can be correlated with source control and CI records. The goal is a chain of evidence, not unrestricted collection of every prompt and file.
Connect identity, intent, and execution
Start with the requester, execution identity, repository, target branch, task source, and session identifier. Preserve the task specification or issue link so an auditor can compare the requested scope with the resulting change. When work runs through a service account, record that identity separately from the person who requested the run.
Factory's remote delegation documentation makes this distinction explicit. Shared channel and issue delegations run as the configured service account, while the originating teammate remains the requester. That separation supports independent review and avoids attributing automated commits to an administrator who configured the integration.
Record tool and command outcomes at useful boundaries. High-risk attempts, blocked commands, file modifications, commits, and pull requests matter more than every internal reasoning step. Include environment and model identifiers when policy or reproducibility depends on them.
Correlate the change with validation and review
Attach the commit SHA, pull request, CI run, validation artifacts, review decisions, and deployment record to the same trace or case. A passing check should include its name, revision, timestamp, and result. Screenshots and videos need enough context to show the route and behavior they represent.
Factory's compliance and audit documentation describes two complementary sources. Factory-side audit logs cover cloud-managed administrative events. Customer-owned OpenTelemetry captures activity such as tool invocations, blocked commands, file modifications, commits, and pull requests with organization, session, and user attributes where configured.
Source-control controls remain part of the record. GitHub protected branches can require reviews and status checks before merge. The audit trail should preserve who approved the exact revision, not only that the pull request eventually reached a merged state.
Collect enough evidence without collecting everything
Define retention, access, and redaction rules before enabling detailed telemetry. Prompts, source snippets, command output, and test fixtures can contain personal data or secrets. OpenTelemetry's guidance for sensitive data recommends filtering or redacting data at collection and transformation points rather than trusting every downstream destination.
Factory lets organizations export telemetry to collectors they operate and choose aggregate granularity when per-user analytics are unsuitable. Message-content trace spans are opt-in and customer-only. Those controls support a narrow evidence policy that keeps operational facts while limiting content collection.
Test the audit trail with a reconstruction exercise. Select one agent-authored change and trace it from request through execution, validation, approval, and deployment. Note every manual lookup and missing identifier. Fix those gaps in the workflow, then repeat with a failed or blocked run so the record covers decisions that did not produce code.
