What is runtime authorization?

In plain English

Static authorization is what most apps already have. A user signs in, the system loads their role, and from then on the role decides what they can do. The check happens once, often before the request arrives. That model breaks when the actor is an AI agent that can chain hundreds of actions per minute on behalf of many users, sometimes acting on instructions that did not come from any of them.

Runtime authorization treats each governed action as its own decision. Same agent, different arguments, different answer. An agent calling refund(order_id, amount) with a $50 amount and a $50,000 amount triggers the same code path but two different decisions. The authorization engine sees the arguments, checks them against policy, and returns allow, deny, or route to a human approver.

How it works

The pattern follows the policy decision point and policy enforcement point split familiar from XACML. The enforcement point sits on the tool path. It pauses the action, sends the request to the decision point, and waits for the verdict. The decision point evaluates a set of declarative rules against the request and returns one of three outcomes: allow, block, or require_approval.

With Veto, the rules live in YAML in your repo. They reference the tool name, the arguments, the agent identity, and anything in the request context. The SDK runs the decision in-process, returns locally before execution, and logs the verdict with the decision context.

# YAML policy: runtime authorization for refunds
- name: refunds_must_be_small_or_approved
  match:
    tool: refund_order
  rules:
    - if: args.amount_cents > 50000
      then: require_approval
    - if: args.amount_cents <= 50000
      then: allow

Operational consequence

The public failure pattern is specific: an agent with a valid session runs a destructive operation during a freeze, then the team has to reconstruct what happened from logs. Authentication was fine. What was missing was a check that asked: should this specific action, with these arguments, against this environment, be allowed right now? A runtime authorization policy that blocks destructive operations on production tables during freeze windows stops the call before it runs.

The same pattern shows up in compliance. The EU AI Act requires human oversight for high-risk systems. SOC 2 reviewers expect access-control and activity-review evidence. HIPAA requires ePHI access controls. None of them say "runtime authorization" by name, but they often require the kind of contextual, logged, human-overridable decision that runtime authorization provides.

Related terms

FAQ