Agent Abilities
GitHubGet it free
Features
Abilities
Browse all abilities

WordPress core

ContentTaxonomies & TermsCommentsUsersMediaSite settingsPluginsThemes & stylesBlocksMenusSearch

Integrations

WooCommerceAdvanced Custom FieldsRank Math SEOYoast SEOAll in One SEO
Integrations
All integrationsWooCommerce52Advanced Custom Fields7Rank Math SEO5Yoast SEO3All in One SEO3
Bridge
AI clients
All clientsChatGPTClaude.aiManusClaude DesktopClaude CodeCursorVS CodeWindsurfGemini CLI
Resources
DocsChangelogPrompt LibraryBlogComparisonsSupport
GitHubGet it free

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

MaintenanceIntermediate~5 min
AbilitiesGet activity log

Before you start

An admin account. Reading the audit log requires the manage-options capability, which a least-privilege agent user should not have, so run this from an administrator connection rather than the day-to-day agent.

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.

The prompt
Read the audit log for this site and tell me what happened over [the last
hour]. Change nothing. Go newest first, group the 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, and the timestamp, and never the argument values or network addresses, so it tells you what ran without leaking the content behind each call.

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.

How it works

  1. Read the audit log newest first, over the window you name.
  2. Group the entries by ability so you can see what was called and how often.
  3. Flag any call that errored or was denied, with its timestamp.
  4. Confirm the acting user and login on each entry matches who you expected.
  5. Summarize the session as a short account of what ran and what did not.

Questions

Why does this need an admin, when my agent runs on a limited user?
The audit log reads through the manage-options capability, which is an administrator power. A least-privilege agent user should not hold it, so this is an admin report you run yourself rather than something the everyday agent can pull about its own activity.
Does the log show the actual data an agent read or wrote?
No. It records the ability name, the status, the acting user, the argument keys that were passed, and the timestamp. It never stores argument values or network addresses, so it tells you what ran without exposing the content behind each call.

Related recipes