The authority paradox: Businesses are granting AI agents power before governance is ready

When a banking application stalls or a digital checkout fails, infrastructure engineers are routinely inundated by thousands of alerts generated simultaneously across application servers, networks, databases, authentication gates, and third-party vendors. Many of these telemetry points simply report different secondary symptoms of a single, underlying architectural failure. While an AI agent can rapidly correlate these disjointed signals, identify the root cause, and formulate a remediation strategy, granting the software permission to execute that response fundamentally changes the nature of the infrastructure.

The agent may restart a critical service, modify a network configuration, block a customer account, or process a financial refund before an engineer ever reviews the incident. A successful automated intervention can drastically compress outage durations, but an execution error can destabilise a functional system, disrupt the user experience, and alter corporate records that are highly resource-intensive to restore.

This tension defines the authority paradox that emerges as enterprises transition autonomous software from isolated testing sandboxes to live production environments. Organisations are aggressively expanding the boundaries of what software can independently decide and alter, even as they work to establish how those non-deterministic choices should be governed. The ultimate success of these deployments depends entirely on the fidelity of the data inputs the agent receives, the non-human identity perimeter under which it operates, the granularity of the permissions attached to that credential, and the organisation’s capacity to intervene after an automated action has initiated.

Transitioning from passive machine diagnosis to active operational execution might appear to be a minor software iteration, but in structural terms, it shifts the business toward an environment in which software has the independent authority to reshape enterprise architecture without waiting for human review.

Decisions depend on the information available

Peter Marelas, Senior Director of Product Management at New Relic, argues that AI agents can work through complex, multi-step problems, test their output and refine a response. That capability may resemble a complete understanding of the situation, although the agent remains bounded by the data and systems within reach. “An agent is only as good as what it can see,” Marelas said. “Give it fragmented data, and it will move towards the wrong fix, but give it a clear, connected view of the system, and it can be trusted to act confidently.”

A failed checkout illustrates the constraint. The problem may appear as an application timeout, but the cause could be a payment provider, an authentication service, a recent software release or a sudden increase in traffic. An agent may still reach a plausible conclusion from application logs without realising that important network or third-party service data is missing.

Human engineers, on the other hand, can navigate these incidents by drawing on experience and institutional memory, instantly understanding if an alert is typical during a scheduled infrastructure upgrade or if a separate department has altered a critical software dependency. Unless this implicit background data is natively integrated into an agent’s inputs, the model will assert complete operational certainty while remaining blind to its own information gaps.

Once an AI agent is granted the authority to act, its entire perception of the enterprise is strictly bounded by the specific logs, alerts, and business records that feed its reasoning engine. Technology leaders must clarify exactly which systems are included within this digital perimeter, how current the underlying telemetry remains, and how conflicting data signals are reconciled before these automated choices are allowed to affect live production. Attempting to solve this visibility issue by granting an agent wholesale access to every corporate repository is an unviable strategy, as it introduces severe security and privacy exposures across the network.

The practical requirement is to define the minimum viable context needed for any autonomous decision, while explicitly establishing fallback policies for when that data is missing or contradictory. In many operational workflows, halting execution and requesting human validation is the only correct course of action. This structural restraint must be hardcoded directly into the surrounding business logic, because an agent optimised purely for task completion will otherwise press forward towards the most statistically probable response, regardless of whether its operational view is complete.

Identity and permissions shape what follows

Once an agent reaches a decision, identity controls determine what it can do with it. Dan Mountstephen, Senior Vice President and General Manager for Asia Pacific and Japan at Okta, expects enterprises to use several models, cloud services and AI platforms. Consistent governance cannot depend on every team selecting the same system. Mountstephen describes identity as the mechanism for applying controls across this mixed technology environment. “Identity is the control plane,” Mountstephen said. In practice, that means establishing ownership, authentication, permissions, revocation and activity records around the agent rather than expecting the model to govern itself.

An AI agent operates as a non-human identity alongside APIs and service accounts, but it can interpret requests, select tools and call other systems. Broad, static permissions can therefore expose more of the organisation than the task requires. Eric Kong, GVP for ASEAN at SailPoint, further argues that agents should be managed like privileged employees, with named human owners, access histories and permissions that change with their roles. Without clear ownership, responsibility for reviewing an agent’s expanding access can become diffuse.

In these deployment scenarios, operational permissions must be tied directly to the immediate task rather than the full technical capability of the underlying model. For example, a customer service agent could be authorised to prepare a digital refund request while the final financial approval remains restricted to a human employee. Over time, that system might receive expanded authority to complete routine transactions below a defined financial threshold, while larger or disputed items are automatically routed for senior human review. The boundary should be enforced by the surrounding systems, not left as an instruction the agent is expected to observe.

Implementing this level of infrastructure-level enforcement requires adopting a model of zero standing privilege. Under this framework, an autonomous agent is granted environmental access solely for the duration of a specific task and loses those credentials immediately upon completion of the task. This continuous adjustment drastically limits the network exposure available to a compromised or misdirected non-human identity, while forcing technology teams to explicitly define what each workflow actually requires to function safely.

Maintaining this level of structural oversight becomes significantly more complicated when multiple autonomous agents collaborate within a single business process. Accountability frequently fractures when one agent gathers the raw corporate information, a second agent assesses the operational parameters, and a third executes the terminal action. Enterprise audit logs must capture the unique identities, underlying resources, specific permissions, and transactional handoffs involved in each step of the chain. Without this structural granularity, a system log will only show what changed within the network without ever revealing how the automated decision was produced.

A SailPoint research cited by Kong indicates that 82% of organisations use AI agents, and more than half allow them to access sensitive information. The same research found that 80% had seen an agent act outside its intended scope, but only 44% had established a governance policy. These vendor-reported findings highlight a major operational deficit that businesses must examine internally. While connecting an agent to a network can happen quickly, assigning clear human ownership, setting strict review cycles, and building reliable revocation procedures require deep, sustained coordination across security, IT, legal, and business units.

Automation magnifies existing weaknesses

These identity perimeters must operate within corporate networks that are frequently already compromised by unreviewed access privileges, broadly shared directories, and orphaned accounts left active after internal structural reorganisations. Kash Sharma, Managing Director for Australia and New Zealand at BlueVoyant, characterises these accumulated weaknesses as security debt. While human employees naturally bypass these systemic flaws using institutional memory, knowing intuitively to avoid an outdated folder or an unmanaged service account, an autonomous agent processes network permissions literally. Because these informal human safeguards are rarely documented in a form that an agent can apply, automation fundamentally alters the scale of the underlying operational risk.

A human worker can be limited by manual search speeds, but an autonomous agent can query thousands of confidential records, execute repeated system calls, and apply identical flawed choices across multiple business units before an information security team can identify the signature pattern.

The agent does not engineer these structural flaws, but it exploits them at machine velocity. A poorly configured storage folder or an unreviewed access rule can be highly consequential when software can automatically process the exposed data, because the system lacks the context needed to distinguish routine corporate documentation from restricted proprietary records. Similarly, the required remediation steps are entirely familiar to technology leaders: conducting continuous permission audits, implementing precise data classification, purging dormant network credentials, and assigning distinct human ownership. The rapid adoption of agents simply raises the operational cost of leaving this foundational housekeeping incomplete, converting static, localised weaknesses into repeatable systemic failures.

This friction becomes acute during the transition from pilots to production. Public-sector and enterprise pilots typically operate within a curated sandbox using clean data, selected users, and close developer oversight. Live production environments, by contrast, introduce legacy permissions, inconsistent business records, and unmapped operational dependencies. A workflow that performs flawlessly under curated test scenarios will behave unpredictably when it encounters operational exceptions that human employees previously resolved through personal judgment. The deployment of autonomous agents ultimately reveals whether a business has mapped its data environment well enough for software to navigate it safely, as a model may perform exactly as expected while the surrounding network exposes it to chaotic conditions the pilot never anticipated.

Production control must include reversal

Live production demands continuous runtime safeguards that extend far beyond static, pre-deployment validation. To maintain control, organisations must establish absolute visibility over an agent’s real-time actions, enforce strict structural limits on its operational parameters, and retain the capability to intervene immediately if autonomous behaviour drifts outside the approved corporate workflow.

Fumiki Negishi, Vice President and General Manager of HPE’s HPC and AI business in Asia Pacific and Japan, argues that governance must continue while an agent is operating, with monitoring, policy enforcement and recovery built into production. Deloitte research cited by Negishi indicates that 21% of organisations have a mature governance framework for autonomous agents. Pre-deployment testing cannot cover every combination of incomplete information, system failure and conflicting instructions that may appear after release.

Constant human approval would undermine much of the efficiency of autonomy, while unrestricted discretion creates exposure when conditions depart from those of testing. Graduated authority offers a middle ground, with runtime controls that reflect consequences, reversibility, and evidence quality.

Low-risk, easily reversible operations can proceed via automated execution, allowing agents to categorise service tickets, gather basic diagnostic telemetry, or draft preliminary client responses without human intervention. Conversely, high-consequence alterations affecting sensitive corporate records, core financial systems, or critical digital infrastructure demand multi-tiered validation, restricted runtime privileges, or explicit human authorisation. This framework separates an agent’s structural permissions from the conditional environments under which those privileges can be used. Even if an agent possesses the technical right to alter an application configuration, enterprise policy must block the transaction whenever incoming telemetry is incomplete, when system signals conflict, or when the expected recovery state is unavailable. Operational confidence is not derived from the absolute capability of a language model, but from verifying that the incoming data matches an approved corporate workflow.

Managing these systems in live environments requires monitoring tools that capture far more than simple task completion metrics. Engineering and security teams need a granular audit trail detailing the exact contextual data the agent parsed, the explicit enterprise policies that permitted the execution, the specific non-human identity that initiated the transaction, and the precise system changes that occurred. Maintaining this level of tracking is particularly vital because the operational baseline shifts whenever the underlying foundation models, system prompts, integrated developer tools, or data pipelines are updated.

Furthermore, technology leaders must separate the capacity to stop an erratic agent from the capability to reverse its real-world outcomes. While a standard system kill switch can instantly freeze further programmatic activity, it cannot natively restore a deleted database index, claw back an erroneous payment instruction, or repair a broken infrastructure dependency. Certain system modifications can be rolled back to a retained snapshot, but others demand resource-intensive client contact, complex financial reconciliation, or manual records reconstruction.

This spectrum of clean reversibility should directly dictate the level of authority granted to an autonomous system prior to deployment. Workflows backed by predictable, deterministic rollback mechanisms can safely tolerate higher levels of automation, whereas operations with cascading consequences outside the core network require narrower permissions, clear human oversight, and pre-configured remediation runbooks. Ultimately, an organisation possesses genuine operational control only when it can explain the underlying logic of an agent’s decision, enforce strict boundaries on what the software can alter, reconstruct the complete sequence of actions, and terminate anomalous processing instantly. Until these architectural foundations are established, expanding the deployment of autonomous agents amounts to granting excessive system access rather than establishing dependable corporate authority.

Editor’s note: This article draws on insights shared by technology leaders from New Relic, Okta, SailPoint, BlueVoyant and HPE as part of a multi-company contribution to Tech Edition. Some inputs, including company-cited research, have been synthesised into broader industry analysis.