Runtime Authority
AI reasons. Your organization authorizes, through the governance it already runs. Runtime Authority determines whether that authorization holds at the moment an agent tries to act, before anything executes.
AI agents are moving from generating information, to taking actions, to becoming part of the workforce
An agent that drafts an email carries limited downside if it's wrong. An agent that initiates a payment, submits a procurement order, modifies a contract, updates an ERP record, changes infrastructure configuration, or makes a healthcare-adjacent recommendation carries the same consequences a human employee acting outside their authority would carry, except it can act at machine speed, at machine scale, and without the institutional friction that normally slows a person down long enough for someone to notice.
Enterprises already have governance structures built for exactly this problem: Delegation of Authority, approval limits, separation of duties, role hierarchies, accountability models. None of them were written with a machine actor in mind, and none of them are currently enforced at the moment an AI agent decides to act.
As AI moves from a tool a person operates to an actor with standing to act on the organization's behalf, the question stops being an AI question and becomes an organizational one: how does the organization preserve the authority it already has, now that part of its workforce isn't human?
Two valid permissions can still add up to an unauthorized action
An autonomous procurement agent holds valid permission to change a supplier's banking details in one system, and valid permission to initiate a payment in another. Each request, evaluated on its own, is fine: the identity is legitimate, the role permits the action, nothing technical is violated in either system. Neither system knows what the other one just did.
Runtime Authority evaluates both intents against the same Authority Graph and the same principal, so it can see what a single system can't: the same actor changed the banking details and then, within 24 hours, initiated a payment that benefits from the change. If the organization's policy treats that sequence as requiring independent human approval, the second intent resolves to Human Review, not Allow, even though the underlying permission was valid. This is illustrative, not a claim that every organization runs this exact rule; the shape of the gap, an actor, a sequence, two systems, and time, is what a single local permission check can't see on its own.
A policy that isn't evaluated at the moment of action is just a document
Logging, monitoring, and after-the-fact review tell you what an agent did; they do not tell you, before it happens, whether it was allowed to. Runtime authorization moves the check earlier: the agent's intent is evaluated against the organization's actual authority structure before execution, and a decision, Allow, Deny, or Human Review, is returned in time for an enterprise to act on it. This is the same principle every mature access-control system already applies to people and services, extended to autonomous agents, at the speed they operate.
Every intent passes through the same deterministic path
An agent submits a cryptographically signed intent, on its own, or, for higher-assurance use cases, corroborated by a customer-controlled Trusted Adapter. Either way, Runtime Authority evaluates it against the active Runtime Policies compiled from your governance documents, encoding who this agent is acting on behalf of and what that principal is entitled to delegate. Those policies are published from a reviewed and approved Authority Graph version, and they stay grounded in the exact delegation relationship they were compiled from: evaluation checks that relationship is still active before the policy can grant that authority, so revoking or expiring the underlying delegation stops the policy from granting it. Evaluation itself is deterministic: no model makes a judgment call at this stage. For the exact request and response shape, see Runtime API in the Developers section.
Three outcomes. No fourth path.
Allow
The intent falls within delegated authority, approval limits, and active policy. No further human sign-off is required for this specific action.
Deny
The intent falls outside authority or violates a constraint. The decision is Deny, returned before execution, not flagged after the fact.
Human Review
The intent is inside a defined escalation boundary. A named accountable reviewer resolves it; the resolution is itself recorded.
From decision to controlled execution
For an Allow, or for a Human Review a reviewer has since approved, an action that needs stronger execution control can be issued a Capability Authorization: a short-lived, single-use authorization bound to the exact agent, action, resource, environment, and Runtime Connection the request was actually evaluated under. An external, customer-operated enforcement point verifies and consumes it before deciding whether to let the downstream operation proceed. It's optional, used where a use case is configured to require it, not issued for every decision automatically.
Single use
Once consumed, the same authorization cannot be replayed.
One per decision
A second authorization cannot be minted from the same decision lifecycle.
Scope bound
The wrong action, resource, environment, or organization is rejected.
Revocation aware
Relevant live organizational state is checked immediately before consumption; there's a narrow window this doesn't close, disclosed on the Security page.
What changes for the organization operating it
Deterministic, fail-closed
The same intent, evaluated against the same policy, produces the same decision. When evaluation cannot complete, the default is deny, not allow.
Your governance, not a new one
Delegation of Authority, approval matrices, and role hierarchies you already operate become the evaluated policy. Where AI helps extract that structure from your documents, it can only propose candidates: a human reviewer resolves and approves the exact version, and nothing is compiled or activated without that approval.
Before execution, not after
Evaluation happens at the moment the agent forms an intent, ahead of any real-world effect, not as a downstream audit of what already happened.
Every decision is evidence
Allow, Deny, and Human Review all produce a signed record. Every intent submitted to Runtime Authority resolves to exactly one of these outcomes, and every outcome is recorded: nothing evaluated here leaves without evidence.
See Runtime Authority evaluate a real intent
Bring an existing approval policy. We'll show you the decision, in real time, before anything executes.