Ask. Act. Prove.

Security has always loved a triple.

The oldest one still runs the world: authentication, authorization, accounting — AAA, the framework underneath every network login since the dial-up era. Identity has its own catechism, taught in every vendor deck for twenty years: Who are you? Can you prove it? What can you do?

Look at the grammar of those questions. Every one of them interrogates the actor. And every one of them is answered at the door — once, at authentication time, when a session begins. The actor presents credentials, the system renders a verdict about the actor, and everything that happens afterward inherits that verdict.

That model held for thirty years because the actor behind the session was a person, and a person carries their own judgment through the door. The session did roughly what the human intended, the human roughly knew their job, and when something went wrong, the audit log could at least say whose hands were on the keyboard.

Agents broke the door

An AI agent walks through the same door and everything the door verified starts going stale immediately.

The agent is fully credentialed — its identity is real, its token is valid, its connection is authorized. And none of that says anything about the act it is taking right now. An agent can hold zero standing entitlements and still reach hundreds of operations through delegated authority; it can pass every check the door knows how to run and still take an action nobody was ever entitled to delegate to it. Between the moment the door said yes and the moment the agent acts, the persona it operates under, the scope it was granted, and the authority behind the grant can all have changed.

The industry has noticed, and the response has been to move the door closer to the action: token lifetimes shrink, gateways broker short-lived credentials, connections get re-evaluated in real time. All of it is real progress — and all of it is still the same grammar. It interrogates the actor and the connection, faster and more often. The act remains un-asked.

We think the agentic era needs a different triple. One that interrogates the operation, not the operator.

Ask. Act. Prove.

Ask. Before the act, authorization is a question with a computed answer — not a policy lookup, not a scope check, but a question posed against the organization’s own delegation model: is this actor, under this persona, at this position in the organization, eligible to attempt this operation? We have written before about what it means to make that a product action — a question any operator, human or AI, can ask in plain language and get an evidenced answer. The answer is honest about its own boundary: it establishes eligibility to attempt, not a promise that every rule inside the operation will pass. An ask that overpromises is a vulnerability wearing a feature’s clothes.

Act. The governed operation re-evaluates authority independently, at execution, from actual resolved state. This is the part that keeps the triple honest: the ask is never a bearer token. It reserves nothing, bypasses nothing, and grants nothing. A system that weakens its runtime checks because a preflight question was answered has converted a question into a credential — and credentials are exactly the thing that go stale between the door and the act.

Prove. The act leaves evidence, and the evidence is opinionated. Not a log line that says something happened — a decision record that says what was decided: granted or denied, which factors were evaluated, which targets were actually resolved, and under whose delegated authority the act was taken. Other platforms log actions; the point is to log reasoning. And the contract cuts both ways: denials leave receipts too. In a world of runtime gateways, a denial is a closed connection — a non-event. In a governed system, a denial is evidence: here is the act that was attempted, and here is the specific reason it was not within delegated authority.

The payoff is drift

Here is what the triple buys that no amount of faster actor-checking can: the proof binds back to the ask.

Because the answer to the ask is computed from a defined authority boundary — this actor, this persona, this node, this operation — the evidence from the act can carry that same boundary and show whether it moved. The question every audit ultimately wants answered is not was the agent authenticated or even was the action permitted. It is: was the authority that answered the question still the authority that governed the act? That is a comparison, not an investigation. It is what certification campaigns approximate on a quarterly cadence, computed at the cadence that actually matters — per operation.

Why this needs an authority model

You cannot bolt this triple onto a policy engine, and the reason is the third word.

To ask, there has to be somewhere the authority lives — a model of the organization in which an actor holds a persona at a node, with delegated grants that have provenance. To prove, the evidence has to carry lineage: not just the rule permitted it, but who held the authority that made the rule permissible, and through what chain it was conferred. A policy engine can cite the policy that allowed an act. It cannot cite who was entitled to write the policy — nobody in the delegation-chain world computes that root. Lineage is not a field you add to a log schema. It is a property of having an authority model underneath the decision, and it is the reason the proof can mean something to an auditor, a regulator, or the next system downstream that has to decide whether to trust the act.

The industry’s triples are not wrong. Authentication still matters. The door still matters. Who are you? still matters.

It is just no longer the last question.

Ask before the act. Enforce during it. Prove it after — with lineage. Three words, one operation at a time.

IdentityRM is the authority governance platform built on a governed delegation model — what Authority Governance actually is, how an agent knows what it can do, or see the platform. Built on US Patent 12,549,558.