TL;DR: As 41% of code is now AI-generated or AI-assisted and 82% of developers use AI tools weekly, commit-level provenance has become the control that distinguishes trustworthy software changes from unverifiable repository noise, according to Beyond Identity. Cryptographic signing tied to verified identity shifts security from post-commit review to commit-time accountability.
At a glance
What this is: This is a blog analysis arguing that AI-generated commits require code provenance because repository controls built for human developers no longer prove who actually authored a change.
Why it matters: It matters because IAM, developer identity, and software supply chain teams need commit-level identity assurance before AI-driven code volume makes manual review and post hoc scanning insufficient.
Context
Code provenance is the control gap that appears when a repository can record a commit but cannot prove who, or what, created it. In AI-heavy development, the problem is not only volume. It is that identity assurance shifts from a human developer assumption to a mixed human-and-machine authorship model that existing Git and SSH practices were not designed to verify.
The article frames this as a software supply chain issue with identity consequences: commit authenticity, developer identity binding, and cryptographic attestations become part of the control plane. For IAM and platform teams, the relevant question is whether the commit trail can still stand up as evidence when code is produced by assistants, automation, or a human using an AI tool.
Key questions
Q: What breaks when commit identity is based only on Git metadata?
A: Git metadata can record a name or email, but it does not prove who actually authored the change. That leaves teams unable to distinguish a legitimate commit from a spoofed or stolen-credential commit. Once AI tools increase code volume, the gap becomes operational, not theoretical, because manual review cannot reliably restore source trust.
Q: Why do AI-assisted commits increase software supply chain risk?
A: AI-assisted development increases the number and speed of changes, which reduces the time available for human verification. The risk is not AI itself, but the possibility that unverified code reaches the repository before identity and provenance checks can stop it. That makes commit-time trust more important than post-commit inspection.
Q: How should security teams implement code provenance in developer workflows?
A: They should require cryptographic signing, verified identity binding, and branch protection that blocks unsigned or untrusted commits. Provenance checks need to happen before merge, because downstream scanning can detect defects but cannot prove origin. The control objective is to make authorship auditable at the point of entry.
Q: What should organisations do when software provenance and IAM are managed separately?
A: They should align commit signing, identity proofing, and credential lifecycle controls so the same identity governance model covers developer access and source integrity. If those functions remain siloed, the organisation may secure logins while leaving repository authorship unverified. Provenance only works when identity controls extend into the software delivery chain.
Technical breakdown
Why Git commit identity is not enough
Git records metadata, not trustworthy identity. The author field can be spoofed, and SSH keys only prove possession of a credential at the moment of use, not who the committer really is. That distinction matters because repository controls designed around human developers assume the person who authenticated is also the person who authored the change. In an AI-assisted workflow, that assumption collapses. Commit records therefore need cryptographic proof of origin, not just a name attached to a change.
Practical implication: treat commit metadata as audit context, not as identity evidence.
How code provenance creates verifiable authorship
Code provenance is the auditable link between a commit and a verified identity. It usually combines signing, hardware-backed credentials, and a trusted identity source so the repository can verify provenance at commit time. The point is not to stop AI-generated code. The point is to make the source of each change attributable and non-repudiable. That changes software security from after-the-fact inspection to pre-merge trust decisions, which is the only workable model when code volume makes line-by-line review unrealistic.
Practical implication: require cryptographic commit signing tied to enterprise identity before code can merge.
Why SLSA turns provenance into supply chain control
SLSA treats source integrity as a supply chain requirement, not an optional engineering preference. Its source track expects verifiable proof of who authored a change, which aligns code provenance with build trust and artifact integrity. That matters because once an unauthenticated commit enters the repository, downstream scanning cannot restore origin assurance. In other words, provenance is the gate, while build and scan controls are downstream evidence. If the gate is weak, the rest of the supply chain inherits ambiguity.
Practical implication: align repository controls and build attestations so source identity is verified before artifacts are produced.
NHI Mgmt Group analysis
Identity provenance is becoming the trust boundary for software delivery: When AI can generate substantial portions of code, the security question moves from whether code is syntactically valid to whether its origin is provable. Git and SSH were built for possession-based trust, not authorship assurance. That means software teams now need identity proof at commit time, not just vulnerability detection later. Practitioners should treat provenance as a first-class governance control, not a developer convenience.
Code provenance is the control that closes the authorship gap: The article correctly identifies that commit metadata does not equal identity assurance. A signed commit tied to a verified corporate identity creates a defensible chain from developer to repository to build artifact. That is especially important where AI tools participate in code creation, because the author and the operator are no longer guaranteed to be the same subject. The implication is that IAM must extend into the software delivery path.
SLSA makes provenance a supply chain obligation, not an optional hardening step: The source track requirement for verifiable authorship signals a broader market shift toward identity-aware software assurance. This is not just about preventing malicious code from landing in a repo. It is about being able to prove where code came from when procurement, compliance, or incident response requires it. Teams should expect provenance evidence to matter as much as scan results in future assurance reviews.
Hardware-backed signing is now part of developer identity governance: Phishing-resistant credentials are no longer only a human login concern. They are also the mechanism that can bind commit actions to a trustworthy identity event. The control objective is not merely stronger authentication, but a narrower space for false attribution and stolen-key abuse. Practitioners should fold commit signing into their identity architecture rather than leaving it inside developer tooling.
Code provenance should be treated as a lifecycle problem across human and machine authorship: As AI-assisted development normalises mixed authorship, provenance has to survive joiner, mover, and leaver events for both developers and the credentials they use to sign code. That is a governance problem, not only a cryptography problem. The implication for programmes is clear: source integrity fails when identity lifecycle and software supply chain controls are managed in separate silos.
What this signals
Code provenance is becoming an identity architecture requirement: Security teams that still treat repository trust as a developer-tool problem will struggle to prove authorship once AI participates in routine coding. The practical shift is from trusting the person who pushed the code to trusting the identity evidence attached to the commit.
Commit signing now sits alongside IAM as a governance control: The boundary between software delivery and identity security is narrowing. When source authenticity cannot be demonstrated, downstream controls inherit uncertainty, which is why provenance belongs in the same governance conversation as authentication, access, and lifecycle management.
For practitioners
- Enforce signed commits for all code changes Require every commit to carry a cryptographic signature before merge, and reject unsigned changes from protected branches.
- Bind developer credentials to verified corporate identity Use enterprise identity proofing and strong authentication so the signing identity maps to an accountable employee or approved system account.
- Separate author attribution from trust decisions Treat repository author fields as informational only and make provenance checks the control that decides whether code can proceed.
- Extend supply chain evidence into build workflows Carry provenance evidence into build and release stages so downstream artefacts remain traceable to the authenticated source commit.
Key takeaways
- AI-assisted code creation turns commit authenticity into a governance problem, because repository metadata alone cannot prove authorship.
- The article’s central control idea is provenance at commit time, which moves trust decisions earlier than traditional vulnerability scanning.
- Teams that connect identity proofing, signed commits, and build traceability will be better positioned to defend software supply chains under AI-driven development.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Developers and AI-assisted workflows rely on non-human signing and repo credentials here. |
| NHI-04 — Insecure Authentication | The article hinges on stronger proof of the committer’s identity than possession-only access. | |
| Recommendation — Bind commit actions to approved identities and prevent human misuse of signing credentials. Require phishing-resistant authentication for code-signing and repository access. | ||
| SLSA | Source track — Source provenance | SLSA source requirements directly match the article’s provenance and authored-by proof focus. |
| Recommendation — Adopt SLSA source attestations to verify where committed code came from. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Commit signing depends on strong credential lifecycle and authenticator governance. |
| Recommendation — Manage signing credentials with lifecycle controls and revoke compromised authenticators quickly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Stolen keys and unverified commits are central to the source’s software supply chain risk. |
| Recommendation — Monitor for stolen signing keys and suspicious commit activity that could enable source tampering. | ||
Key terms
- Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
- Commit signing: Commit signing is the process of attaching a cryptographic signature to a code change so it can be verified later. It is useful only when the signature is tied to a trusted identity and enforced by repository policy, otherwise it becomes weak evidence rather than strong assurance.
- Phishing-Resistant Credential: An authenticator that cannot be copied, replayed, or phished in the way a password can. For retail identities, it is typically device-bound or hardware-backed and can produce a signed event that proves the correct user or customer was present for the transaction.
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org