Review the audit log for agent traffic

The Activity Log records everything, 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 for [the last seven days], newest first. Every row now
carries an is_agent_identity flag, so split the rows on it: agent traffic in
one group, human traffic in the other. 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, how
many errored, and how many were denied.

Pull out every denied and every errored row and show me those 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.

Know what the log is not, before you plan around it. It keeps identifier-only values by design: ability names, statuses, user ids and logins, the argument keys that were passed, timestamps, and a short detail such as an object id, a slug, or an error code. It does not keep argument values, content, file paths, or network addresses. So this recipe can tell you that an agent updated four posts and which four, and it cannot tell you what the new text was or where the request came from. Those are deliberate omissions, and they are the reason the log is safe to hand to a prompt in the first place.

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.