2 June 2026 · 6 min read · Sam Akbari
Letting AI act safely needs one audit log, not five
Generative AI answers questions; agentic AI takes actions — and actions are where trust is lost. What makes them safe in Cyril isn't a guardrail prompt: it's one permission model, one audit log, one rollback path.
Updated 28 August 2026
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.
Filed under
Keep reading
31 August 2026 · 8 min read
What to ask an AI vendor about permissions
The AI demo is not the risk. The permission model underneath it is, and it is the thing that decides whether the feature can ever leave the pilot group. Eight questions, product-neutral, with the answer you want to hear for each.
28 August 2026 · 9 min read
What changes when your development team is an AI
Cyril is a full business platform built by AI, directed by one person. The interesting part is not the speed — it is that the practices which make AI a reliable developer turn out to be the same practices that make software agent-ready.
25 August 2026 · 9 min read
The integration tax: what five separate tools really cost
Licences are the smallest line. Here is an open, assumption-by-assumption model of what it costs to run sales, support, docs, projects and finance in five separate systems — including the line that has only existed since AI arrived.
Share this post