Enterprises have learned to control what autonomous agents are allowed to do. They have not yet decided who designs those limits in the first place.
Introduction
The sharpest piece written on agentic AI in the past year is not a research paper. It is Bob Slocum's IBM Think article, "The accountability gap in autonomous AI: How governance turns risk into an advantage" (IBM, 4 February 2026). It is worth naming who is making the argument. IBM has operated the identity and access layer of large enterprises for decades; it is, in effect, an incumbent authority on who is allowed to touch what. When that incumbent argues that Identity alone can no longer hold, the claim carries weight the usual governance commentary does not. When the company that has spent decades defining enterprise identity says identity is no longer enough, the industry should pay attention.
Slocum's contribution is to move the conversation past the reflex that "agents need access controls too." As Enterprise AI shifts from assistive tools to Autonomous AI that acts on the organization's behalf, his article shows precisely where traditional Identity and Access Management breaks when the actor is an autonomous agent rather than a person, and it follows that break all the way to its accountability consequences. Read it closely and you will agree with almost everything in it. You will also be left with a question the article never states—and its silence on that question is exactly what reveals how far it has traveled.
What IBM Changed
The article builds its case as a sequence, each layer resting on the one before it.
Identity. Legacy IAM assumes a stable subject: a human, or a long-lived service account. Agents violate that assumption. They can be spun up for a single workflow—sometimes a single transaction—and dissolved on completion. Identity stops being a durable account and becomes ephemeral, which is why the article insists every agent carry a first-class, verifiable identity of its own.
Authorization. Authentication that unlocks a session and then steps back is too coarse for actors that make thousands of decisions an hour. Slocum's model scopes every permission, binds it to time, and keeps it revocable, so that Authorization becomes a first-class object that can be proven after the fact rather than assumed at login.
Runtime Governance. Policy that lives in a document does nothing at the moment an agent calls an API, reads a record, or changes a configuration. Enforcement has to sit at the point of action. The article notes that auditors have already shifted their expectation from static lifecycle reviews to runtime process evaluation.
Auditability and Accountability. When something goes wrong, the enterprise must be able to reconstruct what happened, why, and under whose authority—an end-to-end trail that links human and machine across the entire transaction.
Stacked together, these produce the article's central move: from access control to Authority Control. IAM stops being the lock on the front door and becomes a discipline of validating authority continuously, action by action. This is a real advance, and it deserves to be recognized as one. IBM took the limits of Identity and Access Management and pushed them onto genuinely new ground.
The Remaining Question
Authority Control governs authority that already exists. It monitors it, records it, revokes it when necessary. Every mechanism in the article—runtime enforcement, revocation, the audit trail—presupposes that a line has already been drawn between what the agent may decide and what it may not.
So who drew the line?
The article is precise about how to control an agent's authority and silent about how that authority was allocated in the first place. Some contract clauses were handed to the agent; some credit decisions were kept with a human. That allocation was a decision. It happened somewhere, made by someone, on some basis. IBM does not describe it—not out of oversight, but because the act of designing authority sits outside the frame of governance itself. Authority Control begins the moment the boundary exists. The boundary's origin is a different problem.
The Same Shift Is Emerging Elsewhere
The pressure is not only technical. It is arriving through policy as well.
In March 2026, Japan's Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry published Version 1.2 of the AI Business Operator Guidelines. The guidelines assume AI adoption as the default, then require that meaningful human judgment be inserted where autonomous output could compromise fairness or safety. Read carefully, the instruction is not "keep a human in the loop." It is more specific: decide where a human must intervene, guard against automation bias when they do, and recognize that some decisions demand a human account that carries real weight. That is not a rule about human presence. It is a rule about designing where judgment returns to a person.
Two very different institutions—an American technology vendor and a Japanese regulator—are converging on the same frontier from opposite directions. Both have moved past "should there be oversight" to "how should the placement of judgment be structured."
Governance Is Necessary—But Not Sufficient
Here the argument turns. The question IBM leaves open—who designs authority itself—cannot be answered in the vocabulary of AI Governance, because governance operates on authority rather than defining it. Governance governs authority. Decision Design determines where authority legitimately begins and ends. In one line: governance administers authority that has already been designed; it monitors, enforces, and proves. Deciding how the authority is apportioned in the first place is a different layer of work, and no governance framework claims it.
That layer needs a name, because what has no name tends to be decided by default—and authority decided by default is authority no one designed.
Decision Design
Decision Design is the discipline of designing that allocation deliberately. It treats the distribution of judgment—not the individual decision—as the object of design. Held to a stable definition across three questions:
What Decision Design designs
It designs the allocation of judgment. Given a business process, it enumerates the decisions inside it and assigns each one: this the agent may resolve autonomously, this a human must own. It specifies not only the split but the return path—the conditions under which a delegated decision escalates back to a person. Its output is a concrete artifact: the Authority granted, the Decision Boundary that bounds it, and the behavior triggered when that boundary is crossed. That artifact is what Authorization and Runtime Governance then enforce. Because it structures where judgment sits, Decision Design is best understood as a Judgment Architecture. Decision Design is not about improving decisions alone; it is about designing the authority structure within which decisions become institutionally legitimate.
What Decision Design is not
It is not model accuracy work. It is not workflow automation. It is not a statement of ethical principles. And it is not simply a Human-in-the-Loop implementation. Human-in-the-Loop asks whether a person remains in the process. Decision Design asks which decisions, under which conditions, are allocated to whom. Keeping a human is a conclusion; Decision Design is the reasoning that produces the conclusion. Inserting one reviewer and calling the problem solved operates at a different layer entirely.
What problem Decision Design addresses
It addresses authority that no one designed—authority that accretes by default. On the ground, allocation is usually settled by momentum: hand the agent whatever it can plausibly take, and return a human only after something breaks. That "we didn't decide it, it just happened" distribution is the gap IBM's article stops short of, and it is the same territory Japan's guidelines are trying to close from the regulatory side. Decision Design exists so that this allocation is chosen rather than inherited.
Decision Boundary
Every enterprise already has Decision Boundaries. Most simply never designed them consciously.
At the center of Decision Design sits the Decision Boundary: for a given decision, the line separating where an agent's authority reaches from where a human takes over. It is not an on/off switch. It is the unit through which Authority is allocated in graded steps—an act of Authority Allocation rather than a permission flag. Decision Boundaries are not operational thresholds; they are institutional demarcations of legitimate authority.
A boundary becomes concrete through four behaviors:
- Escalation — when an agent is about to act beyond its authority, the decision is raised to a higher judge.
- Override — a human reverses and rewrites the agent's conclusion.
- Suspend — the process halts in place.
- Review — the decision is inspected after the fact.
The revocation IBM describes is, in these terms, Suspend and Override surfacing at runtime.
These are not features bolted on one at a time; they are derived from a single boundary design. Which decision triggers Escalation, which deviation forces a Suspend, what is left for Review—written down as one coherent scheme, this becomes a set of Governance Decision Boundaries. Every judgment that crosses a boundary is captured in Decision Logs. Decision Logs do not merely record outputs; they preserve accountability continuity across distributed judgment processes. Only here does the Audit Trail and Accountability IBM demands stop being a bolt-on record and become a record that follows from the design.
Practical Example
Contract review. The naive build has an agent read the contract, flag risk, and hand the file to a lawyer for a final look. That is Human-in-the-Loop; it is not Decision Design. Designed as a boundary, the judgments are separated by type. Deviation detection on standard clauses goes fully to the agent. Interpretation of clauses touching liability or value escalates to legal the moment a defined threshold is crossed. A pattern matching a clause type that has produced litigation before triggers a Suspend and waits for a human. Which deviation invokes which behavior is written in advance, as one boundary. The lawyer no longer "reviews everything"—they own what crosses the line.
ERP approval. When an agent approves purchase orders or payments, the danger is authority accreting by momentum—precisely the "over-privilege without visibility" IBM names. As a Decision Boundary, the agent's Authority is bounded explicitly: approvable value bands, counterparty attributes, the range of repeat patterns it may clear. Inside the range, approvals pass automatically; transactions near the edge route to Review; an unfamiliar counterparty or an abrupt swing in value escalates to a person. Every approval that crosses a boundary lands in the Decision Logs. The human moves off the individual voucher and onto the design of the boundary itself.
In both cases, the variable is not whether a human is inserted. It is whether the line that distributes judgment was drawn deliberately or left to settle on its own.
Why Existing Frameworks Are Not Enough
No established discipline has owned the design of that allocation. Set them side by side and the gap is visible.
AI Governance is not enough. It administers, monitors, and proves authority that already exists. It handles the world after the line is drawn; drawing the line is outside its remit.
DX is not enough. Digital transformation relocates work into software. Which decisions a human retains is treated as a byproduct of that migration, settled implicitly rather than designed.
Automation is not enough. Automation pushes in one direction—delegate whatever can be delegated. Where to stop, where to return judgment to a person, does not follow from its logic.
AI Ethics is not enough. Ethics articulates what ought to be, but does not descend to which specific decision, under which condition, is allocated to whom.
Each owns a different layer—administration, migration, efficiency, principle—and the design of allocation falls between them, owned by none. Decision Design is the concept that spans all four and holds a single accountability for Authority Design. It is the missing layer in the enterprise's Governance Architecture: the layer that decides how authority is distributed before any of the others operate on it. Institutional Governance works only when this layer is built underneath it: without designed authority, institutional authority is asserted, not structured.
Conclusion
IBM carried the argument from Identity and Access Management to Authority Control, and described—about as completely as anyone has—how the authority granted to an autonomous agent should be operated and proven.
The next requirement sits one step before that. Not how to control authority, but how to design it: who holds which decision, and how far, drawn on purpose rather than by drift.
Controlling authority is already becoming reality. The open question is who designs authority in the first place. Return to where this began—Authority Control governs a line that someone must first draw—and the answer names itself. IBM reached Authority Control. The next question is not how to govern authority, but who designs it. That question defines the next frontier of Enterprise AI. The framework for that frontier is Decision Design.
Decision Design is a judgment architecture framework proposed by Ryoji Morii, founder of Insynergy Inc., for structuring authority, accountability, and decision boundaries in AI-augmented organizations.