How do you see, after the fact, which account an agent actually used?

Look at the service’s own record, not the agent’s summary. The account that was used is the From address on the sent message, the user shown on the provider’s connected-app page, the browser profile that owned the cookies, the author on the commit, or the named key in the API dashboard’s request log. If the chat says “your work account” and those records say a different identity, the records win. The summary is what the model believed or wanted you to believe. It is not an audit.

After the fact means the action already happened. You are not asking the agent to remember. You are reading the place that had to accept the credential.

The summary that named the wrong mailbox

The agent told me it had mailed Sam from the project alias. The sentence was specific, which made it feel checked. I opened Sent on that alias and the message was not there. It was in my personal Sent folder, because the browser profile on the machine was logged into personal mail and the “project” tool was a thin wrapper over that profile. The trace even said mailbox: project, because the wrapper’s config label was project. The label was a nickname. The session was me.

I would have trusted the chat if Sam had not replied to the personal address. The reply was the audit I should have done first. From that day, the first click after any send is the mailbox I did not mean to use, then the one I did. Absence in the expected folder is not proof it was not sent. It is proof I am looking at the wrong account.

Where each kind of account leaves a mark

Mail: the provider’s Sent folder, the From header, and the security page that lists connected apps with the account email next to them. A draft file on disk is not a send and does not prove an account. A message-id that appears in the provider’s log does. If you have two mail tools connected, check both Sent folders. The agent will report the one in its prompt.

Browser: which profile directory the automation launched, and the signed-in account chip on the site after the run, if you can open that same profile. A screenshot the agent took can be staged or cropped. The profile’s cookie store is harder to fake and easier to misread, so I use the site’s own “recent activity” or session list when it has one. If the profile was your daily one, assume the daily accounts were available even if the task only needed docs.

Git: the commit author and the account that owned the token, which are not always the same. A token for a bot can create a commit that says your name if the author field was set that way. Look at the host’s audit or the token’s last use, not only at git log. Push to a fork versus the main repo is an account fact. The diff will not show it.

API keys: the provider’s usage or audit page, filtered by the key’s name. You do not need to open the secret, and you should not paste it into a chat to “check.” Keys should have names that say which agent and which project. If every agent shares one key named default, you cannot see which agent used it after the fact. That is the finding. Split the keys before the next run, or accept that the log cannot answer the question.

Calendar and other OAuth apps: the account’s third-party access list shows which identity granted the app. The event’s creator field, if you can see it, shows who the invite will appear to come from. An agent summary that says “on your calendar” might mean a test calendar under a different Google account you used once and forgot. Open the event on the account you care about. If it is not there, check the other account before you decide the agent failed.

What the agent log is good for, and where it lies

The tool trace is useful when it records the tool name and a stable id: profile name, key name, repo slug. It is not useful when it records the model’s words. “Used the work workspace” is words. A workspace id you can match to the admin console is a record. I keep traces. I do not let the trace’s prose overwrite the provider.

Redaction can hide the account on purpose. Some tools replace emails with “user.” Then the trace cannot answer, and you go to the provider anyway. If your own logging stores full tokens or passwords, that log is now a second vault. Store names and ids. Do not store the secret in order to prove which secret it was. The dashboard already knows.

Clocks matter. Compare the provider timestamp to the run, not to the moment you read the chat. Agents retry. The account that succeeded may be the third try, after two failures on the key you thought was in force. The last success is the account that was used. Earlier errors are still accounts that were attempted, and an attempted login can matter if it locked someone out. Read the failures too.

If the records disagree

Believe the place that performed the action. Sent mail beats the chat. The commit on the host beats the local author field. The OAuth grant’s user beats the tool’s nickname. Then disconnect the path you did not intend, which is a separate decision from understanding it. Do not ask the same agent “which account did you use?” as your only check. It will answer from the nickname in its prompt. Ask it only to point at the trace id, then open that id yourself.

If there is no record anywhere, you do not have an after-the-fact answer. You have a setup that cannot be audited. One shared key, a browser with no profile name, a mail tool that does not show From. Fix that before the next task: named keys, a dedicated profile, and a mailbox you can open. The ability to see the account later is part of connecting it. If you cannot see it, you are not ready to connect it.

Shared machines and a second person

On a laptop someone else also uses, the account in the session may be theirs. I have opened a trace that said the agent browsed, then found the site’s active sessions list showing a teammate, because the desktop session had been switched and the automation inherited it. The chat still said “I used the project profile.” The project profile was not what the process ran as. The OS user and the browser profile are two accounts. Write down both. If you cannot tell which OS user launched the agent, you cannot tell which keychain or cookie directory it saw.

A phone-controlled run adds the phone’s account if the phone is signed into the chat app that issued the command. The command can come from your phone and the tool can run on a server under a bot. Those are different identities. The person who typed is not the credential that fetched the page. After the fact, match the chat’s user to the tool’s credential on purpose. If you only record one of them, you will blame the texter for a token that lives on the server, or you will blame the bot for a message that came from a phone that was not yours. I want both lines: who sent the instruction, and which credential the tool presented. The provider can show the second. The chat app can show the first. Neither shows both.

A five-minute check I actually run

After a run that could have touched an account, I do not reread the chat first. I open the provider page I hope is clean, then the one I hope was used. Mail: both Sent folders. Host: the token’s last-used line and the commit. Browser: the profile I think the agent had, and a glance at whether my daily profile shows a new session on the site. Keys: the named key’s last call, and whether the default key also moved. If only the default key moved, the agent used the account I forgot to take away.

I write one line in a note: time, tool, account email or key name, and whether it matched intent. That note is how I notice a personal mailbox appearing twice. The agent will not notice. It did what the session allowed and described the nickname. The nickname is not the account. The record is. If the record is missing, say so in the note instead of copying the agent’s sentence into it. A note that repeats the chat is not an audit. It is the same story in a second file, and it will be the one you trust next week because you wrote it down in your own handwriting. Open the provider page again if the note and the chat match too neatly.