The Agent Signup Problem Nobody's Talking About

You've probably heard about robots.txt. It's been telling web crawlers where they can and can't go since 1994. You might know about llms.txt for AI context, or .well-known/security.json for reporting vulnerabilities. But here's what's missing: a standard way for a website to tell an AI agent, "Yes, you can create an account for my user—under these conditions."

This gap matters more than you might think. In 2026, AI agents aren't just reading web pages anymore. They're acting as delegated users. They're filling out forms, creating accounts, trying APIs, and signing up for trials—all on behalf of a real human. But from the server's perspective, this looks indistinguishable from spam automation. No wonder both sites and agent builders are confused.

Why Existing Standards Don't Cut It

Let's be honest: the web's current "policy files" are fragmented.

• robots.txt handles crawling permissions for search engines
• llms.txt provides context and usage guidelines for AI models
• sitemaps enumerate URLs for indexing
• OpenAPI and MCP expose callable interfaces
• security.txt points to responsible disclosure contacts

None of these address account creation. And that's a critical blind spot because account creation isn't passive browsing. When an agent creates an account, it:

• Changes persistent state on your platform
• Potentially triggers rate limiting or abuse detection
• Affects your signup metrics and funnel analytics
• Binds a user to your terms of service
• Could lock your system into unexpected behavior patterns

You can't just slap a "yes/no" policy on this. The stakes are too high, and the use cases are too varied.

Introducing: The Agent Policy Manifest

A new experimental proposal—wkdomains.agent-policy.json—attempts to solve this by creating a machine-readable manifest at /.well-known/agent-policy.json. Think of it as a detailed, granular permission system for AI agents.

The key innovation isn't a binary allow/deny. It's permission tiers.

Instead of "can agents create accounts?" the manifest answers:

• What can agents do when browsing publicly? (Read pages, follow links, check pricing)
• What requires explicit API access? (Sandboxes, test modes, documented agent flows)
• What conditions must be met for user-delegated signup? (Verified human intent, transparent identity, audit trails)
• When must agents absolutely stop? (Payment required, fake identity needed, material liability terms)

How Permission Tiers Actually Work

Imagine you run a SaaS platform. Your new agent policy might say:

Public exploration mode: Enabled by default. Agents can read your docs, pricing page, and feature list.

Declared automation mode: Only through your official API or sandbox environment.

User-delegated signup mode: Conditional. Agents can create trial accounts if:

• The human user's intent is verified (not automated)
• The agent's identity is transparent (not impersonating a human)
• The email follows a pattern like user+agent-{domain}@example.org (traceable)
• You maintain an audit log the user can see
• The agent stops before asking for payment or material business terms

This last point is crucial. The manifest distinguishes between:

• Routine checkboxes (like "I accept the privacy policy"): Can be allowed with disclosure
• Material liability terms (legal indemnification, payment obligations): Require human confirmation, full stop

The Architecture Behind the Proposal

Here's what a real agent-policy.json might look like:

The manifest starts with metadata (schema version, domain, expiration date). Then it defines sections. The account_creation section is where the magic happens.

Within account creation, you specify:

• Default mode (what agents assume if they find no policy)
• Available modes and their conditions
• How terms acceptance is logged
• What triggers hard stops

The "hard stops" are worth studying:

• Captcha or bot detection challenges
• Terms that explicitly prohibit automated accounts
• Fake identity requirements
• Payment methods
• Phone verification
• Public posting or messaging
• Material liability acceptance
• Unknown terms impact

When an agent encounters any of these, it should stop and ask the human user to take over.

Processing Rules: What Agents Should Do

The proposal includes clear guidance for agent behavior:

No file found? Default to public exploration only. Read and summarize, but don't automate signup.

Explicit allow in the manifest? Proceed only within the named section and limits. Log the manifest URL and the acting human.

Routine checkbox triggering? Allowed with disclosure, if the policy permits and you log the action.

Material terms? Stop immediately. Don't let an agent accept liability, payment obligations, or business terms on behalf of a user.

Why This Matters for Developers

If you're building AI agents, this standard gives you a north star. Instead of writing custom logic for every platform, you can:

• Check for the manifest first
• Parse permission tiers consistently
• Implement safe fallbacks when policies don't exist
• Build transparent audit trails that users can trust

If you're running a platform, this standard gives you granular control. You can:

• Encourage agent-assisted signup without losing security
• Create separate policies for different user types
• Maintain audit trails for regulatory compliance
• Signal to agents exactly where your boundaries are

And for users? You get transparency. You can see exactly what an agent is allowed to do on your behalf, and you own the audit log.

The Experimental Phase: What Comes Next

This is still a draft proposal from wkdomains.com, proposed for discussion by domain owners, bot builders, standards people, and agent builders. It's experimental—which means it could change, improve, or even be replaced as the community learns more.

The proposal expires November 1, 2026, to encourage rapid iteration rather than premature standardization.

The Bigger Picture

We're at an inflection point. AI agents are becoming delegated users, not just crawlers. The web's permission infrastructure hasn't caught up. robots.txt works for search engines because the incentives are simple: search engines want to crawl; publishers want visibility.

But AI agents creating accounts? The incentives are more complex. Platforms need safety. Users need transparency. Agents need clear guardrails. A standard like agent-policy.json doesn't solve every edge case, but it gives everyone a common language.

If your platform allows agent-assisted signup, it's worth thinking about publishing an agent policy. If you're building agents, it's worth checking for one. And if you're a developer interested in standards, this is a great time to weigh in on the proposal.

The alternative? Keep guessing. And in an age of smarter agents and more sophisticated automation, guessing isn't good enough anymore.