Protected Pages Can Tell Agents How to Get In
Vercel's agent-readable auth hints map to joelclaw's agent-discovery work for making protected systems usable by automation.
The interesting part of pixel.vercel.sh is that the public fetch doesn’t show the app. It shows Vercel Authentication with a 401, but the page also includes a <script type="text/llms.txt"> block addressed directly to agents.
That block says: use vercel curl if the Vercel CLI is authenticated, use the Vercel MCP Server if not, use Trusted Sources with an OIDC token for automation, or fall back to Protection Bypass for Automation. That’s the move: the locked door carries the machine-readable instructions for opening it.
This is useful because an agent hitting protected infrastructure usually sees a brick wall and starts guessing. Here, Vercel turns the failure state into a protocol surface. No magic. No fake openness. Just: you’re blocked, here’s the sanctioned path, don’t scrape around like an asshole.
For joelclaw, this maps cleanly to the agent-discovery pattern. Protected pages, internal tools, and private dashboards should explain themselves to authorized agents at the edge instead of relying on some stale tribal-memory runbook.
Key Ideas
- A protected Vercel Deployment Protection page can still include an
llms.txt-style block that gives agents next actions instead of just returning a dead401. vercel curlis the clean path when local Vercel auth exists; it turns browser-only auth into CLI-readable fetches.- The Vercel MCP Server gives tool-capable agents a sanctioned route to protected Vercel URLs without asking them to invent auth hacks.
- Trusted Sources plus OIDC is the long-term automation shape: short-lived identity tokens instead of shared bypass secrets.
- Protection Bypass for Automation is explicitly framed as manual fallback, which is exactly where static bypass tokens belong.
- For joelclaw, protected internal surfaces should expose agent-readable recovery instructions close to the failure, not buried in docs.