---
title: Letting AI act safely needs one audit log, not five
canonical: https://getcyril.com/blog/agents-need-one-audit-log/
published: 2026-06-02
updated: 2026-08-28
author: Sam Akbari
language: en
---
# Letting AI act safely needs one audit log, not five

Answering a question wrong wastes a minute. Taking an action wrong sends the email, moves the deal, refunds the invoice. The gap between generative AI and agentic AI is the gap between being unhelpful and being dangerous — and most of the work of closing it safely happens below the model.

Cyril is built for agents to take actions on your behalf. That only works if every action runs through the same three things a human action does: a permission check, an audit record, and a way to undo it.

## The problem with actions across five tools

In a stitched-together stack, an agent that acts has to act *through integrations*. It creates the project in one tool, sends the email through another, updates the deal in a third. Each has its own permission model, its own (or no) audit trail, and no shared notion of "undo."

So when something goes wrong — and with agents, something will — you're left reconstructing what happened from five partial logs that don't share an ID, a clock, or a vocabulary. You can't answer the only question that matters: *what did the agent do, on whose authority, and how do I reverse it?*

That's not a model-safety problem. It's an architecture problem, and a guardrail prompt can't fix it.

## One permission model

In Cyril, an agent is a caller, not a god mode. It acts inside the same RBAC that governs people: scoped to an `org_id`, bounded by a role, allowed exactly the permissions in its grant — no more. An agent asked to do something outside its permissions is refused the same way a user would be, by the same code path.

This matters because it makes agent authority *legible*. "What can this agent do?" has the same answer shape as "what can this person do?" — and you set it in the same place.

## One audit log

Every action — human or agent — writes to one audit trail, with the actor, the authority it acted under, the before-and-after, and a timestamp from one clock. An agent action is tagged as such, so "show me everything the assistant did to the Phoenix account last week" is one query, not a forensic reconstruction across systems.

When the actions and the records live on one graph, the audit log isn't a bolt-on. It's a natural read over the same data.

## One rollback path

Because mutations are transactional and tenant data is soft-deleted rather than destroyed, an agent's action has a defined inverse. A wrong move is a recoverable move. The same property that protects you from a bad human click protects you from a bad agent step — there's no separate, riskier "AI write" route that skips the safety rails.

## Human-in-the-loop is a setting, not a rewrite

Some actions should just happen; some should wait for a person. Because every action runs through one pipeline, "require approval" is a policy you apply to an action class — not a feature you have to re-engineer per integration. You decide how much rope the agent gets, per action, and change your mind without touching the agent.

## What this looks like for you

- Let an agent run a multi-step workflow across modules and see exactly what it did, in one log, under one identity.
- Give it real authority without giving it unbounded authority — same roles, same scoping as your team.
- Undo a wrong step the same way you'd undo any step, because there was never a second, weaker write path.

Trustworthy AI action isn't mostly about the prompt. It's about whether the platform underneath can answer for what the agent did. Cyril is built so it always can.

## Common questions

### Is a guardrail prompt not enough?

A prompt shapes what the model tries to do. It has no bearing on what the platform will let it do, and the second is the one that holds when the first is wrong. Treat the prompt as ergonomics and the permission model as the control.

### Should an agent have its own service account?

Not a broad one. A service account with wide read access moves the authority question out of your role model and into a place nobody reviews. An agent acting as the user, inside that user's permissions, keeps "what can this agent do" answerable in the same place as "what can this person do".

### What does one rollback path actually mean?

That an agent's write goes through the same transactional, soft-deleting code path as a human's — so the inverse already exists. There is no second, weaker write route for AI that skips the safety rails, which is the route that usually gets added under launch pressure.

### Can approval be required for only some actions?

Yes, and that is the point of routing everything through one pipeline: approval is a policy applied to a class of action, not a feature rebuilt per integration. You change how much rope the agent gets without touching the agent.

---

If you'd like to be among the first to use Cyril, [join the waitlist](/waitlist/).
