Topics

What is runtime authorization?

Runtime authorization is the evaluation of an action at the moment it is attempted, using the context available only at that moment, rather than relying on permissions granted in advance. For AI agents, it is the difference between deciding once, at deployment, what an agent may do and deciding every time the agent is about to do something whether this instance of it is allowed.

Design time versus runtime

Most authorization in the enterprise is decided at design time. A role is defined, entitlements are attached, the identity is placed in the role, and from then on requests are checked against a grant that was fixed before the request existed. This works when the caller's behavior is predictable and the meaning of an action does not depend on what came before it.

Agents violate both assumptions. Their behavior is chosen, not scripted. And the meaning of an action depends heavily on history: the first refund of the day and the fortieth are the same API call with very different significance.

Runtime authorization moves the decision to the point of action and lets it use what is only knowable then: the parameters of this action, the cumulative state of the run, the current delegation chain, and any conditions that have changed since deployment.

What runtime context makes possible

Cumulative ceilings. A daily refund total, a monthly procurement budget, a cap on the number of records an agent may export in one session. These can only be enforced by a check that knows what has already happened.

Conditional constraints. No refunds on accounts currently flagged for review. No changes to a configuration currently under an active incident. The condition is evaluated against live state.

Delegation-aware decisions. An agent acting on its own behalf and the same agent acting as the fourth hop in a chain started by a human may hold different effective authority. Only a runtime check can see the chain as it exists at that moment.

Graduated outcomes. Instead of allow or deny, a runtime check can constrain: proceed, but with the amount reduced to the remaining ceiling, or with the scope narrowed. It can also escalate to a named human and wait.

The shadow mode step

A practical property of runtime authorization is that it can run without enforcing. Every action is evaluated and the outcome that would have applied is recorded, but nothing is blocked. This is how a new surface is brought under governance: observe what the authority model would have done, tune it against reality, then switch to enforcement. Our position is that this step is where most of the early value lives, because it shows the gap between what agents are doing and what anyone thought they were authorized to do.

Where the check has to sit

For runtime authorization to be a control rather than a report, it has to sit between the agent's decision and its effect. Six placements work in practice.

An in-process API the agent or its framework calls before a consequential action. An inline gateway that terminates the agent's outbound connection and evaluates the action, not just the destination. A required check at the API tier or a reverse proxy in front of an application that cannot be integrated. A sidecar or service mesh policy so the agent has no path to enterprise systems except through the check. A tool broker or MCP gateway that evaluates every tool call. And the event-only mode described above.

The placements differ in how much they know about the action. An in-process call sees intent. A proxy sees the request. Where deeper integration is possible, prefer it. The proxy and broker patterns exist so that nothing falls outside governance because its caller could not be instrumented.

Where BotAris fits

BotAris performs runtime authorization for AI agents through the Decision Authority Enforcement Point, deployed in any of the placements above. Every placement evaluates against the same Authority Model and writes to the same Accountability Ledger, so a decision is governed the same way whether it arrived through an API call or a proxy.

Frequently asked questions

Does runtime authorization add latency to agent actions?

It adds a check in the path of consequential actions. The design question is which actions count as consequential. Reading a record generally does not need a check. Moving money, changing configuration, or committing the organization does, and the cost of a check there is small relative to the cost of the action being wrong.

How is runtime authorization different from monitoring?

Monitoring observes and alerts after the fact. Runtime authorization sits before the action and can constrain, escalate, or stop it. Event-only mode is monitoring; enforcement mode is control.

Can runtime authorization work for agents on a SaaS platform I do not control?

Yes, through the placements that do not require agent integration: an inline gateway, an API tier check, or a proxy in front of the system the agent is acting on. Coverage follows the surfaces you put enforcement in front of.

Keep up to date on Authority Governance

Long-form writing on defining, enforcing, and proving what AI agents are allowed to decide. No product pitches.

Confirm by email. Unsubscribe anytime.

Humans define authority. BotAris enforces it.

BotAris is onboarding a limited group of enterprise design partners. Design partners shape the product roadmap and receive early access. If you are putting agents into workflows with real consequences, we want to talk.

Related topics