Audited actions
When the assistant takes an action on your behalf, two things are always true: it confirmed with you first, and the action is recorded under your name.
Confirm before mutating
Every write requires your explicit confirmation. The assistant shows you what it is about to do and waits. This covers approvals, rejections, plan submissions, and every other call that changes data. There are no silent background mutations.
When an artifact already exists, the assistant prefers to propose: the change is staged for you to accept or reject on the artifact page. Approval gates on documents stay with people.
Runs as you
Writes inside a sandbox session run as the signed-in user, not as an agent service account. The actor recorded in the audit log is your account. When you read the audit trail for a project, actions the assistant took on your instruction appear with your name and not the name of the agent.
The audit log
Every mutating action lands in a per-project audit log. Each entry's hash covers the previous entry, forming a chain. Removing or altering any record breaks the chain, so the log is tamper-evident. The event categories recorded are:
artifact.*: create, update, approve, reject, submit, supersedecomment.*: create, update, deletegeneration.*: generation run start, step completion, failureagent.*: sandbox actions taken on a user's behalf
The audit log for a project is available to project admins and organization admins at Settings → Audit log. The history for a specific artifact is visible in the artifact's Events view, opened from the ⋮ menu.
Approval gates stay with people
The assistant can propose changes, trigger generation, and retry failed steps. It cannot bypass the approval gates configured for a project. A document that requires human approval enters review and does not advance until a person approves it, regardless of whether the assistant initiated the generation.
Next steps
- Audit trail: the full audit log for a project.
- Approve an artifact: what approval means and who can do it.