Audit Trail: Proving What Your AI Did and Didn't Do

An audit trail, in the AI-tools context, is the complete record of every call an assistant made through its connector: which tool was invoked, against which account, whether the call succeeded or was refused and for what reason, and exactly when. It is the difference between "the AI did something to the account" and "this person's assistant called this tool on this account at this timestamp, and here is what happened."

The blunt version: an AI with access to a spend system and no trail is unmanageable by definition. Not risky — unmanageable. You cannot supervise what you cannot see.

How an audit trail works

A complete trail records four things per call, and the fourth is the one vendors skip:

• Who and what — the member whose connector made the call, and the tool invoked.
• Where — the customer account the call targeted.
• When — a timestamp, so activity can be lined up against performance and against people's recollections.
• Outcome, including refusals — success or refusal, with the reason. AdCopilot records every call this way, and the refusals are not filler: a log entry showing a delete attempt refused server-side is evidence of the safety property working, which no marketing page can substitute for.

The trail pairs with Google's own change history rather than duplicating it. Google logs every write that landed, attributed to the authorising user, for two years — but it never sees reads, and it never sees what was attempted and blocked. The connector trail covers exactly that blind spot. Read together they answer both directions of the trust question: everything the AI did, and everything it tried.

Attribution granularity is the design decision underneath. A shared service-account connector produces a trail where every row says the same name; per-member connectors — each teammate signing in with their own Google account, individually revocable — produce a trail where rows attach to people. Only the second kind supports real accountability.

Why delegating to an assistant needs the trail

For a team, the trail is what makes delegation to assistants compatible with the accountability structures that already exist. A manager can answer "what has the AI been doing in the client's account this month?" with a record, not a vibe. When something looks odd, the trail bounds the investigation: these calls, this member, this window.

For an agency, it is close to a commercial asset. Client trust in AI-assisted account management rests on being able to show — not assert — what the assistant read, changed and was refused. A trail turns the scariest client question ("what exactly does the AI do in our account?") into a report you can produce on request.

And when evaluating any vendor, the trail is a five-question interview: Do you log reads or only writes? Are refusals recorded with reasons? Does activity attribute to individual people? Can I export it? How long is it kept? Vague answers to those questions are themselves an answer. The wider trust architecture — what is logged, what is stored, what is refused — is laid out on the security page.