# Agent Capability Scope Is the New Trust Boundary ## Claim When software delegates capability to a remote agent, the trust boundary moves from the code a user installed to the operator running the agent, and no amount of scrutiny of the installed code closes that gap. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any delegated-capability integration — an AI support agent, remote management tooling, a hosted service acting on a user's behalf through a credential it holds. - Strengthens as the credential's lifetime and scope grow: a non-expiring, admin-equivalent credential with no revocation trigger is the strongest case; a short-lived, narrowly-scoped, user-initiated token is the weakest. - The installed plugin's own code quality becomes nearly irrelevant to this specific risk, which is why counting a vendor's historical vulnerabilities is the wrong lens on a consent-failure incident — vulnerability counts measure code defects, not delegation exposure. - Breaks down where the remote party has no standing access at all — a one-time, user-triggered API call with no persisted credential doesn't create an ongoing trust boundary the way a stored Application Password does. ## Evidence > [!quote] ID:rw_rankmath_h1 > "the plugin immediately creates a WordPress Application Password for that user. It sends that password to group[.]one's servers." Rank Math 1.0.277's Support Agent inherits the opening administrator's full capabilities via a standard WordPress feature (Application Passwords) and transmits that credential off-site, non-expiring, with no toggle to disable it. Nothing here is a vulnerability in the conventional sense — no exploit, no privilege escalation. The risk profile shifted entirely to a party the site owner never evaluated: group.one's credential storage, its AI agent's resistance to prompt injection, its own access controls — none of which the affected WordPress site can audit or configure. ## Links - [[3. Resources/Permanent Notes/A Shared Kernel Is Not a Trust Boundary for Untrusted Agent Code]] — because extends; both name a case where the intuitive trust boundary (the container, the installed plugin) is not where the actual threat model lives — the real boundary sits one layer further out than the obvious one. - [[3. Resources/Permanent Notes/Consent Is a Gate Not a Notice]] — because pairs-with; consent gating is the control that would let a user decline this exact transfer of trust before it happens, from the same source. - [[3. Resources/MOCs/AI Agent Safety MOC]] — because applies-in; a direct evaluation question for any AI feature under review — not "is the code safe" but "who holds the credential this feature creates, and for how long." ## Tests / falsifiers - Audit a sample of top-100 WordPress plugins for programmatic Application Password creation (`wp_create_application_password()` calls) and score each by credential lifetime, scope, and revocability. If most delegated-capability features already use short-lived, narrowly-scoped credentials, this incident is an outlier rather than a category-defining case. - Track whether WordPress.org's Plugin Review team begins evaluating "credential delegation scope" as a distinct review criterion separate from vulnerability disclosure — its emergence as a formal category would support the claim that this is a genuinely new trust boundary, not just a variant of existing security review. ## Source - [[3. Resources/Readwise/Articles/Rank Math WordPress Plugin Accused of Secretly Taking Admin Access]] — Roger Montti, Search Engine Journal, 2026-08-30. The article's own vulnerability-count coda (7/2024, 4/2025, 3/2026) is uncited and unnormalized by install base — this note deliberately does not use that framing, since raw vulnerability counts measure a different thing than credential-delegation exposure.