AI Audit Log: Why Sentinel Logs Everything, Blocks Nothing

An AI audit log has exactly one job: answer the question “what happened?” after the fact. It is not a gate, not an approval queue, and not a safety mechanism that stops anything. Sentinel logs every action your AI takes against your CRM and blocks none of them, and that combination is deliberate — not a feature we haven’t gotten around to building yet.

That sounds backwards to most people the first time they hear it. If you can see every change coming, why not stop the bad ones? Because in practice the systems that try to stop bad changes stop good ones at the same rate, and the humans staffing them learn to click approve. The log is the part that keeps working when everyone is busy.

What your CRM’s own audit trail actually gives you

Start with what you already have, because it’s better than most people think and narrower than most people assume.

Salesforce ships a Setup Audit Trail. It shows the 20 most recent setup changes in the UI, and you can download the past 180 days as a file — after that, the records are deleted. Each entry records the date, the username of whoever made the change, and what the change was. Salesforce has also added a Delegate User column for admins acting on someone’s behalf, and an AI Agent column for changes made by an agent through Setup with Agentforce (Salesforce Help).

That last column is worth pausing on. The platform vendor has independently concluded that when an AI makes a configuration change, the log needs to say so. That instinct is correct. It’s also the floor, not the ceiling.

Below the setup layer, deeper activity logging lives in Event Monitoring, which is a paid add-on. Without it you get seven event log file types with one-day retention; with it you get dozens of event types and much longer windows (Salesforce Architects). None of that is a criticism. It’s just the shape of the thing: native logging is split across surfaces, tuned for platform events, and priced accordingly.

A username is not an actor

Here is the gap that opens the moment an AI starts doing the work.

Your CRM’s audit trail records the identity the change arrived under. When a person makes a change, that’s usually enough — the username is the actor. When an AI makes the change, the username is a service account, and the actual actor is a session: someone typed a request, a model interpreted it, a deploy went out. The log says a change happened under an integration user. It cannot say which of your four team members asked for it, in which session, as part of which larger piece of work.

The other half of the gap is timing. Setup Audit Trail tells you a field was created. It does not tell you what your org looked like ten seconds earlier, which is the only fact that matters when you want to go back.

So the question a useful AI audit log has to answer is not “what changed.” It’s: who asked, what ran, when, against which org, and what is the state I can return to.

What Sentinel’s log records

Every action your AI takes through Sentinel is logged — reads and writes both, with the key that authorized it, the target org, and the timestamp. Deploys carry the extra piece: a snapshot taken before the change went out, tied to the entry that describes it.

That means each line in the log is answerable in both directions. Forward: this is what was asked for and what ran. Backward: this is the state that existed immediately before, and here is how to get there. A log entry without a recovery path is a receipt. A log entry with one is an undo button with a paper trail attached, which is what you actually want at 4pm on a Friday.

This is also why the log lives on the server and not on anyone’s machine. A dedicated VM per client means every session — yours, your ops lead’s, whichever AI model each of you happens to be using — writes to the same log. One record, one timeline, no reconciling four laptops after the fact.

Why it blocks nothing

Now the opinionated part.

The obvious next step, once you have a log, is to put a gate in front of it: every AI-written change waits for a human to approve. It sounds responsible. It fails for three reasons.

It slows every change, not just the risky ones. The whole point of handing work to an AI is that a five-minute task takes five minutes instead of sitting in a developer queue for three weeks. A gate re-queues everything and puts the constraint back where it was.

It trains complacency. Approval queues that are 98% routine get rubber-stamped, and by the time the 2% arrives the reviewer has been conditioned by four hundred harmless diffs. This is the well-documented failure mode of every change-approval board that has ever existed.

And it promises something it can’t deliver. A gate only catches changes a reviewer recognizes as wrong. The changes that hurt are almost always the ones that look completely reasonable and are pointed at the wrong records.

So Sentinel makes the opposite bet: let the change go, make it visible, make it recoverable. To be explicit, because this gets misread — Sentinel does not prevent you from making a regrettable change to your CRM. It is not designed to. It’s designed so that when you make one, you can see exactly what it was and put it back. That’s the recovery-first argument the whole platform is built on, and the audit log is the half of it that does the seeing.

The log is what makes multiple AIs on one org survivable

Two people pointing AI sessions at the same Salesforce org is where logging stops being hygiene and starts being load-bearing.

Sentinel allows unlimited read keys and one write key at a time per org. That constraint exists partly to prevent simultaneous conflicting deploys, but it does something quieter and more useful too: it makes the log unambiguous. At any moment there is exactly one identity that could have written, so every write in the timeline has an unarguable owner. You never end up staring at two overlapping change streams trying to work out whose deploy clobbered whose.

That’s the one-write-key model doing double duty — traffic control and attribution in the same mechanism.

How you actually use it

Three moments, in descending order of urgency.

Something looks wrong. A field is empty that shouldn’t be, a flow is firing twice, a report broke. Open the log, scan back to when it was last right, find the change that lands in that window. Read what ran. If it’s the culprit, the snapshot attached to that entry is your way back. This is a five-minute exercise instead of an afternoon of archaeology, and the difference is entirely that the record exists.

Someone new joins the work. A new team member, or you coming back after two weeks off, can read the last fifty entries and reconstruct what the org has been through. That’s institutional memory that would otherwise live in one person’s head and in a Slack thread nobody can find.

The weekly skim. Not an audit, just a scan. You’re looking for things that surprise you — a deploy you don’t remember asking for, a write key active at an hour nobody was working. Most weeks it’s boring, and boring is the correct outcome.

The honest limits

The log doesn’t judge whether a change was a good idea. It records that it happened. A perfectly logged mistake is still a mistake, and the log’s only contribution is that you find it in minutes instead of never.

It also doesn’t read itself. Nobody is going to page you because entry 4,102 looks odd. That’s the tradeoff we chose: no gate means no false alarms, and it also means the responsibility to look stays with you. If that sounds like too little structure, the honest answer is that it’s the same amount of structure a good engineering team runs on — plus a rollback path most of them don’t have.

And it isn’t a substitute for the questions you should ask before any of this starts. If you’re evaluating whether to let an AI touch your org at all, the ten questions worth asking first cover the ground this post assumes you’ve already crossed.

Visible beats blocked

Every safety mechanism is a bet about which failure you’re more afraid of. Gates bet you’re most afraid of a bad change shipping. Logs and snapshots bet you’re most afraid of a bad change shipping and nobody knowing what it was. The first fear is loud. The second one is the one that actually costs you a weekend.

Sentinel is a bet on the second — a full safety layer of logs, snapshots, sandbox-first Salesforce deploys, and one write key at a time, wrapped around an AI that is otherwise free to build what you asked for. Freedom and visibility, not permission slips.

If you want your AI to have that kind of accountable access to your CRM, that’s what a Sentinel is: a dedicated VM for your org, key-based access, and a log of everything that runs against it. It’s $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel.

Get a Sentinel and get a log of everything your AI ships