Who Authorized the AI?

A license is approved. A connector is enabled. An agent is allowed to act through an existing identity. Sometimes that means delegated user access; sometimes it means a workload identity with its own permissions. Each decision may be reasonable on its own. Together, they can create authority that no one explicitly approved as a whole.

Who authorized the AI?

Not who bought it. Not who approved the vendor. Not who turned on the license.

More precisely, who authorized the AI-enabled workflow: what it may know, what it may decide, and what it may do?

In many enterprises, the answer is scattered across several teams and systems. The business approved the tool. IT enabled the platform. Security reviewed the provider. Identity granted access. Yet those decisions may never add up to an explicit authorization of the combined workflow.

This is authorization by accumulation. The components can be approved while the resulting authority remains undefined.

Approval is fragmented. Authority is cumulative.

Enterprise approval processes are often organized around components and artifacts. Procurement reviews a vendor. Security assesses a platform. Identity grants a principal access. A deployment process approves a release. Each review has a legitimate purpose, but none necessarily answers what the assembled workflow is authorized to do.

A user may be allowed to read a customer record. That does not automatically authorize an agent to combine the record with email and support history, infer what the customer is likely to do next, and update the account.

An engineer may be authorized to deploy code. A finance leader may be authorized to release funds. Neither decision automatically gives an agent standing authority to deploy or pay, regardless of whether it acts through delegated user access or its own workload identity.

An access review can confirm that a principal belongs to the right group. It does not decide whether an AI workflow should combine three systems, make an inference, and write the result into a fourth. Access defines part of the reachable environment. Authorization must also cover purpose, context, decision rights, action rights, evidence, ownership, duration, and recovery.

The relevant unit is the combined workflow.

The operating model has lagged access

Many enterprises have moved quickly on AI access and more slowly on the operating model around it.

McKinsey’s 2025 global survey, based on 1,993 respondents, found that 88 percent said their organizations regularly used AI in at least one business function. Nearly two-thirds had not begun scaling AI across the enterprise, and 39 percent reported any enterprise-level EBIT impact. The same research found that AI high performers were nearly three times as likely as others to have fundamentally redesigned individual workflows.

ISACA’s 2026 AI Pulse Poll, drawing on more than 3,400 digital-trust professionals, found that 90 percent believed employees were using AI in their organizations. Only 22 percent said the return had met or exceeded expectations, and 38 percent reported having a formal, comprehensive AI policy.

These are self-reported surveys, not a census of every enterprise. Neither one measures authorization by accumulation. They do show the conditions in which it can emerge: broad access, uneven value, incomplete governance, and workflows that have not yet been deliberately redesigned.

Across many organizations, tool access has moved ahead of workflow design, value measurement, and authority boundaries. A company can therefore be far along in AI adoption while remaining early in operating AI as an enterprise capability.

Authorize the workflow

Not every use of AI needs the same process. For this purpose, I would treat a workflow as material when it uses sensitive enterprise context, influences a consequential decision, acts in another person’s name, writes to a system of record, or creates effects that are difficult to reverse. Organizations can map that threshold to their existing risk tiers and regulatory obligations.

A material workflow requires explicit, durable authorization. Some organizations may call the artifact an AI use-case record, system card, impact assessment, or production-readiness record. The name matters less than the decision it preserves.

Start with the job. What happens today? Where does the work wait? What does it cost? Where does quality break down? Who owns the result? What should improve if the AI works well?

“Help account teams” is too vague to authorize. “Prepare a renewal-risk summary from approved CRM and resolved support data for an account manager to review” is closer. It identifies the work, the sources, the output, and the human owner. A credible authorization also establishes a baseline, expected result, acceptable failure, and an accountable business owner.

Define the context boundary. AI becomes more useful when it can reach email, contracts, source code, customer records, support tickets, financial data, and internal knowledge. That reach also makes existing permission debt easier to search, combine, and use.

The model did not create years of excessive sharing, stale groups, broad links, abandoned repositories, or unclear retention rules. The workflow can still turn those conditions into a more consequential capability.

The authorization should therefore name the approved systems, inherited or delegated permissions, data classifications, trusted and untrusted sources, external destinations, retention rules, and prohibited combinations. The customer-account workflow may need CRM records and resolved support cases. It does not need every employee’s mailbox or every historical contract.

Separate decision rights from action rights. Decision rights describe what the workflow may classify, prioritize, recommend, or decide. Action rights describe what it may send, change, approve, purchase, deploy, delete, or trigger.

Those rights should be narrower than the platform’s maximum technical capability. The customer-account workflow may prepare a risk summary without being allowed to change the account, contact the customer, adjust a forecast, or offer a concession.

Human approval is useful only when the person sees the relevant context, understands the consequence, has time to challenge the recommendation, and can reject it without being punished for slowing the process. Otherwise, the approval step becomes a click-through control attached to an automated decision.

Design for evidence, recovery, and change

AI workflows will sometimes be wrong, manipulated, or used outside their intended conditions. A material authorization has to assume that failures will occur and specify how the organization will see, interrupt, investigate, and contain them.

Traditional application logs may show that an API call occurred. They may not show the workflow’s objective, the context that influenced it, the tools it could use, what it attempted, who approved the action, or how the result was corrected.

Evidence does not mean retaining every prompt and retrieved record indefinitely. Logging should be proportionate to risk, minimize sensitive content, enforce access and retention rules, and preserve enough lineage to reconstruct consequential actions.

ISACA reported in March 2026 that 56 percent of respondents did not know how quickly their organization could halt an AI system during a security incident. Only 43 percent had high confidence in their ability to investigate and explain a serious incident, and 36 percent said humans approved most AI-generated actions before execution.

For the customer-account workflow, useful evidence might include the sources behind each risk summary, the version of the workflow that produced it, the recommendation shown to the account manager, and any resulting action. Preventing direct CRM writes simplifies recovery; a visible correction path lets the account manager repair a bad summary without hiding the failure.

Some effects cannot be rolled back. An email may already have been sent. A payment may already have been released. A customer may already have received a decision. Those workflows need staged execution, transaction limits, dual control, idempotency where possible, compensating actions, credential revocation, and a clear incident owner.

Every material workflow also needs one named accountable business owner. The role needs a current human incumbent, even though approvals and control responsibilities remain distributed. Depending on the organization and the risk, technical, data, security, privacy, legal, compliance, model-risk, and operational control owners may all have decisions to make. The accountable owner cannot waive their obligations.

A cross-functional AI council can coordinate policy and escalation. It should not become the nominal owner of every production workflow.

The authorization also needs change triggers. A new model or provider, data source, connector, tool, geography, regulated decision, user population, write permission, spending limit, or degree of autonomy should trigger an impact assessment. If the change alters the workflow’s purpose, risk tier, context boundary, decision rights, action rights, or recovery assumptions, it requires reauthorization.

If the customer-account workflow later gains permission to update the CRM or contact a customer, its authority has materially changed. The earlier authorization no longer covers it.

Make the authorization operational

Much of this work already has a home. Application risk assessment, model risk management, privacy review, identity governance, change control, and incident response remain relevant. NIST’s AI Risk Management Framework already organizes the lifecycle around governing, mapping, measuring, and managing risk.

What changes is the object being reviewed: the combined workflow rather than each component in isolation. Identity, data, models, instructions, memory, tools, and business process can compose differently at runtime even when every individual part has been reviewed before.

Authorization records the business and risk decision. Enforcement turns that decision into technical limits. Assurance tests whether the live workflow still matches both.

The authorization record is the authoritative statement of intended authority. It should capture the purpose and expected value; identity and chain of delegation; approved context; decision and action rights; evaluation and evidence requirements; interruption and recovery design; accountable owner; accepted residual risks; review date; and reauthorization triggers.

The record is not the source of truth for live configuration. Identity policies, API scopes, tool registries, gateways, deployment configuration, and monitoring should implement and test the authorization, while their own platforms remain authoritative for current state.

The record also cannot become a document abandoned in a SharePoint folder. At minimum, it should link to the authoritative records for identity, deployment, tool and API policy, configuration, monitoring, and incidents. Higher-risk workflows can automate checks against those systems. Lower-risk workflows do not need a new integration program merely to satisfy the record.

Existing controls should enforce the authorization. Identity systems establish the principal and constrain delegation; data controls limit context; gateways restrict tools and actions; deployment controls manage approved versions; monitoring preserves evidence and detects drift. These mechanisms are consistent with Zero Trust principles, but no individual control point can define what the business intended the combined workflow to do.

An enterprise is unlikely to lose control of AI in one dramatic moment. Control will be delegated gradually: a license here, a connector there, an inherited permission somewhere else. Each step can sound reasonable while the combined authority becomes something no one explicitly approved.

That is authorization by accumulation.

If no one can point to the decision that authorized the combined workflow, including its purpose, context, authority, limits, evidence, and owner, then the enterprise did not authorize it.

It accumulated it.