Every agent identity pitch sounds complete until you ask it one question. Once the agent proves who it is, what stops it from doing the wrong thing. Most of the market has a confident answer for the first half and a shrug for the second. That split, authentication against authorization, is the most important distinction in agent security right now, and it is the one teams collapse the fastest.
Authentication is who. Authorization is what.
Authentication is an agent proving its identity. A certificate, a signed token, a registration record, something that says this request really came from the invoicing agent and not an impostor. Authorization is the decision that comes after: what is this proven identity allowed to do right now, on whose behalf, and for how long.
Here is the part that gets lost. An agent authenticates once and then makes a thousand calls. The authentication event happened at call zero. Every call after that is an authorization question, and most stacks never ask it again. They check the badge at the door and then let the holder roam the building for the rest of the day.
The market sells you authentication and calls it done
Identity vendors are genuinely good at issuing agents identities. Okta, Entra, and a wave of agent-identity startups will give every agent a distinct, verifiable name, often backed by a certificate. That work is necessary and I am not knocking it.
But a valid identity says nothing about scope, purpose, or duration. An agent can hold a pristine credential and still drain a system, because the credential was broad and nobody decided what it was actually for. Issuing the identity is the start of the job. The market keeps shipping the start and presenting it as the finish.
ASI03 is an authorization problem wearing an identity label
OWASP's ASI03, Identity and Privilege Abuse, is the identity risk in the Top 10 for Agentic Applications. Read its failure modes and they are all authorization failures in disguise:
- Cached credentials reused across sessions. The token was valid. Nothing scoped it to a single task or expired it fast enough.
- A privileged agent handing full credentials to a lower-privileged one. Both authenticated cleanly. The delegation carried far more authority than the handoff needed.
- A borrowed user session acting three hops from the request. The session was real. No layer checked whether this action, for this user, was still in bounds.
In every case the agent was who it claimed to be. The breakdown was in what it was allowed to do.
The valet key test
A valet key starts the car and opens the door. It will not open the glovebox or the boot, and it stops working when you take it back. The attendant is authenticated, clearly the person driving your car into the garage. Their authority is scoped to exactly that task.
Authentication is the attendant being who they say. Authorization is the key turning the ignition and nothing else. Agents today mostly get handed the house key, which opens everything, and then we act surprised when one of them wanders into a room it had no reason to enter.
How to tell which problem you have actually solved
Run this on any agent in your stack:
- Can it prove who it is? If yes, you have authentication.
- Is its access scoped to a user, a set of endpoints, and a time window? If no, you have not solved authorization.
- Can a high-impact action be held for a human? If no, your authorization is partial at best.
- Can you revoke it in seconds and replay every action it took? If no, you have identity without control.
Most teams answer yes to the first and no to the rest. That is an authentication win sitting on top of an authorization gap, and ASI03 is exactly the shape of that gap.
What to do instead
- Treat identity as the foundation, not the finish. Issue every agent its own identity, then build the decision layer on top of it.
- Scope at the authorization layer. Bind each credential to one user, a set of endpoints, and a tight window. Keyless and short-lived, so there is no standing secret to replay.
- Decide per user. The question is what this agent may do on behalf of this specific person, which a blanket per-agent grant cannot answer.
- Gate the expensive actions. Sending mail, moving money, deleting records. A human approval on those beats trusting the prompt held.
- Keep a trail you can hand an auditor. Agent, user, action, target. If you cannot reconstruct who did what, you have logging, not authorization.
This is the work an authorization layer does, and it is the half AgentValet was built for. It issues scoped, short-lived, keyless credentials per agent, runs a per-user policy engine that decides what each agent can do for each person, holds high-impact actions for a push approval confirmed with a biometric, and writes every call to an audit trail. The one-line version: Okta handles authentication, AgentValet handles authorisation.
Solve the half that decides your blast radius
Authentication was always going to get solved. There is a market for it, there are standards for it, and the identity vendors are good at it. Authorization is the half that decides what a compromised or confused agent can actually reach, and it is the half you have to enforce on every call, not once at the door. If your agent can prove who it is and still do anything, you have answered the easy question and left the dangerous one open.