On Whose Authority? The Identity Question in AI Agent Security

I bought the same domain twice. Neither registration survived.

I bought a domain from Hostinger. The registration was cancelled and the payment refunded, and I had not asked for either. So I bought it again. Same result.

On 9 October an email told me the registration had been cancelled. I wrote back, and Hostinger’s AI support agent answered:

You’re right: you asked to purchase the domain, not to refund it. I’m sorry the registration was refunded and canceled.

It had checked the records. The payment had been fully refunded, the domain was no longer active in my account, and it was not flagged for suspicious review. Then came the line I keep coming back to: “the records don’t show why the refund was issued, so I can’t confirm what triggered it. I have not submitted another cancellation or placed a new order.”

Its suggestion was that I buy the domain again.

I asked to talk to a human. The agent checked again, told me the domain was available, and pointed me back to checkout. I asked for the domain to be restored, since I had never cancelled it. This time the reply was: “A teammate will take a quick look and give Hostinger Agent the guidance it needs. Adding context below will help them get it right the first time.”

The next day I went through it all again in Hostinger’s chat. Billing showed a paid invoice dated 9 October with two domain-registration line items, including this domain, and the agent was careful to add that “payment alone doesn’t confirm the registry completed the registration.” The lookup now reported the earlier registration as deleted or failed. There was no pending verification and no manual-review flag. And the domain, available the day before, could no longer be registered. The agent could not say who held it. It found no evidence that Hostinger had booked it, and no separate ticket had been created.

Its summary was straightforward: “The records don’t show why the registration failed or who currently holds the domain.”

I am telling this story because it put a question in front of me that I think any team running an AI agent in production should be able to answer. When an action lands on a customer, can anyone say who acted, and on whose authority? This piece is about designing for that question, before the agent acts and after it has.

What the agent could tell me, and what it could not

Read the replies again and there is a pattern. The agent could tell me what it had not done since: twice it said it had not submitted another cancellation or placed a new order. It could not tell me what had happened to my registration, because the records it checked did not say.

It also caught something I had glossed over. I had paid, and the registration still had not gone through. Those are separate facts, and here they disagreed.

None of this shows that Hostinger has no record of what happened, or that nobody there can see it. What I know is narrower: the agent answering me could not establish what had happened, so it could not tell me. From the customer’s side, a record that never reaches the conversation works a lot like no record at all.

That is the problem I want to look at, and it is much bigger than one domain. It comes down to three plain questions:

• Who is acting? A person, a rule, a scheduled job, or an agent, and which one.
• On whose behalf, and with what permissions? Which customer, and what the actor was allowed to do for them.
• Can we reconstruct it? What triggered the action, and what actually happened.

The first two need answers before the action runs. The third needs an answer afterward, from the people who will be asked about it.

Before the action: who is acting, and for whom

Here is an illustrative call. It is not a client story, but anyone who has built a voice agent for a utility or a phone company will recognise the shape. Four things happen on this call that are easy to blur together: confirming who the caller is, knowing who the agent is, deciding what the agent may do for this caller, and recording what it actually did.

A customer calls. The agent texts a one-time code to the phone on file, the caller reads it back, and they are through. Now the agent knows who is calling. It still knows nothing about what this caller is allowed to do, or what they want.

The agent needs an identity of its own as well. In the provider’s systems it should show up as itself, separate from the caller and from “the system”. OWASP’s list of top risks for agent applications warns that without “a distinct, governed identity of its own, an agent operates in an attribution gap”. In practice, that gap is a log that cannot tell the agent apart from the customer it served.

Permissions are where it goes wrong quietly. To look up accounts, the agent’s tool signs in with one integration login that can read every customer. The verified caller says: “While you’re in there, what’s the balance on my mother’s account? I help her with the bills.” The agent can see that account, so it answers. Nothing was hacked. The caller had no right to that account. The agent did, and the caller borrowed its access just by asking. Security people have had a name for this since 1988, when Norm Hardy described a program that “serves two masters and carries some authority from each” and has no way to keep them apart: the confused deputy.

The fix is to stop the agent carrying authority the caller does not have. For this call, it should work with a short-lived pass that carries this caller’s rights, only the ones this task needs, and expires when the call ends. OWASP’s guidance on excessive agency makes the core point: keep the original user’s scope rather than relying only on the permissions of the agent or service calling the tool. Standards help with the plumbing. OAuth token exchange can carry both names, “this agent, acting for this customer”. The MCP authorization rules require a tool server to check that a token was issued for it, and forbid it from passing the caller’s token on to other services, partly because the downstream logs could then show a different identity. A scoped token carries delegated authority. It does not enforce anything by itself: the system receiving it still has to validate it and enforce what it allows. That policy is yours, and it should be written down where a person can review it.

Authorization also has to cover where things go. Shane Mac, the CEO of XMTP Labs, described this in a first-person account in Business Insider on 9 October. He gave a personal finance agent in Grok Bot, xAI’s agent app, read-only access to his checking and savings accounts and told it to send messages only to him. By his account, the first time its monthly report ran, it posted his balances and biggest expenses into his company’s executive Slack channel. He says the Grok team found it had done what he asked but picked a company channel with the same name as his private chat, and that it could reach Slack at all because his agents “feel like different agents” but were “all using the same connections”. xAI’s documentation says as much: “Do not use separate Bots as a security boundary.”

The agent had read-only access to his bank accounts, and what it read still ended up somewhere it should not have. “Send messages only to me” was an instruction to the model, and nothing in his account suggests a permission enforced it. Permission to read information is not permission to disclose it to a particular destination.

Back to the call. The caller now asks to change the bank account that pays the bill. The scoped pass proves the agent may act for this caller on this account. It does not prove the caller meant this particular change. So the agent reads back exactly what will change, the old account and the new one by their last four digits, and gets a clear yes. For something this consequential, a fresh code to the phone on file is a sensible second check. The customer’s yes confirms what the customer wants. It is not independent approval. OWASP also lists requiring a person to approve high-impact actions before they are taken. For the higher-risk changes, I would want that person to be someone other than the one asking, such as a supervisor, which is the case I come back to below. The yes and any approval are recorded with the change, and that record is where accountability starts. How much an agent may do without asking is a setting you choose per task, which I wrote about in autonomy is a dial.

Why injected text raises the stakes

Everything above assumes the agent is trying to do the right thing. Prompt injection takes that assumption away. If text the agent reads, a support ticket, an email, a web page, can steer what it does, then the authority it holds limits what it can be made to do. I have not seen a fix inside the model that holds up against someone who controls what it reads, and I went into why in agent failure modes. The point here is narrower. A deputy that can be talked into things can still do harm inside its pass, but the permissions and enforcement are what you control, and narrow permissions help limit the potential damage.

After the action: what the record has to say

Back to my domain. Something happened to my registration, and nobody has explained it to me. For any consequential action, this is what I would want written down at the moment it happens: who acted, for which customer, under what authority or approval, what triggered it, what was done, and what came of it.

What the record should say about an agent action

Action	Actor	Customer	Authority or approval	Trigger	Outcome
Payment account changed (illustrative)	The voice agent, under its own identity	The verified caller	A pass for this caller and task, plus the caller's recorded yes	The caller's request	Change confirmed back to the caller
The same change, approved by a supervisor (illustrative)	Supervisor decides, agent executes, each named	The verified caller	The supervisor's approval, plus the agent's pass	The caller's request	Change confirmed back to the caller
Records checked, replies sent (my Hostinger case)	Hostinger's AI support agent	Me	Unknown	My messages	Did not submit another cancellation or place a new order, by its own account
Registration refunded and canceled (my Hostinger case)	Unknown	Me	Unknown. Not requested by me	Unknown	Not active, later reported deleted or failed, then unavailable to register

For my registration, most of that row is unknown, to me and to the agent that answered me. That is the practical cost. If the people and agents answering a customer cannot see why something happened, they cannot explain it or confidently put it right, and they end up suggesting what I was told twice: buy it again.

The illustrative rows show what good looks like. When the agent acts with a delegated pass, the record can carry both names, the agent and the customer it acted for, with the customer’s yes beside the change. That only happens if someone designs it in.

So this is the rule I would hold any team to, including my own:

An AI agent should not perform a consequential action unless its authority can be verified before execution and the action can be traced afterward.

“Consequential” is doing real work there, and it does not just mean “can change things”. Mac’s agent had read-only access, and the trouble in his account came from what it could read and where it could send it. So weigh what the agent can see and where its output can go, as well as what it can change. The readiness checklist has a note on scaling the gate to the risk. Audit and incident response get a fuller treatment in the security and governance chapter of Designing Enterprise Agentic AI Systems.

When a human steps in behind the agent

When I asked for the domain to be restored, the reply said a teammate would “give Hostinger Agent the guidance it needs”. I do not know what happened after that, and I will not guess. But the message describes a pattern worth designing for: a person behind the agent, steering it, while the agent keeps doing the work and talking to the customer.

Take the illustrative call again. A supervisor approves the bank-account change and the agent carries it out. Two parties now have a hand in one action. One decided and one executed. If the log names only the agent, the decision disappears. If it names only the supervisor, nobody can see what the agent actually did with the approval. The record has to keep both, with their separate responsibilities.

This is the handoff problem from the other direction. In the handoff piece the question was whether the human receives what the agent knew. Here it is whether the record shows what the human decided.

Still open

As I write this, the domain is not in my account, no person from Hostinger has replied, and I still do not know what cancelled the registration. I will update this piece when that changes. It may well have an ordinary explanation. I would just like to hear it from someone who can see the record.

For your own system, it comes down to one question. Pick one consequential action your AI agent can perform. Can you prove who authorized it, what the agent was permitted to do, what triggered the action, and what actually happened?

If you would like a second pair of eyes on that before an agent ships, that is what my Agentic AI Readiness Review is for. The review includes security and data access as mandatory checks. Details at how I can help.