Skip to content
LAUNCH FILM — LIVEGREENLIGHT · PATENT-PENDINGRUNTIME AUTHORIZATION FOR AI AGENTSMCP CONNECTORS — IN DESIGNISO/IEC 27001 — ROADMAPSOC 2 TYPE II — ROADMAPISO/IEC 42001 — ROADMAPMAS FEAT — DESIGN-ALIGNEDDETERMINISTIC · EXPLAINABLE · TAMPER-EVIDENTAI ACTS · CRELIS DECIDESLAUNCH FILM — LIVEGREENLIGHT · PATENT-PENDINGRUNTIME AUTHORIZATION FOR AI AGENTSMCP CONNECTORS — IN DESIGNISO/IEC 27001 — ROADMAPSOC 2 TYPE II — ROADMAPISO/IEC 42001 — ROADMAPMAS FEAT — DESIGN-ALIGNEDDETERMINISTIC · EXPLAINABLE · TAMPER-EVIDENTAI ACTS · CRELIS DECIDES
All posts
AI Governance 22 August 2026

Identity Is Not Authorization Is Not Evidence: Three Questions Every AI Agent Raises

Who authorized that refund? An AI agent just issued one, and three separate facts decide whether it should have. Who the agent is. Whether it was permitted to issue that refund at that moment. And whether, a month later, you can prove the permission existed. Identity vendors answer the first question well. Some answer the second. The third is the one almost nobody sells, and it is the one an auditor, a regulator, or a disputing counterparty actually asks for. This piece separates the three, because conflating them is how teams discover — too late — that they can authenticate an agent, authorize it, and still have nothing to show for it.

Authentication vs authorization for AI agents

Authentication is who the agent is. Authorization is what the agent may do. For AI agents the distinction is the same one it has always been for people, and the Microsoft identity platform states it plainly: authentication is "the process of proving that you are who you say you are," while authorization is "the act of granting an authenticated party permission to do something." An agent can be perfectly authenticated and still be wrong to act. Authentication answers identity. Authorization answers permission. They run on different logic, and treating a verified identity as if it were a granted permission is the first and most common mistake in agent governance.

Consider the refund again. The agent signs in with its own identity, so authentication is satisfied. Whether it may refund this customer, for this amount, given this account's history, is a separate decision that the identity alone does not settle. Confusing the two produces a predictable failure: a well-identified agent doing something it was never meant to do, with every monitor reporting green because the credential checked out. The credential was never the question.

AI agent identity vs access

Give an agent an identity and you can tell it apart from every other agent, hold it to a policy, and revoke it. That is the layer the largest vendors are racing to build, and they frame it explicitly as identity. Microsoft describes its offering as an identity system: Entra Agent ID is "an identity and security framework that extends Microsoft Entra capabilities to AI agents." Okta approaches the same problem from the connection side; it describes Cross App Access as "an OAuth extension that makes it easier to support secure, controlled integrations at scale." Both are real, useful work. Both answer who the agent is and what it may connect to. Neither, on its own, produces the record you need when someone later asks who authorized one specific action.

Non-human identity vs authorization

"Non-human identity" is the category name for the machines, service accounts, and now agents that hold their own credentials. Vendors here frame the work as identity security. Astrix Security describes its product as a way to "Discover, secure and manage AI agents & NHIs." Discovering and inventorying those identities is essential, and it is also not the same as authorization. An identity can be discovered, current, and fully governed while the separate question — was this identity permitted to take this action, right now — stays open.

Some vendors do reach toward that question. Aembit, which positions itself as an identity broker for agentic AI, describes its job as applying "policy, context, and audit to all agent interactions based on their unique identities." That includes audit, which is a genuine step in the right direction. But applying audit to access is not the same as holding a verifiable record of who authorized a particular action — a record whose integrity you can demonstrate to an outsider who was not there.

What is agent authorization?

Agent authorization is the runtime decision: may this agent take this specific action, under these conditions, at this instant. It is distinct from identity because the answer changes with context even when the identity does not. The same agent that may read a report at 2pm may not be allowed to wire funds at 2:01. Some vendors build precisely here, and build well. Britive positions itself around "Continuous authorization and runtime enforcement for AI agents, NHIs, and humans." That is the authorization half taken seriously: a live decision, enforced in the moment, rather than a static role handed out once and forgotten. Crelis operates in the same category — runtime authorization and governance for AI agents — and treats the decision as the floor, not the ceiling. Making the decision well is necessary. But a decision that is made and enforced can still leave you unable to prove, afterward, that it was ever made.

Enforcement answers the question in the present tense. It does not, by itself, preserve the answer. The moment of decision passes, the action completes, and what remains is whatever the system happened to write down — often a scatter of events across several tools, in formats designed for debugging rather than accounting. That is usually enough to operate a service. It is rarely enough to defend one. If you want to see how much rides on a single one of these decisions, we take one apart in who authorizes an MCP tool call.

What this means if you have to produce evidence

Now separate the third question from the first two. Identity tells you who acted. Authorization tells you the action was permitted when it happened. Evidence tells you that you can still show both — completely, in order, and without gaps — weeks or years later, to someone who was not in the room and has no reason to trust your dashboard.

This is the question almost no one in the identity or authorization market sells against, and it is the one that decides outcomes when they are contested. An auditor does not accept "the system allowed it." A reviewer asks to see the record of who authorized what, and to be confident the record was not edited afterward to fit the story. A tamper-evident record is one that cannot be altered after the fact without the alteration showing. That property is what turns a log into evidence, and it is a different property from access control.

Picture the dispute directly. A payment the agent authorized is challenged sixty days later. The customer says they never approved it; the agent's owner says the policy allowed it. Resolving that turns entirely on the record: can you point to the exact authorization, show the conditions it was granted under, and satisfy a skeptical outsider that the record itself was not touched between then and now. If your logs can be quietly rewritten, they prove nothing at the one moment they are questioned — which is precisely the moment they exist for.

The difference is not academic, and it is not solved by keeping more logs. Volume is not integrity. A larger pile of the same rewritable records is a larger pile of the same problem. What changes the picture is a record whose past cannot be revised without the revision being visible — so that "here is what happened" and "here is proof it has not been edited" become the same artifact, rather than two separate claims you ask people to take on faith.

You can test any agent stack against this today, without buying anything. Ask three questions of it. One: for a specific action an agent took last month, can you name the exact authorization that permitted it. Two: can you produce that record on demand, as a coherent account rather than scattered log lines assembled by hand. Three: if someone had changed that record, would you be able to tell. If the answer to the third is no, you have logging, not evidence — and the gap does not surface until the day someone disputes what happened. The distinction between securing an agent and being able to account for it is the same one we draw in AI agent security vs AI governance.

Crelis was built for the third question. It records who authorized what, at the moment of the decision, in a form designed so that any later change to the record is detectable. The identity and authorization layers stay where they are; the evidence sits alongside them and outlives them. Crelis is patent-pending on this approach, and you can see the shape of it in GREENLIGHT. The point of this piece is not the product. It is the distinction: authenticate the agent, authorize the action, and keep evidence you can stand behind — three jobs, not one, and the third is the one that is missing when it matters.

Related reading

Want the full story?

Explore GREENLIGHT