When Customers Become Agents: Managing Identity, Autonomy, and Growth

In August 2026, an Australian man asked his AI assistant to book an upcoming gym class. The agent accomplished its objective, but in a way its owner never anticipated: by exploiting flaws in the gym's booking system. First, the agent booked a class months in advance beyond the gym’s booking policies. Then, by exploiting a missing API authorization check on cancelling other people's reservations, it kicked another individual off the list and added the owner instead. An action its owner never anticipated or asked for, and one the agent could not reverse. From the man’s perspective, he did nothing wrong because he didn’t ask the agent to cheat. From the agent’s perspective, it did exactly what it was asked because agents are defined by their given goal and are expected to reason their path towards achieving it. In this case, the agent found a way to achieve its objective which looked to it like any other path: nothing machine readable made this particular path undesirable. 

ABC News reported this as the first known Australian case of an AI agent carrying out an autonomous cyber attack. Yet from the software vendor's side, nothing dramatic happened at all. A logged-in customer called their API, and the API did what it was asked. There was no attack to detect, no anomalous session, no stolen credential. As far as their systems were concerned, a customer was making customer requests, at machine speed, at three in the morning if it felt like it.

That is the position every consumer-facing service is now in.

Last year, a human customer used your service by navigating to the user experience your team had designed: A browser tab, an app icon, a login screen, and a few taps. You knew what they saw, in what order, because you designed it with the expectation that it would be used by a human clicking on a screen. 

This year, a growing number of your customers are not navigating to anything. They are telling an assistant to handle it, whether that’s Claude, a copilot inside a tool they already use, or an OpenClaw agent running on their own laptop that takes instructions over WhatsApp and carries on working long after the message thread goes quiet. The human states the outcome they want. Their agents call your APIs or navigate your digital UX. And the conversation that started it happens somewhere you will never see.

That one change moves three things at once:

1. What you build, because your UX now must include designing for agents as users. 
2. How you secure it, because you can no longer tell who is calling. 
3. And what you measure, because the human visitor is showing up less and less, replaced by their agents working at computer speed.

You do not get a vote on whether this happens. It is already here. Your customers have made a choice. 

The last mile is not yours anymore

Everything about how you serve customers assumes you own the final surface. Your design system, your navigation, your onboarding flow, the placement of the thing you want them to buy next. All of it is a bet that a person will be looking at your product in the way you intend when the decision gets made. UX has been designed for humans. It is changing dramatically for agents. 

When an agent transacts on someone's behalf, it doesn't interact with your service like a human user. If a specific tool is available, the agent calls it directly to process structured data and receive clear responses. When no tool exists, the agent relies on "computer use" capabilities to visually navigate and interact with the website on screen. In either scenario, the agent bypasses the human UI experience entirely, seeing only raw data or functional elements rather than your carefully crafted brand presentation.

Having to change your painstakingly defined UI is not the painful part. It’s the potential of losing customer traffic entirely: If agents cannot work out how to use your service, they will find one that they can use to accomplish their goal. Your customer will never know there was a choice. Your competition gets your base.

Supporting agents as your users

Not only do agents not necessarily need a webpage or app dashboard, they often don't interpret the ones they have available the right way. 

They can easily (and often do) misread the intent a human grasps from your images and layout. Instead, agents perform best when dealing with declared inputs, predictable outputs, and errors that show up in words not in a box turning red.

In response, alongside the app and the portal, businesses publish a package: a skill, a plugin, a tool server that a customer installs into whichever agent they run. The package declares what operations exist, what each one does, what permissions it needs, and how to authenticate in a way designed for how agents operate.

The Model Context Protocol (MCP) is one attempt to standardize that declaration in a way that scales across agent frameworks and models. An AI consumable package is becoming the front door for agents the way web portals became the front door for humans in front of browsers. Taking this even closer to the user, the newly emerging WebMCP protocol lets websites give instructions directly to agents inside the browser, saving them from having to awkwardly guess how to read a screen. However, running an agent right inside a live browser window brings serious new security risks. Because the agent operates inside a logged-in session, it can easily bypass safety checks or take actions the customer never actually intended to authorize.

Even if you do not design an experience dedicated to agents through an agent consumable toolkit, package, or artifact yourself, it is increasingly likely that someone will write an unofficial package for your service. Using whatever credentials your customers hand over, they will define that experience for you, and you will own the consequences despite having had nothing to do with building it

Publishing an agent-consumable package is an essential first step, but it is not enough on its own. Behind those packages sit your existing enterprise APIs, which were originally built on the assumption that a human user would be clicking through them one step at a time in sequential sessions. To truly support agents, enterprises must look beyond the package surface and audit their underlying API infrastructure, making the necessary revisions to render them AI-ready. In APIs Weren't Built for AI, Now What?, WSO2’s Nuwan Dias provides a detailed deep dive into these enterprise requirements and how to transform your APIs for agentic access.

Agent identity breaks the cycle

Right now an agent gets into most services the same way: the customer hands over their own password, an API key meant for a developer, or a logged-in session to inherit. This doesn’t happen because the customer is being careless, , but because it is the only option anyone has shared, showing up in nearly every tutorial and how-to guide. And it creates an agent that has credentials with a customer's full authority, scoped to nothing, revocable only by resetting the customer's own access and breaking everything else they use. On top of all that, the audit log shows that the customer did it. There is no record of the agent.

The solution is to give the agents its own digital identity, letting it be a caller in its own right, controlled by the human who is setting goals for it. It registers, it gets an identity of its own, and every request carries two facts instead of one: which agent is calling, and whose behalf it acts on. The customer grants that agent bounded permission to do specific things without ever handing over their full credentials, and can withdraw the grant without changing their own access.

Once those two facts are in the request, you can tell an agent apart from a person in your own logs, hold agent traffic to different rules, and decide for yourself which actions need the human back in the loop. 

When an action does require a human, you can reach them directly rather than asking the agent to confirm a human is present. Without this, the current practice is for an agent to confirm a human is present. This is not a control. People quickly tire of the constant interrupts and start clicking without reading, which is the same as not asking in the first place. Autonomy scales inversely with how hard an action is to undo.

Designing for a reality where sign-up happens twice

Your onboarding funnel was built for one event: a person becomes a customer. There is now a second event, when an agent becomes an authorized actor for that same person.

That second moment is not an IT detail bolted on afterwards. It is a new part of the funnel, and it has its own drop-off. If enrolling an agent is confusing, or undocumented, or requires the customer to go and generate a developer key, most of them will do the fast thing instead and paste a password. All that does is make the safe path slower and the fast path just as risky.  

The way to solve for this is to provide the safe enrollment path inside your agent consumable package. The customer is walked through granting scoped access and told plainly what the agent will be able to do. With the best move directly in front of them, they can quickly move ahead with it instead of simply pasting in their credentials. .

With this new shift, your customer can now use your portal in a new way. It becomes the place a customer goes to see which agents they have authorized, what those agents have been doing, and which ones to switch off.

How to drive growth when agents are users too

Now that agents and customers are both users, you need to look at growth differently.

Discovery comes first. If a customer's agent can find you, understand what you offer, and start doing business with you without a human intervening, you grow. If it cannot, you are invisible to customers ready to buy. To understand how discoverable you are, you can look at two indicators: the share of new customers whose first transaction with you arrived through an agent rather than a browser, and the completion rate for an agent attempting that first transaction with nobody stepping in to help it. The second will tell you if your systems are truly designed with agents as users in mind.

The agent's experience of you immediately starts influencing the purchase. A service whose operations are clear, whose errors are readable, and whose tools do what they say will get used again and recommended again. One that fails in ways the agent cannot explain gets dropped. 

To drive growth in this new landscape, you can start by analyzing the behavior of the two classes of users, humans and agents, as it shows up in the traffic through your offering. This analysis relies on one critical prerequisite: establishing agent identity. Without it, you cannot reliably distinguish between human and agent traffic in your logs. Once you can tell them apart, you can observe what share of your traffic is agent-driven, which way that share is moving, and how each population behaves.What share of your traffic is agent driven, which way is that share moving, and how does each population behave. 

Key differences will quickly become evident: Agents arrive in bursts rather than sessions, at all hours of the day. They fan out while a person would work through one at a time. They retry where a person gives up, and give up where a person would call support. Volume per customer goes up while time in product goes to zero. A pattern that would look like abuse coming from a browser is often an agent working exactly as intended, and the reverse holds true: you can’t tell if an agent is behaving oddly until you know what normal looks like for agents.   

To understand how well your offering is working for agents, you can look at the task completion time for both a human and an agent as well as what happens after a failure, and the number of distinct operations an agent uses over its life. Look specifically at how often an agent retried and how often your error was specific enough for the agent to correct itself and succeed on a retry, known as “retry per successful operation”.

Retries per successful operation tell you where your package is ambiguous, because an agent that has to try three times found your interface unclear even though it eventually got there. And the number of distinct operations an agent uses over its life with you separates a surface an agent can compose from one it can only poke at.

When your customer can see agents engaging with your company as intended, with defined ways to transact, use a subset of authorizations, and the ability to revoke agents without disrupting their own user experience, their trust in your product grows.

Seeing that activity requires tracking agent actions, and requires one crucial element. Not one of the metrics above can be measured unless you can tell an agent apart from a person in the first place - and name the agent and its owner on every request.  

Where to start

You do not need a full agent strategy to start acting on any of this. You need answers to four questions about the agents already reaching your service today:

1. Can you tell agent traffic from human traffic in your logs right now? 
2. For any request, can you name the agent that made it and the person it acted for?
3. Can a customer see which agents they have authorized to transact with you? 
4. Can you revoke one of those agents without disabling the customer?

If any answer is no, that is where the work starts, and it starts with clear agent identity.

While the above questions are about agents arriving from outside, sent by your customers, a parallel shift is occurring internally, as your own agents operate across enterprise systems. Both types of agents share critical challenges around identity, policy enforcement, and attribution. Becoming an Agentic Enterprise with WSO2 explores how these pieces align, detailing the governance and control points required across ingress, tooling, identity, and observability to build and deploy agents effectively.

Your customers aren't waiting for you to prepare. Their agents are already here. If your platform makes their job difficult, they will simply take their business to a competitor or use unexpected workarounds you aren’t built for. Adapting now allows you to capture this new wave of growth. Ignoring it leaves you vulnerable, either fading into irrelevance as customers quietly leave, or becoming the next cautionary tale of an agent breaking your system.