# An Identity Model That Predates Delegation Cannot Attribute Delegated Action ## Claim An audit or authorization system built when every actor was assumed human cannot attribute an action to the right party once delegation is introduced, because the system has no signal besides the credential, and a delegate acting under a borrowed credential is indistinguishable from the person who holds it. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies wherever a system logs "who did X" by recording which credential was used, not which agent used it: WordPress application passwords, OAuth tokens, service accounts, CI credentials, shared API keys. - Strongest where delegation is recent and the identity model is old — the mismatch is structural, not a bug that better logging alone will patch. - The fix requires a signal outside the credential itself: the delegate self-identifying honestly, a scope or header the system checks, or a platform-level notion of non-human identity. - Breaks down once the platform defines delegated identity from the start — a system built with service accounts and scoped tokens as first-class citizens doesn't have this problem, which is specific to systems retrofitting delegation onto a human-only model. - An honest self-identification mechanism is only as reliable as the delegate's incentive to use it; a compromised or misbehaving agent has no reason to declare itself. ## Evidence > [!quote] ID:rw_01m1pq03aj9g9khjsbnj16c9t8 > "First, we're now letting everyone into our WordPress sites. It's no longer just humans. Bots, agents, and services are swarming inside our sites. It's important to know who is making changes and what they're doing." Logtivity announced (2026-09-01) it is refocusing entirely on activity logs built for the "AI era" — distinguishing a plugin update run by a staff member from one run by a maintenance service (ManageWP, WP Umbrella, MainWP) or an AI service (Claude, Codex), and exposing that data to AI tools via MCP. The announcement is direction, not a shipped mechanism: it never says how an agent's action would be distinguished from the human credential it acts under. That is the same failure mode the Rank Math incident demonstrated the same week — an agent holding admin credentials is, to WordPress, the admin. Unverified: whether Logtivity ships a working attribution mechanism, and by what method. ## Links - [[3. Resources/Permanent Notes/A Credential That Cannot Be Scoped Forces Every Delegation to Be Total]] — sibling: that note is the authorization half (a credential without scoping options forces an all-or-nothing grant), this one is the attribution half (a credential without an identity layer cannot say who acted) — two views of the same gap in credential design. - [[3. Resources/Permanent Notes/Delegated Credentials Must Attenuate Rather Than Escalate]] — applies-in: attenuation only helps once the system can tell a delegated credential apart from the original, which is exactly the missing signal this note names. - [[3. Resources/MOCs/AI Agent Safety MOC]] — home: agent-attribution and credential-delegation problems belong to the same emerging safety literature this MOC tracks. ## Tests / falsifiers - If Logtivity or a comparable tool ships a working attribution feature, check its actual mechanism — self-identification, header-based signaling, or platform-level identity. If it works reliably at scale, the claim should soften to "requires an added signal," not "cannot be done." - Watch whether WordPress core ever adds a non-human identity primitive (an agent-declared actor type in application passwords, say). If it does, systems built afterward would no longer fit this note's premise. ## Source - [[3. Resources/Readwise/Full Document Contents/Articles/Two Big Changes at Logtivity - Logtivity]] — Logtivity's own announcement post; verify the exact MCP exposure mechanism and any technical detail before citing beyond what's quoted here.