Almost Every Session Was About Bots Link to heading

I went to Ping YOUniverse in Sydney on 13 August. Identity conference, identity vendor, identity crowd.

One session was about logging a human into a device, and it was the sharpest thing on the floor. I will come to that first, because it is the last good news in this post.

Everything else was about agents.

Not booking agents. Not travel agents. Software agents, driven by large language models, running on a laptop or in a data centre, doing things on behalf of a person who may or may not be watching. That was the rest of the day, and it was the right call, because that is where the problem has moved.

First, the Good News Link to heading

The human session was a demonstration of Keyless, a London company Ping announced it was acquiring last October and closed on in January. It is now being taken global on the back of the Ping platform, and having seen it run I understand why they bought it.

You log in with your face. Ordinary camera, no special hardware, no dedicated device. Quoted time to authenticate was 300 milliseconds, and the demonstration did not appear to be lying about it.

The clever part is not the speed, it is what is stored, which is nothing. At enrolment the client takes two or three seconds of video and produces a lock on the server side. From then on your face produces the key, client side, in under half a second. There is no biometric template sitting in a database waiting to be breached, on the server or on the device. The transformation is one way, the pieces held by each party are useless on their own, and neither side ever learns anything about your face beyond a yes or a no. It is secure multi-party computation doing the work, not a stored image and a similarity threshold.

Which is why calling it biometrics undersells it. Your face is the input, but nothing biometric is retained, so the usual objection to face login - that a biometric is a password you can never change and are about to hand to someone who will eventually lose it - does not apply. You cannot leak what was never stored.

The user provides a username and a face. The server decides yes or no. Smart maths, not a passkey, not a template, and no shared secret anywhere in the flow.

That is exactly the direction the last post argued for: stop trusting anything the user can tell you, and move to proof that cannot be copied out and replayed. It works, it is fast enough that nobody will complain, and it is shipping. No idea what it costs, mind you. That sort of thing tends to be priced on how badly you need it.

Enjoy the peace of mind it might bring you though, because that was the security high point.

Shadow IT Grew Up Link to heading

The framing that stuck with me was the redefinition of shadow IT. Shadow IT used to mean the marketing team expensing a SaaS subscription nobody in IT approved. It now means an agent running on an employee’s desktop, with that employee’s credentials, doing real work against production systems, entirely outside any control plane the sysadmin has access to. Same category, vastly higher blast radius. Your data loss prevention tooling is watching the browser. The agent is not in the browser.

The vendor response is what you would expect and it is arriving quickly: give the bot its own identity, its own privileges, its own control plane, its own risk profile. Ping had a working demonstration of agent privilege control, and while the honest caveat is that it currently needs to be installed on the user’s desktop to be effective, the idea underneath it is sound.

But the demonstration was not the thing that got me.

The Chart That Moved Link to heading

What got me was a chart.

It was a plot of an agent’s actions over time, with a risk signal rising and falling as it worked. Not a decision. Not a gate. A moving line. Some actions pushed it up, others let it settle back down, and when it crossed a threshold something happened.

I have spent enough time around financial services to find that completely unremarkable in its original context. Transaction risk scoring is ancient technology in payments. Nobody in a card scheme has thought about fraud as a per-transaction pass or fail for decades. They look at the sequence, the velocity, the deviation from a known pattern, the merchant category, the device, the hour of the day, and they produce a number. The number moves. When it moves too far, you get a step-up challenge, and the rest of the time you do not even know it happened.

Seeing that same shape applied to API calls was the light-bulb moment, and I am slightly annoyed it took a conference to trigger it, because it is obvious in hindsight.

We do not do this with APIs. We authorise each call in isolation. Present a valid token with the right scope and the call succeeds, every single time, with no memory of what came before it and no opinion about what it means in sequence.

Consider two sessions. The first is login -> profile -> action -> result. The second is login -> privilege uplift -> change contact details -> change password. Every individual call in the second sequence can be perfectly authorised. The token is valid. The scopes are right. Each one passes on its own merits. And the shape of it is an account takeover in progress, visible to anyone looking at the sequence rather than the calls.

We are not looking at the sequence. We should be. There is more to say on that, and I will say it in the next post.

The Gap Nobody Has Closed Link to heading

Here is the actual state of the industry, stripped of the marketing.

We have not agreed on how to tell the difference between a human and an agent. We have not agreed on how to express what authority a human granted to an agent. We have not agreed on how a service should verify either of those claims. There is no standard. There is no interoperable profile. There is not even consensus on the shape of the answer.

What there is instead is a gold rush. Everyone and their dog is shipping an identity for agents, a wallet for agents, a credential for agents, a registry for agents. All of it proprietary, all of it incompatible, all of it convinced it will be the one that wins. It is the wild west, and the thing about the wild west is that it is a wonderful environment for people with bad intentions.

Because in the absence of a standard, “trust me, I am a good bot” is just a string in a header. Anyone can send it.

Two Camps Link to heading

There are two schools of thought about how to close this, and they are genuinely opposed.

Camp one says the agent should just be you. Your agent uses your credentials, your session, your identity. As far as any service is concerned, it is you at the keyboard.

The steelman for this is stronger than its opponents admit: it works today, it requires no new standards, no coordination and no adoption curve, and critically it routes around the fact that half the web is actively blocking agents from doing anything useful. If the only way to get the job done is to look like a human, people will make their agents look like humans. That is not a hypothetical, it is happening right now, and no amount of disapproval changes the incentive.

Camp two says the agent should have its own identity and carry a mandate. The agent authenticates as itself, distinctly from any human, and presents a delegation that says which human it acts for and precisely what that human authorised.

I am firmly in camp two, and the reason is attribution.

If your agent acts as you, then everything it does has your name on it and no way to distinguish. That sounds fine while it is booking restaurants. It sounds considerably less fine when it deletes a production table, sends an email to a customer that should never have been sent, approves something it should have escalated, or spends money it should not have spent. All of those have your name on them, your credentials behind them, and your signature on the audit record.

And you have a defence available: “that was not me, that was the bot.”

Think about what that does to every process that depends on knowing who did what. Incident review. Disciplinary process. Financial dispute. Regulatory investigation. Legal discovery. Every one of them rests on non-repudiation, and camp one destroys non-repudiation by design. You cannot have accountability in a system where the accountable party has a permanent, unfalsifiable excuse.

It is worth noting that the defence works in both directions, too, which is worse. An attacker who compromises your session gets to hide behind the same excuse, and you get to spend six months proving a negative.

Consent Fatigue Is the Failure Mode Link to heading

There was a point made at the conference that I have not stopped thinking about, because it describes something I have done myself.

The current approach to agent safety is human-in-the-loop approval. The agent proposes, you approve. Sensible on paper. In practice you approve, and approve, and approve, and after the fortieth prompt in an afternoon you stop reading them. Then you find the setting that turns them off, because the prompts are the friction and the work is the point.

And that is exactly when it goes sideways. Not on prompt one, when you were paying attention. On prompt four hundred, when you were not, or on the first action after you took the restraints off entirely.

Any control that depends on a human staying alert across hundreds of low-consequence decisions is not a control. It is a liability transfer. The fix is not more prompts, it is fewer and better ones: reserve the interruption for the things that genuinely warrant it, and let the rest through under constraints agreed in advance. Which is another way of describing risk-based step-up… which brings us back to that moving chart.

What an Agent Credential Actually Needs Link to heading

I have done a fair amount of work on this question, so let me set out what I think the shape of the answer looks like without pretending it is settled.

Its own identifier. The agent is not the human. It is a distinct principal with its own lifecycle, and it can be revoked without revoking the human.

A mandate that is explicit and bounded. What the agent may do, in what domain, up to what limit, until when. Not a scope string that means “everything this user can do”, but a genuine constraint set that a relying party can evaluate. The primitives for this mostly exist already, scattered across specifications that were written for other reasons: token exchange for downscoping a user’s authority into something narrower, rich authorisation requests for expressing detailed constraints rather than coarse scopes, verifiable credentials for portable claims. Nobody has agreed on how to compose them for this purpose, but we are not starting from nothing.

Proof it is running where it claims to be running. This is where I think the endgame is, and it is not popular because it is inconvenient. Hardware-locked keys. A key generated inside a secure element that cannot be exported, with an attestation chain back to the manufacturer, and every request carrying a signed proof of possession. DPoP has been a published RFC since 2023 and does exactly this job. A stolen token without the hardware is worthless, which is the property you want when the token carries authority to spend money or change production state.

A trust level, not a trust boolean. And this is the thread that ties the whole day together. A key in certified discrete hardware deserves more authority than a key in a firmware TPM, which deserves more than a key sitting in a software keystore in a container someone can docker exec into. All three might be legitimate. They are not equally trustworthy, and the authority granted to each should reflect that.

That is the shift I keep coming back to. We have spent thirty years building authentication as a binary. Valid or invalid. Authorised or denied. In or out. That model cannot express the thing we now need it to express, because the interesting question is no longer “is this credential valid”, it is “how much do I trust this actor, right now, given what it is asking to do and everything it has done in the last five minutes”.

Everything should be risk rated. Nothing should be binary.

Meanwhile, We Are Just Blocking Them Link to heading

While the industry works this out, the default response from the services on the receiving end has been to block anything that looks like a bot. All bots are bad. Challenge everything.

GitHub did it for a while. If you were vibe coding and told your agent “here is a repository that seems to solve this, go and read it”, the agent got nothing. No soup for you. So the agents found a way around it, as they always do, and eventually GitHub gave up. Cloudflare took a more entertaining approach and started feeding suspected scrapers into a maze of generated content, which is at least good sport.

I have sympathy for how this started. The first wave really was indiscriminate scraping for training data, taking bandwidth and giving nothing back, and a WAF rule was the only lever available. That was defensible.

It is not defensible now, because the population has changed. A large and growing share of automated traffic is somebody’s legitimate work: an agent researching a purchase, reading documentation, comparing prices, filling in a form on behalf of a person who asked it to. Blocking that is not security. It is refusing a customer.

And the customer does not give up. They go to a competitor whose site the agent could actually use. That is the part I do not think has landed yet in the boardrooms currently signing off on “block all bots” as a policy. You are not stopping the transaction, you are redirecting it.

The purchase case is the one people get most nervous about, and I think the nerves are misplaced. Airlines already hold a seat for twenty-four hours without payment. Twenty-four hours is extraordinarily generous; four would be plenty. The mechanism for “a booking that is not yet final and can be unwound” is already built, already understood by finance teams, already reconciled. We do not need to invent agent commerce from scratch. We need to accept that some purchases will be made by bots, that some of those bots will get it wrong, and that the correct response is a controlled path with a reversal window rather than a locked door.

Embrace them, with caution and control. That is a product decision, not a security one.

What I Am Actually Going to Do About It Link to heading

I gave a version of this argument to a room of people in January, eight months ago. Almost all of it has since come to pass, built by other people, because the people I pitched it to could not see the value at the time. That is fine. The story is still being told, and being early and unfunded is a very common combination.

What I have concluded is this. I cannot make a standard happen. I am one person with a strong opinion and a conference lanyard. What I can do is advocate for one loudly, and build everything I touch so that the identity and mandate layer is separable, replaceable and ready to be bent to whatever standard actually lands in the next twelve to twenty-four months.

Because something will land. And the organisations that spent this window blocking every bot on sight will find they have to rebuild anyway, from a worse starting position, with a customer base that already learned to shop somewhere else.

So what do you actually do while we wait? That’s the next one.

This post is part of a series on identity and agents. Previously: Auth Is a Solved Problem on why authentication is still broken everywhere. Next: Let the Good Bots In on planning for the bot swarm.