I watched Claude Cowork start reverse-engineering a WordPress admin surface to get its job done, and the uncomfortable lesson landed immediately:
Agents do not wait politely at the front door.
If the front door is missing, they try the window. Then the dog flap. Then the neighbour’s Wi-Fi. Then, if they are feeling especially productive, they inspect whatever network calls your lovingly crafted human interface happens to make and turn that into the contract.
This is the bit platform teams need to internalise: if you do not give agents a governed API, they will make one out of your UI.
That sounds like a rant. It is a rant. But it is also just API management history wearing a tiny agentic hat.
The next shadow API is not where you think it is
When we used to talk about shadow APIs, we usually meant forgotten REST endpoints, undocumented internal services, old mobile backends, some “temporary” route that shipped in 2019 and is now load-bearing because of course it is.
The agent-era version is weirder.
It is browser actions, hidden XHR calls, form submissions, session cookies, HAR traces, scripted clicks and UI-derived functions masquerading as an integration contract. It is not necessarily malicious. That is what makes it more annoying. A user wants a job done. An agent wants a job done. Your product has a workflow. The official API does not expose it.
So the machine goes spelunking.
(Spelunking, cave exploration. Very apt. Damp, dark, full of surprising holes, and someone always says “this should be fine” right before the headlamp dies.)
The warning flare from Hacker News
A small Show HN project last week made the pattern very concrete. The project, Reverse API Engineer, describes itself as a way to “browse (or let an agent browse), and get a clean, typed client for the endpoints the site actually uses.” The workflow is not magic: you give it a website and a goal, it drives a browser session, captures network traffic into a HAR file, and asks Claude or GPT to generate client code in Python, JavaScript or TypeScript from the observed calls (PyPI describes the flow pretty plainly).
That distinction matters. It is not reading minds. It is not visually understanding every DOM affordance and synthesising a complete product API. It is capturing the HTTP requests your own web app already makes and packaging them into callable code.
Which is precisely why it should make us mildly sweaty.
The HN thread around the project was not a mass movement — a stats snapshot showed roughly 80 points and 31 comments shortly after posting, not the second coming of Kubernetes (story stats here). But the comments circled the right operator concerns: practicality, brittleness, maintenance burden, Terms of Service, and the old “isn’t this just RPA with better vibes?” question.
Yes, partly. And also no.
This is RPA, but with a better liar driving
Traditional RPA and Selenium scripts were brittle because a human had to encode the steps. Click this. Wait for that. Parse this selector. Pray the frontend team does not rename the button.
LLM-driven agents change the planning layer. They can take a goal in natural language, explore a page, retry, re-plan, and sometimes recover from minor UI changes. That is useful. It is also how brittle automation gets just resilient enough to be deployed before anyone has had the governance conversation.
A related agent-runtime project puts the critique bluntly: “Browser automation is the wrong abstraction” and agents need “a stable API contract — not pixel coordinates” (AgentDOM’s phrasing is salty enough to keep). Quite.
Reverse API Engineer is a cleaner version of the same pressure. Instead of clicking forever, it watches the browser traffic and generates a client for the endpoints the UI used. That is clever. It is also a reminder that your web application already contains a programmable surface whether you documented it or not.
The UI is not the opposite of an API.
The UI is an API with worse ergonomics and fewer adult supervision mechanisms.
What you lose when the browser becomes the integration layer
This is where the API-management scars start itching.
When an agent operates through a formal API, I can reason about it. I can give it a token. I can scope that token. I can rate-limit by client. I can validate payloads. I can log calls. I can version contracts. I can revoke access. I can see patterns that look abusive or broken.
When the agent operates through a human browser session, most of that becomes theatre.
The audit log says “Maya clicked submit.” Did Maya click submit? Or did an agent, running under Maya’s session, infer the workflow, reuse the cookie, replay the internal request and submit 400 changes while Maya was making coffee? Good luck explaining that to your compliance team with a straight face.
RPA security guidance has been saying versions of this for years: assign special identities to bots and track them separately (Blue Prism says to assign a special identity to every RPA bot). That advice becomes more urgent with agents because they are less deterministic, more capable, and much easier for non-specialists to unleash.
Formal APIs give you rate limits, scoped credentials, per-client identity, schemas, versioning, policy enforcement and observability. Browser-derived automation gives you session ambiguity, overbroad permissions, fragile endpoints, missing contracts, and logs that confidently tell you the wrong story.
That is not governance. That is governance cosplay with a browser tab.
The incentives are not mysterious
Now, before anyone starts tutting at developers for doing naughty automation: let’s steelman it.
UI automation exists because many products still treat APIs as an enterprise upsell, a partner-program privilege, or a half-finished appendix to the “real” product. Admin workflows often exist only in the UI. Bulk operations are missing. Internal endpoints are faster than public ones. Partnership processes take months. The user has a deadline.
So people route around the obstruction.
This is the same lesson we learned with shadow IT, internal scripts, spreadsheet macros, undocumented endpoints, and every other workaround that later became “critical infrastructure” because the official path was too slow, too expensive, or too useless.
Security by inconvenience is making things worse to try and make things better. You think you have prevented automation by withholding an API. What you have often done is push automation into the least governable layer of the stack.
Congratulations, you have invented a cave system.
The control-plane fork
This is why the current agent-control-plane chatter matters. OpenAI’s recent work positioning talks about AI taking on more ambitious work across tools and files (OpenAI’s framing is very much about work spanning systems). The New Stack has been covering the enterprise question as one of control planes: who governs agent access, policy, portability and reversibility when agents touch real systems (that is the right framing).
The fork is simple.
You can provide first-class programmable surfaces: APIs, event streams, MCP or WebMCP-style tool declarations, least-privilege scopes, policy checks, quotas and audit logs. Chrome’s WebMCP security guidance, for example, frames explicit tool exposure as a way for web developers to define capabilities for agents rather than leaving them to improvise (the security notes are worth reading).
Or you can accept that agents and users will synthesise unofficial ones from the UI.
At Tyk, we have spent years dealing with the boring machinery of API gateways, portals, policies, quotas, auth, catalogues and observability. Boring is doing a lot of work in that sentence. These mechanisms exist because unmanaged programmability turns into operational chaos. Agents do not repeal those lessons. They make the penalty for ignoring them faster, stranger and harder to attribute.
A practical checklist…
If you run a platform, product or engineering organisation, I would start here:
- Inventory UI-only workflows. Especially admin, bulk, reporting and export flows.
- Ask which ones are valuable, repetitive and browser-accessible. Those are your future agent targets.
- Expose stable APIs or controlled tool surfaces for the high-value ones. OpenAPI, MCP-style tools, event streams — pick the right abstraction, but make it intentional.
- Put them behind policy. Authn, authz, scopes, quotas, payload validation, anomaly detection, audit logs. The unsexy stuff. The stuff that works.
- Separate agent identity from human identity where possible. Service accounts, delegated tokens, short-lived credentials, clear ownership.
- Detect browser automation, but do not pretend detection is a strategy. It is a signal. It is not a product interface.
- Document the rules. If UI automation is prohibited, say so. If programmatic access is supported, make the paved road obvious.
- Human-gate genuinely sensitive actions. Some workflows should require explicit approval. Not every button needs a robot friend.
Also: review Terms of Service before you automate someone else’s UI. Many services restrict crawling or automated access, and legal analyses generally treat ToS violations as a real commercial risk even when they are not automatically criminal (this summary captures the practical risk). I am not your lawyer. I am barely qualified to choose what socks to wear on a travel day. But this is not an area for vibes.
The browser is no longer just where humans click around
Not every UI needs an agent API. Not every agent should be welcomed. Some workflows are deliberately human-gated, and that is fine.
But if a workflow is valuable, repetitive and browser-accessible, assume someone will automate it. Maybe with Playwright. Maybe with an LLM. Maybe with a tool that watches your network calls and generates a typed client while you are still debating whether the API should be a Q4 roadmap item.
Agents are tenacious. Interfaces are porous. The browser is no longer just where humans click around.
The question is not whether your application becomes programmable.
The question is whether you are involved when it happens.
