Your Next AI Agent Won't Need an API. It'll Just Log In.

Until recently, connecting an AI tool to a piece of business software meant going through an API: a structured, permissioned channel a vendor had to build and expose on purpose. If your accounting package, your industry-specific booking system, or your bank's business portal never built that connector, automation stopped at its front door. A newer class of AI agents changes that. Often called computer-use or browser agents, they operate software the way a person does — opening a browser, typing a username and password, reading the screen, clicking the right button. Anthropic's Claude, OpenAI's Operator, and Google's browser agent all now ship this capability. The practical effect is that almost any web-based tool with a login screen is, in principle, something you can hand to an agent, whether or not its maker ever intended that.

This matters more for ordinary businesses than the framing usually suggests. The API-integration wave of the last decade mostly served software with the market share and engineering budget to build connectors — major CRMs, major accounting platforms, well-funded SaaS tools. A regional supplier's ordering portal, a niche trade association's booking system, a bank's own web banking interface: these stayed locked out, not because automating them was a bad idea, but because nobody with the resources to build an API connector had a reason to. Computer-use agents don't need one. They use the same login screen a person would, which is why the businesses most likely to benefit are the ones that never had budget for custom integration work in the first place.

The decision this creates is not whether to use a tool like this, but what to hand it once it's logged in. A set of credentials doesn't come with judgment attached. Give an agent a username and password and it can, in principle, do anything a person signed in with those credentials could do — place an order, change a saved payment method, submit a form with a typo nobody caught. A human employee doing the same job would notice when a page looks wrong or hesitate at an unfamiliar confirmation dialog. Current agents are improving at that kind of caution, but the vendors building them are candid that it isn't reliable yet: under ambiguous conditions, an agent is still meaningfully more likely than an attentive person to click through something it should have flagged.

That points to a sensible boundary, and it isn't "which software to allow" — it's "which actions within that software." Start with a dedicated login for the agent, never a shared human one, scoped to the narrowest role the software's permission system allows — the same least-privilege principle already applied to a new employee or an outside contractor, just extended to a non-human user. Read-only and data-gathering work, like checking an order's status or watching a supplier's price list for changes, is a reasonable place to start, because a mistake there costs time, not money. Anything that moves money, changes banking details, or commits the business to a supplier deserves the same second-person confirmation you'd expect of a brand-new hire handling that task for the first time — not because the agent is untrustworthy, but because it hasn't yet earned the judgment call.

There's a quieter problem worth naming alongside the access question: the audit trail. A human employee's actions inside a system are traceable to them personally, and most software's activity logs were designed around that assumption. An agent acting through a shared or generic login blurs that trail — if an order goes out wrong, working out whether it was the agent, a compromised credential, or an actual person becomes far harder after the fact. Before putting any computer-use agent in front of live business software, confirm the platform can log the agent's actions distinctly from a human's, the same discipline already applied to service accounts and API keys.

None of this argues for holding back. The businesses with the most to gain are precisely the ones the API-integration era left behind — running ordinary web software from smaller vendors, with no developer on staff to request a connector, that now has a real path to automating routine work without waiting for that vendor to catch up. What it argues for is treating agent access with the same care a well-run business already applies to a new hire's system access: start narrow, log everything distinctly, put a second check on anything that can't be undone, and widen the agent's reach only as it demonstrates it deserves it.

The mistake sits at either extreme. Locking an agent out of everything because the risk feels unfamiliar throws away a capability that's now genuinely useful for software that was never going to get an API. Handing over a shared admin login because scoping access properly takes an extra hour trades a small amount of setup time for a risk disproportionate to what was saved. The businesses that get real value from computer-use agents will be the ones that treat the login screen an agent just walked through as seriously as they'd treat handing a stranger the keys to the office — which, functionally, is what they're doing.