Code signing · Agentic AI · Software supply chain

Who Signs the AI’s Code?
Code Signing in an Agentic World

AI changes who—or what—can produce code, but it does not remove the need to establish who authorised that code, what produced it and whether the resulting artefact has changed.

The Central Argument

Traditional code signing largely answers two questions:

“Who published this software, and has it been altered since it was signed?”

AI-assisted development creates a harder set of questions. Who actually created the code? Who authorised its creation? Which AI agent or model was involved? What tools and repositories could it access? Who reviewed the output? And what exactly are we trusting when we sign the resulting artefact?

Imagine an autonomous coding agent that can move through an entire delivery chain:

Prompt → generate code → modify repository → invoke CI/CD → build → test → package → request signing → deploy

If an agent can traverse that chain, the code-signing service becomes one of the final control points between an AI-generated instruction and executable software.

Giving an agent unrestricted signing authority would be dangerous. A valid digital signature can identify the publisher and show that signed content has not been altered. It does not prove that AI-generated code is safe, correct, non-malicious or adequately reviewed.

What Code Signing May Need to Become

The future architecture may look less like:

Developer → Build → Signing Key → Signed Binary

and more like:

Human or AI agent → Controlled build → Verification → Policy decision → Attestation → Signing service or HSM → Signed artefact → Deployment

The signing decision could incorporate identity and provenance signals such as:

• The human sponsor and accountable owner
• The workload identity
• The repository and commit
• The controlled build environment
• The software bill of materials (SBOM)
• Security-test results
• The model or agent involved
• Approved tool permissions
• Human approval where the risk warrants it

“AI should not simply possess a code-signing credential. It should have to earn authorisation for each signing operation through policy.”

This is where PKI, HSMs, workload identity, short-lived credentials, software-supply-chain provenance, signing policy and AI governance begin to converge.

Why Provenance Must Be Verified

Provenance can record how an artefact was produced, which builder ran the process and which inputs were involved. But provenance is not useful merely because it exists. It has to be checked against an organisation's expectations before the artefact is trusted.

The design principle is broader than any one tool or standard: separate the ability to request a signature from the authority to approve one, keep signing keys behind a controlled service, and make the policy decision depend on verifiable evidence.

Agentic AI Makes the Question Sharper

We do not need artificial general intelligence for this problem. Agentic AI already makes it relevant.

If increasingly capable systems can independently design software, write it, test it, modify infrastructure and initiate deployment, cryptographic identity becomes part of the boundary between machine autonomy and organisational authority.

In the age of AI, code signing can no longer be treated simply as proof of software-publisher identity. It increasingly becomes a control over machine authority: determining which human, workload or AI agent is permitted to turn generated code into organisationally trusted software.

Accountability Cannot Be Delegated to the Model

If an AI agent introduces vulnerable code that subsequently receives an organisation's production signature, saying “the AI wrote it” is meaningless from a governance perspective. The organisation's cryptographic signature effectively says:

“We authorised this artefact.”

The future question is not merely, “How do we sign AI-generated code?” It is:

“What evidence should an organisation require before it allows an AI-generated artefact to inherit its cryptographic trust?”

One Practical Exercise

Choose one production signing workflow and run a tabletop exercise. Assume an AI coding agent can open a pull request, invoke the build and request a production signature. Then ask:

• Which identity makes each request?
• Which evidence is generated by the build rather than supplied by the requester?
• Which policy decides whether signing is allowed?
• Which actions require human approval?
• Can the signing service refuse the request without exposing the private key?
• Can an auditor later reconstruct who authorised the release and why?

Every answer that depends on an agent holding a long-lived credential—or on a human remembering to check something manually—belongs on the remediation backlog.

Sources

• Microsoft: Introduction to code signing
• NIST Secure Software Development Framework
• NIST SP 800-218A: Secure Software Development Practices for Generative AI
• SLSA specification, version 1.2
• Sigstore: Identity-based signing overview