Introduce agent users to give AI agents an auditable identity

[gziolo]

What problem does this address?

Today, AI agents interact with WordPress exclusively by borrowing a human user's identity. Whether through the MCP Adapter, the Abilities API REST endpoints, or WP-CLI (--user), an agent authenticates with a user's credentials, typically an application password, and every ability's permission_callback runs against that user. This works, but it has a structural gap:

• Agents always run on behalf of users. There is no other option, even for external or autonomous agents where no human is present at execution time.
• Access to abilities is controlled through permission checks (current_user_can() via permission_callback). That is the right enforcement layer, but it can only answer what a given user may do, never what a given agent may do.
• There is no way to distinguish users from agents. Not in post_author, not in activity logs, not in the new wp_ability_invoked hook (Abilities API improvements in 7.1). A site owner cannot answer what the agent changed yesterday, or revoke an agent's access without touching a human account.

This has come up repeatedly in recent discussions. The August 5 core AI chat leaned toward representing agents as a type of user, partly because that is where regulation around AI disclosure is heading. The trust ladder framing @JasonTheAdams presented there, with gradual and task-specific autonomy backed by observability and recoverability, requires knowing who the agent is before any of its levels can be enforced. Slack discussions in #core-ai about permission sets for agents point the same way, both as an enterprise requirement and as a trust-building measure for smaller sites. The currently documented workaround of manually creating a dedicated limited user for MCP access demonstrates both the demand and the gap. Those are ordinary users, with a login, full role privileges, and no marker that they are automated.

What is your proposed solution?

Extend the existing user concept rather than inventing a parallel identity system:

• Way to designate a user account as an agent, provisioned deliberately, marked as such, and visible as an agent everywhere attribution matters.
• No interactive login (application passwords or a similar mechanism instead), excluded by default from user listings and author dropdowns, plus other constraints appropriate for automated actors.
• Existing roles adapted where needed. Agents inherit the role system as their capability ceiling, so an "editor agent" is immediately understandable, with adjustments where human role defaults are not appropriate for automated actors.
• Dual usage – the current model stays fully valid, and agents acting interactively on behalf of a logged-in user keep working exactly as today. External and autonomous agents, such as remote MCP clients and scheduled jobs, get explicit agent accounts that can be granted, audited, and revoked independently of any human account.

This builds directly on what has already shipped. The permission_callback remains the enforcement boundary, wp_get_abilities() filtering provides the substrate for exposing only the abilities an agent's role permits, and wp_ability_invoked provides the audit hook that an agent-aware actor model would make meaningful.

Related

• Unifiied Abilities exposure controls #354 covers unified abilities exposure controls, where agent users add the missing dimension of who is consuming.
• Expose role/user access controls per feature/experiment #736 covers role and user access controls per feature.
• Approval interface for tool execution? (gap after wordpress-mcp deprecation) mcp-adapter#176 and Audit hook for tool calls (post-execution complement to #176) mcp-adapter#228 cover approval and audit workflows, both of which need actor attribution.
• The Application Passwords integration guide has listed credential scoping as future work since the 5.6 merge.

Intentionally out of scope for this issue: credential improvements such as expiry and OAuth, trust levels and autonomy tiers, and approval workflows. Each deserves its own discussion once the identity question is settled.

Why is this important to you?

No response

I have searched existing issues and this is not a duplicate.

• Yes

[jeffpaul]

I love this, would definitely see a use case with the RTC deeper integration in #324 where an agent user is shown making content updates.

[webmyc]

the identity gap here is real, and i have a production failure to offer as evidence for the first bullet, plus some field numbers for the third.

an agent with no user is not a lesser-privileged actor in WordPress, it is a broken one.

Respira for WordPress connects agents to roughly 1,276 active sites. before v7.0.25 the plugin ran REST writes with no user at all, wp_set_current_user(0), on the theory that an agent is not a person. two things broke. capabilities collapsed, so no unfiltered_html, and wp_kses_post() silently stripped custom element tags out of customer page content on every write that touched post_content. and every post created that way came back with post_author=0. a customer reported the stripping on 2026-05-15 against a Bricks site before i found the cause.

the fix was to resolve a real user and act as them, defaulting to the lowest-ID administrator on the site. that is exactly the over-privileged borrowing described in this issue, and i shipped it because WordPress offers no third option. there is currently no way to be less than a user without being nothing.

how much traffic can actually be attributed today.

241,614 tool calls across those sites over the last 90 days. 50.2% carry no usable agent identifier at all. the client either sends nothing or sends something unrecognisable. that is the honest ceiling on any audit story built on today's primitives.

a suggestion about provenance, which i think matters more than the identifier itself.

my stack derives an agent name from several signals of very different quality: an operator-pinned env var, the client's own initialize handshake, a process-tree heuristic, and as a last resort sniffing the User-Agent. until today all four landed in the same column, which meant a name i guessed was indistinguishable from a name the client declared about itself. everything downstream then read the whole column as authoritative. i have just shipped a change to record how each identity was arrived at alongside the identity.

if wp_ability_invoked is going to be the audit substrate, it may be worth carrying the same distinction: not just which actor, but on what basis the actor was established. an audit trail that cannot tell an assertion from an inference will overstate its own confidence, and that is the property a site owner is relying on when they ask what changed yesterday.

one thing that might affect the shape of the design.

of 103 distinct agent labels observed, 89 appear on exactly one site and live two days or less. the names look like neighborhood-dental-publish-qa and sitemap-source-governed-create. people are putting the task into the identity field, not the agent. those 89 labels account for 793 calls, about 0.3% of traffic, so it is a long tail of throwaway identities sitting behind a short head of durable clients.

that reads to me as two different granularities wanting two different mechanisms. a provisioned agent user fits the head well, and everything in this proposal about granting, auditing and revoking it independently of a human account is what i want. but nobody is going to create 88 user accounts for the tail. a per-run correlation id carried into the audit trail, creating no account and needing no provisioning, would cover it. without something like that i expect people will keep encoding run context into whatever free-text field is reachable, which is what they are already doing.

happy to test agent users against this fleet once there is something patchable, and to report back what breaks.

[JasonTheAdams]

Thanks, @gziolo! This is a great breakdown!

@jeffpaul I agree! In Automattic we experimented with the ability to use @ai to interact with an agent, but it wasn't great as it was an exception to how @-mentions are intended to work. Having it be just another user that can be included in conversations is pretty cool!

Appreciate all the insight, @webmyc ! 🎉

Thoughts on what to iron out

You touched on some nuances, Greg, that I think we'll want to work out a bit more. Here's what could use some refining in my head:

• What kind of authentication changes do we need to make? Are Application Passwords sufficient?
• How do we keep user queries backwards-compatible so user agents don't start popping up in weird places?
• How do we structure when an agent is acting on a user's behalf?
• What do we need to add to capability checks to take the min of the agent and user's capabilities?
• Are we introducing something polymorphic to users (i.e. user type) or simply a flag that a user is an agent?
• Should we introduce distinct Agent User roles, or are the built-in roles sufficient? (Of course themes/plugins can add custom roles.)

Acting on user's behalf

Since an Agent User will have its own permissions it can do things in and of itself, but there are moments where it's important that an agent lower itself to match the capabilities of a user. Imagine the scenario of an agent working within the sidebar of WordPress as an assistant, conversing with the user and acting on their behalf. This has three circumstances:

1. Agent's role is higher than the user's
2. Agent's role is equal to the user's
3. Agent's role is lower than the user's

If I'm an Author and interacting with an Agent that's an Editor, I probably shouldn't have the ability to now edit others' posts via the Agent. Therefore, as the Agent is working its capabilities should be limited to that of the user's.

The opposite is true: If I'm an Administrator and the Agent is an Editor, the Agent shouldn't now be able to install plugins just because I'm using it. The securest path, therefore, is to operate within the lowest role between the Agent and human user.

For this reason and others, I think it would be a good idea to have an "on behalf of" set of functionality as a formal part of this.

[chubes4]

Here is something to consider. Instead of agents as a type of user, how about the concept of an actor? This applies to more than just agents. It provides a generic identity and ownership primitive that is separate from the WordPress user account.

For a practical example, consider a bbPress forum where a business has an identity that multiple team members can manage.

The same primitive that powers agent identities could allow employees to post on behalf of the business without giving either the business or agent a separate WordPress user account. Multiple users could be authorized to act on behalf of the same identity while remaining individually accountable.

Related exploration:

• Extra Chill public voices: users publish as managed artists or venues while remaining accountable.
• Forum authorization: separates the trusted execution principal from public attribution.
• Agents API execution principal: separates acting user, effective agent, authentication source, and ownership.

[webmyc]

@JasonTheAdams these questions overlap with decisions i had to make already, so here is what happened when i made a few of them the wrong way first.

min of agent and user caps. the split that ended up working is a credential carrying its own scopes, and separately a WordPress user that the write runs as. both get checked, so the effective permission is the smaller of the two, which is the behaviour you are describing.

the trouble was never enforcement. it was keeping the exposed list and the enforced list in agreement. i moved some internal calls onto a bridge that stamped a synthetic credential and skipped the permission callback, while the endpoints still checked the token's scopes, and every tool came back denied. one rule, two places, drifting apart inside a single release. wp_get_abilities() filtering and permission_callback have that same shape. if they can disagree they eventually will, and it is not only a security problem: an agent that finds out at execution time retries, and retries are where state gets mangled.

application passwords. they answer who you are, not what you may do. the password inherits everything the account can do, so the only way to narrow the agent is to narrow the person, and nobody wants to demote their own login to make an agent safer. when customers asked for limits, the lines they drew were read versus write, read everything versus read only the basics, and separately permission to skip an approval step. none of those are expressible as a role.

keeping user queries working. this is the sentence i would test hardest: excluded by default from user listings.

two bugs i have already shipped, both caused by a principal a query could not see. get_users( array( 'role' => 'administrator' ) ) only looks at a site's member list, so a network super admin who runs a subsite without being added to it does not appear. and on installs where admin comes from a custom role or a runtime user_has_cap filter, the same query returns empty while the site plainly has an admin. in both cases my code concluded there was no administrator and acted on that.

anything that enumerates users to make a decision will hit the same wall with agent users, and there is a lot of code like that. it might help to say out loud whether hiding is a display concern (author dropdowns, participant lists) or a query concern, and keep it to the first.

acting on behalf of. related to the failure i described earlier: running with no user at all is not a smaller version of a user. post_author comes back 0 and unfiltered_html is gone, so content gets stripped on the way in. whatever on behalf of resolves to, it has to land on something that can own a post.

@chubes4 the actor framing is close to what i ended up building without giving it a name: authentication identity on one side, execution principal on the other, with a filter to move the second one. the thing worth passing on from running it is that the default binding decides the security, not the mechanism. mine falls back to the lowest-ID administrator, which is more power than most agent work needs, and i only picked it because nothing smaller could still own content.

i would rather help move this than comment from the sidelines. i can run patches against a decent spread of real sites and report what breaks, and if it is useful i can write the invisible-principal cases above into a short compatibility note for whoever takes the user query changes.

[gziolo]

@webmyc thank you, field data like this is exactly what the proposal needs, and I would gladly take you up on both offers, the compatibility note and testing against your fleet once there is something patchable.

I would like to understand the content stripping case better, because I think it previews a limitation agent users will not automatically solve. From your description WordPress behaved as designed: without unfiltered_html, content passes through wp_kses_post(), and that restriction exists precisely to bound what lower-privileged principals can write. An agent user provisioned with minimal permissions would hit the same wall. So I am curious what your agent workloads actually need to produce. If the custom element tags you described are essential to what your agents write, the native path would be extending allowed tags via wp_kses_allowed_html for specific elements, rather than granting unfiltered_html to an automated actor, which I would want to avoid by default. Knowing which capabilities and content shapes your fleet exercises in practice would directly inform how the adapted agent roles should look.

On user 0, my perspective is that logged-out execution is a valid context rather than a gap. Abilities can legitimately run anonymously, for tracking or collecting anonymous data, and user 0 holds no capabilities, so any ability with an honest current_user_can() check in its permission_callback already fails closed there. The rule I would draw from your case is that abilities whose effects require ownership should enforce through their permission check that an attributable principal is present, and fail fast instead of proceeding degraded. Agent users then cover the case that has no good answer today: a principal smaller than an administrator that can still own content.

[gziolo]

@chubes4 thank you, the actor concept is a compelling generalization and the examples show it reaches beyond agents. I see it as a different dimension though, one that could be layered on top of this proposal later rather than folded in here.

The goal of this issue is deliberately narrow: an easy way to attribute work to an agent and surface that attribution on the site automatically, in post authorship, in logs, and everywhere else attribution already flows from a user account. Reusing the user primitive gives the whole ecosystem agent attribution for free, which matters as regulation around AI disclosure gains traction. A generic actor primitive is a much larger reform, and I would welcome a separate issue exploring it, ideally connected to the Agents API execution principal work you referenced.

[gziolo]

@JasonTheAdams thanks, your list is effectively the design checklist for the proposal. Let me share how the pieces connect in my head instead of answering point by point, because some of the questions overlap.

The sidebar scenario is where my mental model differs, so I will start there. When an assistant works in the sidebar with a logged-in user, I would not involve an agent account at all. That assistant is a tool in the hands of the current user. It runs with the user's session and capabilities, exactly as today. Agent accounts are for a different case: external and autonomous clients like MCP connections, coding agents, and scheduled jobs. There is no user session in those cases, and today the only option is borrowing a human credential. With this split, every execution has exactly one principal. The three circumstances you outlined never happen, because there are never two accounts to compare.

Both of your concerns still get covered, just with simpler controls. The user cannot gain the agent's power, because interactive assistance never touches the agent account. The assistant cannot reach beyond its context, because surface-level ability filtering limits what is even exposed in a given surface. Two rules complete the picture. Creating or changing standing instructions for an agent is checked against the capabilities of the user who configures them, so nobody can schedule work they could not do themselves. And who may direct an agent is an explicit grant, so a lower-privileged user cannot use a higher-privileged agent to escalate. I would start with this single-principal model and only revisit capability intersection if real usage shows we need it.

Most of the structural questions have the same answer: the agent account should stay as close to a normal user as possible. I would use a simple flag instead of a new user type. Changing WP_User itself would touch too much existing code, while a flag keeps every current code path working. Where the flag lives in the database is still open, user meta is the obvious option, but multisite behavior needs a closer look. I would also avoid roles that exist only for agents. A separate list of agent roles would be hard to maintain, and the existing roles are already well understood. An agent with the Editor role is clear to everyone. Where a role default does not fit an automated actor, we can adjust specific capabilities for flagged accounts instead. The clearest example is unfiltered_html, because model output combined with it means stored XSS.

Queries follow the same rule. Agent accounts stay fully queryable, and the cases @webmyc described show why: a lot of code lists users to make decisions, and that code must keep seeing agents. What we should explore is smaller, the UI places where a user should not be able to pick an agent account, for example as post author in a dropdown, because from there the agent's work reaches site visitors as user generated content.

That last example points at what may be a separate problem. Agentic usage probably needs its own marker, independent of the account that did the work. Such a marker would also cover the case where an agent works through a real user's session, which no account scheme can express. This touches the direction @chubes4 pointed at, separating what the public sees from which account executed the work, and a provenance marker is the minimal version of that separation. Attribution of the principal and disclosure of agentic origin may be two different mechanisms, and the regulatory pressure is mostly about the second.

On authentication, Application Passwords were an example of what core ships out of the box, not the answer. Credentials depend on the client integration, and plugins already offer alternatives like OAuth. The identity proposal should stay agnostic here: any authentication that resolves the request to an agent account works. Once the account itself is narrow, the usual concern about Application Passwords, that they inherit everything the account can do, mostly goes away. Expiry and finer scoping stay on their own track, which is why credentials are listed as out of scope.