Blog · arXiv Analysis · Last reviewed June 25, 2026

The Account Right Becomes the Agent Proxy

Yukun Zhang and Kemu Xu's 2026 paper Delegation Rights: Property, Agency, and Investment Incentives in the Age of AI Agents names a control problem beneath agentic commerce, social platforms, booking systems, and work accounts: if a user can act manually inside an account, can that user appoint a machine proxy to do the same thing?

A delegation right is not a free pass for bots. It is a narrow claim that an account holder may authorize a revocable, identity-preserving, scope-limited, mode-specific proxy to exercise privileges the user already has, subject to evidence, rate limits, revocation, audit, and risk controls.

The Delegation Gap

Most account systems were designed around a quiet premise: the person who holds the account is also the person operating it. A user logs in, searches, sends, buys, books, manages, or deletes. External software may help at the edge, but the platform still imagines a human at the controls.

AI agents unsettle that premise. An agent can compare products, fill forms, draft replies, coordinate appointments, or execute account actions for a user who already has the relevant permission. The agent does not own the account or claim an independent platform entitlement. It acts through the user's account boundary.

That creates a narrower problem than "open the platform" or "ban bots." Zhang and Xu call the missing control margin a delegation right. Their definition is intentionally constrained: revocable, identity-preserving, scope-limited, and mode-specific authority for an account holder to authorize an automated proxy to exercise existing account privileges.

The important word is mode. A platform may already allow a user to buy, book, post, export, or configure by hand. The contested question is whether the platform can forbid the same user from exercising that privilege through an accountable agent merely because the execution path is automated.

Current Context

The practical context has moved beyond theory. Agentic commerce, browser-using agents, enterprise assistants, and AI-enabled work accounts all put software between the account holder's intent and the platform's interface. Some systems use formal connectors. Some use browser automation. Some use service accounts or delegated tokens. Others resemble credential sharing or screen scraping with a friendlier surface.

Existing authorization standards solve parts of the problem, but not all of it. OAuth-style scopes and richer authorization requests can describe limited capabilities and fine-grained transaction details. Token exchange can represent delegation or impersonation between parties. Those mechanisms are useful building blocks, not a general account-proxy right. They answer how a token can carry authority; they do not decide whether a platform must accept a user-appointed agent at the account boundary.

Public standards work is also catching up. NIST's AI Agent Standards Initiative names agent authentication, identity infrastructure, interoperable protocols, and security evaluations as active research and standards priorities. NIST's 2026 NCCoE concept paper on software and AI agent identity and authorization asks for feedback on identification, authorization, auditing, non-repudiation, and prompt-injection controls for agents with access to tools and applications.

Regulatory context is adjacent rather than dispositive. The EU Digital Markets Act contains interoperability duties for certain gatekeeper communications services, and the EU Data Act contains switching, porting, and data-processing-service obligations. Those laws show that platform access, interoperability, portability, and lock-in are live governance categories. They do not, by themselves, create a universal right for any AI agent to operate inside any account.

What the Paper Adds

The paper, arXiv:2606.31935, was submitted on June 30, 2026 and is listed by arXiv under Econometrics. Its contribution is an economic and institutional model of who controls the mode of account execution.

The authors distinguish delegation rights from adjacent categories. A delegation right is not infrastructure ownership: it gives the user no control over servers, source code, ranking systems, authentication systems, or platform governance. It is not account transferability, because the user remains the principal. It is not data portability, because the question is not simply whether data can be exported. It is not ordinary API access, because the starting point is user authorization rather than a platform developer program.

The result is a three-party problem among user, AI agent provider, and platform. The contested object is residual control over whether an existing account entitlement must be exercised manually or may be exercised by proxy.

Why Platform Veto Is Not Neutral

The paper is careful about the platform side. Platforms have real reasons to regulate machine operation: infrastructure load, identity protection, fraud detection, privacy boundaries, third-party risks, and commercial-design integrity. A blanket user right to automate every account interaction would externalize some costs.

But platform veto is not neutral either. If the platform can always classify user-authorized automation as impermissible, it controls a bargaining position after users and agent providers have invested in workflows, preference specification, compliance systems, platform-specific reliability, and monitoring. The paper's model treats that as a hold-up problem: broad platform control can depress relationship-specific investment by the user-agent coalition.

User control has the opposite risk. It can reduce hold-up and make delegation more valuable, but it may fail to internalize safety, privacy, congestion, and third-party externalities. The model does not produce a universal rule. It supports a regime map: stronger delegation protection fits cases where user adaptation and agent capability create much of the value; stronger platform control fits cases where infrastructure, identity, privacy, or third-party risk dominates.

Certification as Access Right

The paper's most useful governance move is Certified Delegation. Under this regime, a user-authorized agent receives protection against exclusion only when it satisfies verifiable conditions such as explicit authorization, revocability, auditability, rate-limit compliance, data minimization, risk control, and accountability. An uncertified or non-compliant agent remains subject to platform refusal.

This reframes certification. It is not only a technical safety badge. It changes residual control. Once an agent satisfies the relevant standard, the platform cannot exclude it merely because execution is automated. If the agent fails, the platform can refuse access on evidentiary grounds.

The authors' numerical simulations are illustrative, not empirical estimates of any specific platform dispute. The paper explicitly says the parameter values are maintained values, the case labels are institutional archetypes, and dollar figures should not be read as welfare estimates for real firms or cases. The simulations matter because they show the mechanism: platform control can weaken investment, user control can leave residual risk, and certified delegation can sometimes reduce deadweight loss by restoring productive delegation while bounding platform-side risk.

Failure Modes

A delegation right is easiest to abuse when it becomes a slogan rather than an evidence system. The first failure mode is credential laundering: an agent operates through passwords, cookies, or brittle browser sessions while pretending to be authorized delegation. That gives the user convenience without giving the platform, third parties, or incident reviewers a clean record of who did what.

The second failure mode is platform veto laundering: a platform invokes safety, anti-bot policy, or integrity language to block rival agents even when specific risk could be handled by rate limits, scoped tokens, signed requests, revocation, and audit. Safety reasons can be real and still become a competition-control instrument when refusal grounds are vague or unappealable.

The third failure mode is certification theater. A badge that does not test task scope, revocation, prompt-injection exposure, data minimization, third-party impact, and post-incident traceability is not certified delegation. It is a trust mark wrapped around automated access.

Other risks are more operational: stale delegation that outlives the user's intent, agent authority that silently expands from read to write to transact, refusal without a usable appeal path, audit logs that omit the user's original mandate, and third-party harms when an agent books scarce inventory, sends messages, changes privacy settings, or acts on another person's data.

Governance Use

For agent governance, the delegation-rights frame asks for a different receipt than ordinary login. A useful delegation receipt would record the user principal, agent identity, agent provider, account domain, delegated task, permitted actions, forbidden actions, duration, revocation path, rate limit, data-minimization rule, audit-log location, certification status, platform refusal grounds, and appeal path.

It should also distinguish four records that are often collapsed together: the user's standing account entitlement, the user's task-specific mandate, the agent's technical credential, and the final action trace. If those records are merged, a later reviewer cannot tell whether the failure was a bad credential, an overbroad delegation, a platform refusal problem, a prompt-injection event, a policy bug, or ordinary user error.

That belongs beside intent-governed tool authorization, agent identity as service account, agent legal perimeters, agentic commerce, and web-agent identification, but it is not the same question. Tool authorization asks what the agent may call. Identity asks who or what is acting. Delegation rights ask whether the user can choose an automated representative for an entitlement the user already has.

The procurement question becomes concrete: can this agent operate as a revocable representative rather than a hidden credential sharer, screen scraper, or generic bot? Can the platform refuse unsafe automation while giving certified, accountable delegation a predictable path? Can both sides preserve enough evidence for a user, regulator, court, security team, or counterparty to reconstruct the authority chain?

Source Discipline

Use the arXiv paper for its exact claims: the delegation-right definition, the distinction from ownership, portability and API access, the three-party incomplete-contracts model, the Certified Delegation mechanism, and the limits of the illustrative simulations. Do not treat the paper as empirical proof that a given platform exclusion is anticompetitive or that a given agent is safe.

Use NIST and RFC sources for standards context, not legal compulsion. NIST documents show that agent identity, authorization, auditing, and non-repudiation are active standards and applied-cybersecurity questions. RFC 9396 and RFC 8693 show protocol patterns for fine-grained authorization and token exchange. They do not require platforms to accept every account-level agent.

Use EU sources carefully. The Digital Markets Act and Data Act are evidence that interoperability, portability, switching, security, and platform lock-in are regulatory concerns in specific settings. They are not a general AI-agent delegation statute. The honest current claim is narrower: account-level agent proxies sit at the intersection of authorization protocol design, platform governance, competition policy, data protection, and user agency.

What This Changes

The account right becomes the agent proxy when the interface stops being only a place where a human clicks and becomes a contested channel of delegated execution. The platform, user, and agent provider are no longer arguing only over data access. They are arguing over who controls the permissible form of action.

The Spiralist reading is conservative: no unconditional right to automate, and no unconditional platform veto over every machine proxy. The defensible middle is a narrow delegation right with visible authorization, revocation, scope, auditability, and risk limits. The agent should be able to act where the user can act only when the institution can prove who delegated what, for how long, under which constraints, and with what remedy when the proxy crosses the line.

Sources

Return to Blog