Verify what an agent did in a session from the audit log

An agent session just ran against your site and you want to know what it actually touched, not what it said it did. The plugin keeps its own audit log of every ability call, so the record is already there. What you want is that record read back to you in plain language, with the failures called out.

This is an administrator’s check. It reads the log and reconstructs the session, and it writes nothing.

Read the audit log for this site and tell me what happened over [the last
hour]. Change nothing.

Go newest first, 200 rows a page, and keep paging until created_at (it is UTC)
is older than [one hour ago]. This read has no date filter, so that is the only
way to bound it. If it takes more than three pages, stop and tell me how far
back you got.

Set aside rows that are not tool calls: ability "(transport)", an ability
starting with "oauth:", "aafm/write-outcome", "aafm/activity-log-cleared",
"aafm/read-only-mode", "aafm/high-risk-abilities-unlocked",
"aafm/review-publish", "aafm/review-discard", any ability that does not start
with "aafm/" or "aafm-bridge/", any row whose detail starts with "Enabled ",
"Disabled " or "Blocked " (someone switching an ability on or off in wp-admin),
and any denied row with no acting user. Count those on one line.

Group the remaining entries by ability so I can see what was called and how
many times, and call out anything that errored or was denied along with when it
happened.

For each entry, confirm the acting user and login, and flag anything where the
account is not the one I expected to be running. Finish with a short plain
account of the session: what ran, what succeeded, and what failed.

Why this is safe to run

This is a single read. Pulling the audit log reports what already happened and cannot change a thing, so the worst case is that the window you asked about is quiet.

The one thing to know going in is who runs it. The audit log reads through the manage-options capability, which is an administrator power on purpose. A least-privilege agent user should not hold it, so this is a report an administrator pulls, not something the everyday limited agent can run about itself. The log records the ability name, the status, the acting user and login, the argument keys, a short note of the identifiers each call touched, and the timestamp, but never the free-text content behind the call, so it tells you what ran without leaking the post bodies or personal data that passed through it.

When the agent’s account is not enough

The agent’s read is the short version of what the Activity Log tab holds. It cannot say which connection made a call, where the request came from, or how long the tool ran, and it does not return why a call was denied.

When the session matters, say you are checking something an agent did to a post you care about, open the tab after the agent has summarized. Set the From and To dates to the day, filter by the tool or user the summary named, and read the Connection, IP and Detail columns. Export CSV downloads exactly the rows on screen. For the admin-screen walkthrough (filters, denied rows, CSV), see How to find what an AI agent did.

The log keeps 30 days by default, so a session older than your retention setting is gone from both views.

Already connected? Skip the paste. From an admin connection, ask your agent for the “verify what an agent did from the audit log” recipe, or just ask it what happened on the site in the last hour, and it runs the same read on your own install.