Authority Is Not Transitive

There is a structural mistake in how many teams reason about authority in autonomous AI systems, and it keeps getting repeated. The mistake is to assume that authority granted to start a process travels intact through every action the system takes to complete that process. It does not, and the cleanest way to see why is to walk through what “process this insurance claim” actually entails when an autonomous system is the one doing the processing.

Take the instruction at face value. The wording is short. The action set is not. A system asked to process the claim will, in practice, read the customer’s record (almost certainly more of it than the claim strictly requires), select and call one or more external services (the obvious one is a fraud-assessment service), decide what subset of the customer’s data to transmit to those services, and apply whatever score returns to the payout decision. None of those operations is named in the instruction. All of them touch real systems and produce real consequences.

The question I want to ask, and the one many architectures cannot answer, is: who authorised the transmission of medical records to a third party?

The answer is that no one did, in any specific sense. The caller said “process this claim” and the system filled in the rest. The caller authorised an outcome. The system chose the actions.

Teams Assume Initiation Covers Execution

The reasoning that papers over this gap, when I have heard it laid out, looks something like the following. A human configured the workflow, a human triggered the process and a human approved the task; therefore, the line of argument goes, everything the system does in service of that task is covered by the human’s authority. The reasoning is intuitive. It also collapses two different kinds of authority into one, and the conflation has consequences.

Initiation And Action Are Different Authority Claims

There are two distinct things being labelled “authority” here, and they answer different questions.

The authority to initiate is the authority to say “process this claim” or “sync this data” or “handle this request.” It is a statement of intent and names a desired outcome.

The authority to act is the authority to take a specific operation against a specific target — read this record, call this API, transmit this set of fields to this external recipient, in this order, at this moment. It is a series of concrete operations with real consequences, each touching a real system and most of which may cross a boundary between internal and external, between sensitive and public, between what was intended and what was not.

These concrete operations are not listed in the instruction. They are determined by the system at runtime, and in many cases the caller could not enumerate them in advance even if asked, because part of the value of these systems is that they decide the “how” themselves.

The Transformation Nobody Specified

What I want to name explicitly is the transformation that sits between the instruction and the execution, the one that converts a goal into a sequence of operations. If that transformation were fully specified up front, autonomous AI would not be the right tool for the job — a script would do it. The whole reason these systems are valuable is that they determine how to achieve a goal: they interpret, adapt and choose.

The moment a system chooses how to act, though, it is no longer simply relaying the caller’s authority. It is deciding how that authority gets applied. The choices about what to read, what to call, what to send and to whom are themselves authority decisions; they shape what the system does in the caller’s name. None of that is explicitly authorised by anyone. It is resolved at runtime, by the system, against whatever heuristics the model happens to produce.

Nothing in the system, in many production architectures, evaluates whether the transformation itself produces only authorised actions.

The Instruction Expands Into Consequences

Walk through the same instruction concretely. The system reads the customer’s full record — not just the claim itself but contact details, prior claims and medical notes — without anyone having specified which fields it was allowed to touch. It selects an external fraud-assessment service from among the ones configured for this kind of claim, again without anyone having named the service in the original instruction. It transmits a subset of the customer’s medical data to that assessor in order to obtain a risk score. And when the score returns, it applies whatever payout-reduction logic is in its configuration to produce the final decision on the claim. Each of those operations is technically permitted by the infrastructure: the system has the API keys, the database credentials, the network access. That is capability, not authority.

What was authorised was “process this claim.” What got executed included “send this particular patient’s medical history to this specific third-party service at this specific moment.” The system filled in the gap between the two, and nothing in the standard architecture asked whether the gap-filling was within the caller’s authority.

Authority Does Not Travel From Intent To Action

Authority is not transitive. It does not propagate unchanged from intent to execution. At each step from instruction to action, intent is interpreted and concrete operations are selected, and each interpretation introduces a place where what was authorised can diverge from what is actually being executed. This is not an edge case or an artefact of a particular framework; it is the structural shape of any system that determines its own actions in service of an instruction.

Why Identity Does Not Solve This

The temptation when the gap becomes visible is to reach for identity and access management — surely a well-configured IAM system answers the question. It does not. IAM answers a single question: who is allowed to start this process? It does not answer the question that matters here, which is whether this specific action, chosen at runtime by the system rather than specified by the caller, is within the scope of what was actually authorised.

The first question governs initiation. The second governs consequence. Many production systems govern only the first, which is why those systems can have, at the same time, perfectly auditable workflow approvals and entirely ungoverned per-action behaviour. The system has a key that opens every door it might need. What it does not have is anything checking whether it should walk through this particular door, right now, for this particular reason.

Autonomy Creates The Gap

This shape of problem did not exist in traditional software. A user clicked a button, code executed a fixed sequence, and the user’s authority covered the outcome because the outcome was fully determined by the input. There was no gap between intent and action because the actions were enumerated up front. Autonomous AI systems break that arrangement. The system receives an intent and produces a sequence of actions that were not predefined, drawing on context, state, retrieved data and, when language models are part of the loop, probabilistic reasoning. The gap between authorised intent and executed action is the nature of autonomy. It is also exactly why these systems require governance at a point that traditional software rarely needed it: at every individual action, at the moment of execution.

Control Has To Sit At The Action Boundary

If a system cannot, at the moment each action is about to produce a consequence, evaluate whether that action is authorised, then the system is being trusted to keep the caller’s intent and its own chosen actions aligned. In autonomous AI systems, that alignment is exactly what cannot be assumed, and it is exactly where governance has to operate.