Actor and owner
Agent, workflow, job, script, or tool plus the accountable human owner and owning team.
CAISI
Independent research and operating notes on AI Software Delivery Control.
Reference / Audit evidence
Audit Evidence for AI-Assisted SDLC
If a reviewer asks for audit evidence for AI-assisted software delivery, a model name or policy screenshot is not enough. The useful evidence shows what acted, who owned it, which credential was used, what action was requested, what target was touched, what approval applied, which validation ran, and what outcome remained.
This page defines a practical proof packet for AI-assisted SDLC, meaning the software development lifecycle where AI-assisted workflows can participate in code, review, CI/CD, tooling, packaging, or release paths.
Last updated: May 6, 2026
On this page
Short answer
Audit evidence for AI-assisted SDLC should connect an AI-assisted action to an accountable owner, credential, target, approval rule, validation result, and outcome. The goal is not to archive every prompt. The goal is to preserve enough proof for a reviewer to reconstruct privileged software-delivery actions.
Evidence model
A useful evidence model follows the action path instead of treating all AI use as one bucket:
actor/workflow -> owner -> credential -> action -> target -> approval -> validation -> outcomeThat model helps separate low-risk assistance from delivery actions that need stronger evidence. A local suggestion may only need normal code review. An unattended workflow that writes branches, changes CI/CD, uses a credential, invokes a tool, or triggers a release path needs a durable proof packet.
Proof packet fields
Credential and authority
Token, service account, OAuth grant, CI secret, or inherited identity plus the action classes it enables.
Action and target
Requested and executed action, target repo, branch, PR, workflow, package, tool, service, environment, or dataset.
Approval and validation
Policy verdict, approval record where required, validation command, test result, and residual risk or exception note.
Proof packet:
Actor: AI-assisted dependency update workflow
Owner: Platform engineering
Credential: repo-scoped CI token
Action: write branch and open PR
Target: billing-service repo
Approval: not required for branch write; required for workflow-file change
Validation: unit tests and dependency policy check
Outcome: PR opened, checks passed, no release triggered
Rollback/disable path: revoke workflow token or disable workflowWeak evidence
Some artifacts are useful but incomplete on their own. A mature audit trail should not depend on a future reviewer stitching together fragments.
- A chat transcript without the executed action or target-system event.
- A CI log without the credential identity or approval rule.
- A policy document without evidence that policy changed execution state.
- A model name without action authority, credential context, or proof.
- A screenshot that only works while someone remembers the surrounding workflow.
Where evidence is collected
AI-assisted SDLC evidence usually lives across multiple systems. The proof packet should connect them.
- Repository and pull request metadata.
- CI/CD workflow run metadata and logs.
- Credential or identity provider records.
- Policy verdicts and approval records.
- MCP/tool invocation records where tools are used.
- Package registry, deployment, cloud, or target-system events.
- Validation outputs and rollback or disable records.
Review questions
- Can a reviewer identify which AI-assisted workflow acted?
- Can the reviewer see who owned the workflow and who approved the action where required?
- Can the reviewer see which credential or inherited identity was used?
- Can the reviewer distinguish requested action from executed action?
- Can the reviewer see the target system and outcome?
- Can the reviewer determine whether validation ran and what it proved?
- Can the reviewer see what would trigger rollback, disablement, or re-review?
Checklist
- Define proof packet fields before rolling out write-capable workflows.
- Map proof requirements to the Agent Action BOM fields.
- Keep evidence stronger for write, deploy, publish, secret access, and production-adjacent actions.
- Do not rely on screenshots or memory for privileged actions.
- Store proof where it survives product UI changes and personnel changes.
- Set re-review triggers for new credentials, new tool reach, broader targets, or reduced human approval.