What is Runtime Authority Control?
Runtime Authority Control is a runtime authorization layer for machine-initiated actions. It evaluates whether an action is authorized before it executes, and returns one verdict: allow, constrain, or block. The decision is made in the execution path, so a denied action never runs.
Runtime authorization is the category. It governs what AI systems, agents, and automation are permitted to do at the moment they attempt an action, under the policy in force and the context that exists at that moment.
Runtime authorization is distinct from governance of the model, the data, and the record.
The confusion that surrounds the category is the confusion worth clearing first. Runtime authorization is not model governance, not data governance, and not monitoring. Each governs a different thing, at a different time, and produces a different output.
Model governance governs how a model reasons and what it generates. Runtime authorization governs what the system is permitted to do once it acts on that output.
Data governance governs how data is classified, stored, and accessed. Runtime authorization governs the action a system takes, not the record the action reads or writes.
Monitoring reports on what already happened. Runtime authorization decides before it happens. Seeing an action is not the same as governing it.
Identity and access management establishes who has access. Runtime authorization decides whether that access should be exercised for this action, right now.
Three planes of governance.
Information governance governs the record. Model governance governs the reasoning. Runtime authorization governs the doing. The three are complementary. A system can evaluate risk and still execute. Evaluation is necessary, but evaluation is not enforcement. Runtime authorization is the point at which the verdict is enforced in the path, before the action takes effect.
Governs the record. How data is classified, retained, and accessed.
Governs the reasoning. How a model is trained, evaluated, and constrained in what it generates.
Governs the doing. Whether a machine-initiated action is permitted to execute, decided before it runs.
Runtime authorization against adjacent disciplines.
| Approach | What it governs | When it acts | What it produces |
|---|---|---|---|
| Runtime authorization | What a system is permitted to do | Before the action executes | A verdict: allow, constrain, or block, with an immutable record |
| Model governance | How a model reasons and what it generates | During training and inference | Model cards, evaluations, output controls |
| Data governance | How data is classified, stored, and accessed | At rest and in transit | Access policy, lineage, retention records |
| Monitoring and observability | What already happened | After the action executes | Logs, alerts, dashboards, post-hoc reports |
Terms, defined.
- Machine-initiated action
- A machine-initiated action is an action started by software rather than a person. An AI agent calling an API, an automation moving funds, a workflow modifying a record, and one system delegating a task to another are all machine-initiated actions. The initiating party is a system, and the action can carry consequences with no human in the loop.
- Consequential action
- A consequential action is a machine-initiated action that changes state outside the system that initiated it. Moving money, writing to a system of record, provisioning access, granting credentials, and sending an external message are consequential actions. Reading data for internal reasoning is not. Runtime authorization concentrates on consequential actions because they are the ones that cannot be taken back.
- CORTHEM
- CORTHEM is governance verification infrastructure. It preserves decision-linked evidence and produces proof that machine-initiated action remained within policy over time, for regulators and auditors. CORTHEM is additive to runtime authority control, not a dependency. CORTHEM is a trademark of Hartstone Institute LLC and is the subject of pending patent applications.
FAQ
What is runtime authorization?
Runtime authorization is the evaluation and authorization of a machine-initiated action before it executes. It decides whether a specific action, under the policy in force and the context that exists at that moment, is permitted to proceed, and returns one of three verdicts: allow, constrain, or block.
How is runtime authorization different from AI monitoring?
Monitoring reports on actions after they execute. Runtime authorization decides before they execute. Monitoring produces logs and alerts about what already happened. Runtime authorization produces a verdict that determines whether the action happens at all.
What is a machine-initiated action?
A machine-initiated action is an action started by software rather than a person. An AI agent calling an API, an automation moving funds, and a workflow modifying a record are machine-initiated actions. The action can carry real consequences with no human in the loop.
Does an AI agent need authorization before calling an API?
If the call changes state outside the agent, it is a consequential action, and runtime authorization evaluates it before it runs. Valid credentials establish who the agent is. They do not establish whether this specific call, against this target, under current policy, should be permitted right now.
What is pre-execution authorization?
Pre-execution authorization resolves in the execution path, before an action takes effect. A denied action never runs and produces no downstream change. This is the distinction from detection, which can only report on an action that has already executed.
Who authorizes an automated action?
A runtime authorization layer authorizes the action against the policy in force, and records the named authority under which the verdict was issued. Every outcome traces to a named authorizing party rather than an assumed permission.
Is runtime authorization the same as identity and access management?
No. Identity and access management establishes who has access. Runtime authorization decides whether a specific machine-initiated action should execute right now, in context, against the actual target, under the policy that is actually in force. The two are complementary.
What is the difference between Runtime Authority Control and Runtime Authority Fabric?
Runtime Authority Control decides a single machine-initiated action: allow, constrain, or block. Runtime Authority Fabric governs authority across a chain of agents, where one system delegates to another, covering delegation, coordination, and reversal across multiple machine actors.
These terms were defined in the Runtime Authority Series by Emily Hartstone, published by Hartstone Institute LLC, beginning with Before It Acts in June 2026. The governing principles appear in A Bill of Runtime Rights at runtimerights.org, archived on Zenodo under DOI 10.5281/zenodo.22849622.
Runtime Authority Control, RAC, Runtime Authority Fabric, CORTHEM, and UNANIMOS are trademarks of Hartstone Institute LLC, and the technologies they describe are the subject of pending patent applications.