Today, if someone asks you to prove an AI agent was actually authorized to execute an action, what do you show them?

A log? A trace? The model output? A record showing that the tool call happened? All of those can tell you what happened. They don't necessarily tell you whether the agent was actually allowed to do it. That distinction gets more important as agents move from generating text to acting on real systems: sending payments, changing infrastructure, updating customer records, approving workflows, calling internal APIs. A lot of agent stacks still reduce this to identity and access. The agent has an API key. The API accepts the request. The action runs. But having credentials isn't the same as having permission for a specific action. The harder question is: Was this agent authorized to perform this action, against this target, under this policy, at that point in time? And the answer shouldn't depend on asking the agent after the fact. The authorization needs to exist before execution. It needs to be tied to what is actually being executed. And later, you should be able to verify what authorized the action. That means being able to answer fairly basic questions: who issued the authorization? Which policy was applied? What action was it tied to? Who could use it? When was it valid? Had it already been used? Was authority delegated? This is where the execution boundary becomes interesting. It's one thing for a system somewhere upstream to decide that an action is allowed. It's another to make sure that decision still applies when the action actually reaches the system that will execute it. As agents get access to production systems, "the model decided to do it" isn't going to be much of an audit answer. The question is simpler: Can you prove the agent had the authority to do it?