Review the audit log for agent traffic

The Activity Log records a lot, which is its virtue and its problem. Your own admin work is in there next to the agent’s, in one stream, and the question you usually want answered is specifically about the agents: what have they been doing, which abilities are they leaning on, and is any of it being refused.

Version 1.7.4 put a flag on every row that makes the split possible. This prompt uses it to give you an agent-only view of your own log. It reads and reports, nothing else.

I want to know what the agents on this site have been doing. Read only, change
nothing.

Read the Activity Log newest first, 200 rows a page, and keep paging until the
created_at time (it is UTC) is older than [seven days ago]. There is no date
filter on this read, so that is the only way to bound it. If it takes more than
five 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.
Leave them out of everything below.

Every other row carries an is_agent_identity flag. Split on it: agent traffic
in one group, human traffic in the other, and tell me the count on each side
before you go any further.

For the agent rows, group them by ability and give me the counts, busiest
first. Then group the same rows by status, so I can see how many succeeded,
errored, were denied, or are still marked started.

Show me every denied and every errored row in full: the ability, the acting
user, the timestamp, and whatever detail the log recorded.

Finish with a short read on the pattern. Is any single agent identity behaving
differently from the others, reaching for abilities the rest do not touch, or
collecting denials nobody else is getting? Say what you saw, and say plainly if
nothing stands out.

Why this is safe to run

One ability, and it is a read. The Activity Log reports history that has already happened, and reading it cannot rewrite a row of it.

The flag is what makes the split trustworthy. Before 1.7.4 you could filter by username and hope that told you something, but usernames answer the wrong question: they identify the account, not the kind of connection the call came through. The is_agent_identity boolean reflects either the per-user application-password marker that already existed or a per-OAuth-client flag set on the Connection tab, so a connection you deliberately created for an agent is marked as one either way, and the log says so on every row.

What the agent cannot see, and where to look instead

The read your agent runs is narrower than the Activity Log tab in wp-admin, and 1.9.0 made the gap wider. The ability filters on status and on one exact tool name, and nothing else. It returns the ability name, status, acting user, flag, argument keys, timestamp and an identifier-only detail.

Four things are only on the tab:

• Why a call was denied. Version 1.9.0 records the reason, such as “key is not on the allowlist”, in the log. The ability leaves it out of the detail it returns, so an agent holding an administrator credential cannot map your allowlist.
• Connection name, source IP and duration. The tab shows all three on every row, and the CSV export carries them.
• Filters by user, connection, plugin, date and text, plus a 7-day summary card and a Live view.
• Alert settings. Rows about your notification settings are left out of what the agent reads.

So use this prompt to find the pattern, then open the Activity Log tab to find the cause. Click Denied, add the tool or user from your agent’s answer, and read the Detail column.

The log is also bounded by your retention setting, 30 days by default, so a window longer than that comes back short.

The last thing is who runs it. The read is gated behind manage-options, a capability a well-scoped agent user has no business holding, since an agent that could read the audit log could read the record of every other agent too. So this one is an administrator’s prompt, run from your own connection.

Already connected? Skip the paste. From an admin connection, ask your agent for the “review the audit log for agent traffic” recipe, or just ask what the other agents have been up to this week, and it runs the same split against your own log.