Enterprise
An append-only audit trail for AI-assisted development
Every prompt, merge, deploy and admin action, recorded append-only — so 'who did what, and who approved it' has an answer your auditors can read.
Ciao maintains an append-only audit trail across prompts, merges, deploys and admin actions. Unlike development tools that log only commits, the trail captures the AI era's new question — what was asked of the AI, what changed as a result, and which human reviewed it — with Guardrails recording human review behind every merge. The trail can be exported for audit review and demonstrated live during evaluation.
Published 2026-07-03 · Last updated 2026-07-03
'Who did what' now includes the AI
Traditional change management audits three artifacts: the ticket, the commit and the approval. AI-assisted development adds a fourth that most tooling ignores — the prompt. When a plain-language request can produce a production change, the request itself is part of the change record, and an audit trail that starts at the commit has already lost the beginning of the story.
Ciao records the whole sequence. Prompts are first-class events; merges carry the Guardrails review record — which policy applied, which human reviewed, what was approved; deploys and admin actions complete the picture. The trail is append-only: entries accumulate, and the history your auditors read is the history that happened. Nothing about the sequence has to be reconstructed from chat exports or screenshots after the fact.
For a CISO, this converts an uncomfortable question — 'how do you control what the AI changes?' — into a reviewable one: pull the trail and read exactly what was requested, what changed, who approved it and when it shipped. That single capability tends to move an AI development platform from the 'exceptions to explain' column of a risk review into the 'controls to reference' column, because few change-management stories in the rest of the estate start as early as the request itself.
What is recorded
Four event classes, one trail — recorded in sequence, not assembled after the fact:
- Prompts — The plain-language requests made to the platform — the true start of each change, captured rather than lost in a chat window.
- Merges with review context — Guardrails maps code into business areas, detects risky changes, applies plain-English policies and records human review — leaving an audit trail behind every merge.
- Deploys — What shipped and when, connecting approved changes to what is actually running in front of users.
- Admin actions — Identity, access and configuration changes — including provisioning events from SSO and SCIM — so access reviews and change reviews draw on the same record.
- Append-only by design — The trail accumulates; entries are not edited in place. What reviewers read is the sequence as it occurred.
Export and review
Evidence you cannot extract is evidence you do not have. The trail can be exported for audit review, so your team can bring records into its own working papers and retention process rather than screenshotting a vendor UI. During evaluation, ask for two things: a live walkthrough where you pick a real change and trace it end to end, and an export of that same sequence so your auditors see the format they would actually work with. Ask also who can run exports and how export events themselves are recorded — a good logging story includes the log's own access story.
For incident response, the same trail serves a different master. When something breaks or looks wrong, responders reconstruct the sequence from prompt to deploy without waiting on anyone's memory of what was asked and approved. The evidence that satisfies an auditor in the quarterly review is the evidence that shortens an incident timeline in the bad week.
How an audit request plays out
A concrete walkthrough, using the trail the way your auditors would:
1. Scope the question
An auditor asks about a change: who initiated it, what it touched, who approved it, when it reached production.
2. Pull the trail
Locate the sequence — prompt, resulting change, Guardrails policy and review record, deploy event.
3. Show the review
The merge record shows the plain-English policy that applied and the human review Guardrails recorded, answering the approval question directly.
4. Export the evidence
Export the relevant records into the audit's working papers, so the finding rests on records rather than recollection.
5. Close the loop
Because admin actions are in the same trail, follow-up questions about who had access at the time are answered from the same source.
Event types and why reviewers care
| Event type | What is recorded | Why reviewers care |
|---|---|---|
| Prompt | The plain-language request made to the platform | The true origin of an AI-assisted change |
| Merge | Risky-change detection, policy applied, human review recorded | Approval evidence behind every merge |
| Deploy | What shipped and when | Connects approvals to production reality |
| Admin action | Identity, access and configuration changes | Access reviews and privileged-change evidence |
Verification notes
The trail is a control you can watch operate: during evaluation, make a change through the platform and then find yourself in the log. For written evidence, SOC 2 Type II reports are available under NDA, and the security pack — on request via the contact page — covers logging architecture and retention specifics. If your audit framework has particular retention or format requirements, put them to the enterprise team in writing during procurement.
One habit worth adopting from teams that audit well: pick one real change per month and trace it end to end as a drill. It keeps the audit muscle warm, surfaces gaps while they are cheap to fix, and turns the annual audit into a repetition of something routine rather than a scramble.
Frequently asked questions
Can audit log entries be edited or deleted by an administrator?
The trail is append-only by design — entries accumulate rather than being edited in place. For the architectural detail behind that property, request the security pack and, under NDA, the SOC 2 Type II report covering the relevant controls.
Are AI prompts really part of the audit record?
Yes. The trail spans prompts, merges, deploys and admin actions, so the record of a change starts at the request rather than at the commit. During evaluation you can trace a prompt through to its deploy.
How long are audit records retained?
Retention specifics belong in writing, not on a marketing page — they are covered in the security pack and can be addressed in your agreement. State your framework's retention requirement during procurement and get the answer documented.
Can we pull the trail into our SIEM or GRC tooling?
The trail can be exported for audit review. Ingestion into your specific SIEM or GRC stack is an integration question — describe your pipeline to the enterprise team and confirm the workflow during evaluation rather than assuming it.
Who can read the audit trail?
Access to the trail is governed by role-based access control, so audit visibility is a role your workspace assigns deliberately. Access changes are themselves admin actions — recorded in the same trail they grant access to.