Your team has reviewed an AI-assisted change, the tests are green and the deployment is ready. Six months later, can another engineer show which dependency versions went into the release and independently establish that the delivered artefact came from the source revision you approved? That is a different question from “Did someone review the code?”
The Australian Signals Directorate’s September 2026 Information Security Manual (ISM) software-development guidelines explicitly cover human, AI-assisted, AI-powered and AI-driven work. Two September controls make release provenance particularly concrete: ISM-2154 calls for software artefact dependencies to be pinned to approved versions in source code, and ISM-2155 calls for reproducible build practices that enable independent verification that release artefacts came from the stated source. Both are marked “Updated: Sep-26” in the ASD’s published guideline PDF. This is not a claim that the entire ISM is new, or that every private business is automatically subject to every control. An agency and its supplier should agree which controls and evidence apply to their system and assurance obligations.
A passing pipeline is not a provenance trail
A build can pass while a package is resolved from a moving version range, a base image is pulled by a mutable tag, or a deployment is promoted from an artefact different from the one tested. An AI coding assistant may accelerate a change, but it does not make those inputs immutable or prove what was shipped. The useful design question is: what evidence would let a person outside the build team trace a live release back through its artefact, build inputs, source and approval?
Start with one real service and one release, rather than announcing a fleet-wide “compliance” programme. Record the source revision, linked change request, approved dependency lockfiles and container/image digests where relevant; produce a build artefact with an immutable digest; retain the pipeline result, security-test results and deployment receipt tied to that digest. A software bill of materials (SBOM) helps consumers understand components, but an SBOM alone neither pins build inputs nor proves source-to-artefact correspondence. The ISM discusses SBOMs separately, including ISM-1730 on making one available to software consumers.
Make an independent check possible
- Pin the inputs. Use committed lockfiles and approved versions for third-party packages; use immutable container digests rather than floating tags where the build depends on containers. Keep deliberate update paths so pinning does not mean freezing vulnerable components forever.
- Capture the chain. Link the change or issue, reviewed source revision, build configuration, build run, test results, generated artefact digest and deployed release. Protect the authoritative source and pipeline permissions so this evidence is meaningful, not merely decorative.
- Test reproducibility honestly. Rebuild in a controlled independent environment using the same declared inputs and compare artefact digests where byte-for-byte builds are feasible. If timestamps, signing or generated metadata make exact equality impractical, document the non-determinism and the alternative verification method; do not label an untested build “reproducible”.
- Rehearse the handover. Give a reviewer outside the release team the source revision and deployed artefact digest. Ask them to trace the rest without relying on an engineer’s memory or a screenshot of a green dashboard. Record any broken links as work for the next release.
The same guideline covers segregation of development and production environments (ISM-0400), issue traceability (ISM-2025), secret scanning at commit time (ISM-2030), and testing before releases (ISM-0402). These support a credible release trail; they are not replaced by a single AI-generated checklist. ASD also says AI models can augment security testing, not replace traditional tests, with findings validated by appropriately skilled people.
Where a delivery partner can help
For a government digital team or its delivery partner, a scoped first engagement could map one application’s current build and release path, identify where mutable dependencies or untraceable promotions enter, and implement a repeatable evidence packet for the next deployment. That is concrete work across software engineering, cloud/DevOps and AI-assisted delivery—not a claim of panel membership. NAITEC’s digital services include custom development and cloud/DevOps, and its government work spans web and AI projects. If your team needs to make one release independently traceable, talk to NAITEC about that service and its existing procurement route.
Sources: ASD’s September 2026 ISM software-development guidelines and June 2026 edition for comparison. This is practical engineering guidance, not a certification or legal interpretation.