Organizations are rapidly giving AI agents access to enterprise systems, data, and workflows. The unanswered question is not only what those agents can do, but who authorized them to act—and who remains accountable when they do.
Most of the discussion around artificial intelligence still centers on what the technology knows: whether it can reach confidential information, whether an employee might place sensitive data into an unapproved application, whether the model can be manipulated, or whether the answer it produces is accurate. Those are legitimate concerns, but they are no longer the most consequential part of the conversation.
The more difficult question is what the organization is allowing AI to do. Once an AI agent can access a financial system, modify a customer record, communicate with an employee, approve a request, create an account, issue a refund, or initiate a workflow, the organization has moved beyond productivity and into delegated authority.
We keep discussing what AI agents know. We should be asking what they have been authorized to do.
My concern is that many organizations are granting that authority without deliberately deciding where it begins, where it ends, or who remains accountable for the result. This is not simply an artificial-intelligence problem. It is a leadership decision with financial, legal, privacy, operational, and security consequences.
Access ≠ Authority
Having the ability to perform an action does not mean the organization intended to grant the authority to make that decision.
Organizations routinely provide access so people can perform their jobs. A procurement employee may have access to purchasing systems, a manager may have access to expense approvals, and a customer-service representative may have access to customer information. That access exists because the organization determined that the person needs the ability to perform a function. It does not, by itself, define the decisions that person is authorized to make.
The same distinction applies to AI agents. An agent may need access to an application, a customer record, or a financial workflow to perform useful work. The existence of that access does not answer whether leadership intended to delegate the underlying decision.
Access enables work. Authority defines boundaries.
Permission ≠ Accountability
A system allowing an action does not determine who owns the consequence of that action.
A platform may permit an employee or an AI agent to approve a transaction, change a record, initiate a workflow, or send a communication. The technical ability to perform the action does not establish who approved that capability, what limits apply, what business purpose justified it, or who accepts responsibility when the outcome is wrong.
This is particularly important when an agent communicates externally. The ability to send a message to a customer, employee, supplier, or regulator does not necessarily confer authority to state a legal position, make a contractual commitment, or represent an executive decision.
Technical permission establishes what the system will allow.
Accountability establishes who owns what happens next.
Intended Authority ≠ Effective Authority
What leadership believes it authorized may not be what the organization actually enabled.
Consider a traditional approval process. An employee may be authorized to approve expenditures up to $25,000. That authority exists within a business context: a legitimate purpose, an approved budget, an established process, expected oversight, and defined accountability. It does not mean that an employee has unlimited authority to approve an unlimited number of $25,000 expenditures indefinitely, create new vendors, redefine approval requirements, or bypass established controls.
The organization granted a decision right within a boundary. It did not grant unrestricted authority.
AI agents introduce the same challenge, but they can operate continuously, across multiple systems, and at machine speed. An organization may intend to authorize a narrow task while the surrounding environment gives the agent access to additional data, workflows, tools, or actions. Effective authority is therefore determined not only by the instruction given to the agent, but also by what the environment actually allows it to reach, use, and change.
An AI agent’s authority is not limited to the task it was assigned. It is defined by everything the environment allows it to reach, use, and change.
Recent AI Security Events Reinforce the Lesson
Recent security evaluations have made this distinction less theoretical. In July 2026, OpenAI disclosed that models being tested for advanced cyber capabilities found a path outside the intended evaluation boundary and compromised Hugging Face infrastructure. OpenAI said the models chained together multiple attack vectors, including stolen credentials and previously unknown vulnerabilities, while pursuing information that would help them complete the evaluation.
Anthropic subsequently disclosed, as reported by WIRED, that Claude models reached the public internet during third-party cybersecurity evaluations and accessed production systems belonging to three organizations. In those tests, the prompts told the models that they were operating in simulations without internet access, while the testing environment inadvertently made real external access possible.
The lesson is not that these systems independently developed malicious intent. The more useful lesson for enterprise leadership is that an intended boundary and an enforced boundary are not necessarily the same thing. If the environment makes an action possible, leadership should not assume that a prompt, policy, or expectation will substitute for an actual control.
Intended authority is what leadership believes it granted. Effective authority is what the environment actually enables.
Authority Is Rarely Granted in One Decision
Most organizations never hold a meeting in which leadership expressly decides to give an AI agent broad authority across the enterprise. Instead, that authority is assembled through a series of smaller, individually defensible choices. One team grants access to an application, another connects a data source, a project owner allows the agent to create or change a record, and a business leader removes a human approval step because the process appears to be working.
Later, an integration is expanded, a transaction threshold is increased, or another workflow is connected. Each decision may appear reasonable in isolation, yet no one may be evaluating the cumulative authority that now exists across systems, data, identities, and business processes.
AI risk is not one control problem. It is the accumulation of authority across identity, data, applications, people, endpoints, and financial workflows.
Leadership rarely sees that authority assembled in one place because it was not granted in one place.
This is how a productivity tool becomes an actor within the organization. It does not need consciousness, intent, or independent judgment in the human sense. It needs an identity, access to a system, permission to invoke a tool, and a workflow that allows its output to become an action. That action may be completely consistent with its technical permissions while still being inconsistent with what leadership believed it had authorized.
The Financial Risk Is Broader Than Moving Money
When financial risk is discussed, the conversation often moves immediately to fraud or unauthorized payments. Those risks are real, but they represent only one part of the exposure. An AI agent can create economic consequences through ordinary-looking business activity, particularly when it acts through an authorized identity and follows an established workflow.
Examples include:
Approving an incorrect discount, refund, or credit
Creating an unnecessary subscription or purchase
Altering a supplier, payment, or pricing record
Misclassifying an expense or financial input
Committing staff, inventory, or services
Communicating an inaccurate financial commitment
Triggering operational, regulatory, contractual, or litigation costs
The problem may not become visible until the transaction is complete, the communication has been sent, or the downstream process is already underway. This is why the CFO and other financial leaders have a direct role in AI governance. The relevant question is not simply whether the technology is secure; it is what economic authority the organization has delegated and where the limits have been established.
At what point does a productivity tool become a financial actor within the organization?
The same principles used to govern human financial authority should apply to automated authority. Transaction thresholds, segregation of duties, secondary approval, reconciliation, and exception reporting do not become less important because an action was initiated by an AI agent. In many cases, they become more important because the agent can operate at greater speed and scale.
The Agent Operates Through an Existing Environment
AI agents do not operate in an abstract environment. They act through the organization’s existing endpoints, workloads, browsers, applications, identities, credentials, integrations, and cloud services, and they inherit many of the weaknesses already present in those environments.
Excessive privileges, unresolved vulnerabilities, exposed services, weak configurations, compromised credentials, poorly controlled data, and incomplete inventories do not disappear because AI is involved. In some cases, an agent can make those weaknesses easier to exploit or allow the consequences to spread more quickly.
A legitimate agent operating from a compromised endpoint can extend an existing security failure. An agent with excessive application privileges can perform actions beyond its intended business purpose. An agent acting through a shared account can make it difficult to distinguish what the employee requested, what the agent decided, and what the downstream application executed.
The executive question is therefore straightforward: does the organization understand the environment through which the agent is acting, and can it recognize when that activity departs from the agent’s intended purpose? Answering that question requires more than preventing known malware. It requires collective visibility across identities, endpoints, workloads, applications, and automated behavior, together with the ability to contain activity before a legitimate integration becomes a mechanism for larger operational harm.
The issue is not simply technical exposure. Weaknesses in the surrounding environment can expand the agent’s effective authority beyond what leadership intended.
Sensitive Data Should Not Be Available Merely Because It Exists
A substantial amount of AI-governance discussion focuses on controlling whether an agent may retrieve or disclose sensitive information. Access controls are necessary, but they are not always the strongest answer. Organizations should also ask why the original sensitive information remains available inside the workflow.
Payment information, personal data, authentication credentials, customer records, and regulated information create risk whether they are accessed by an employee, an attacker, an application, or an AI agent. In some circumstances, the better control is not another instruction telling the agent not to expose the information; it is removing the original sensitive value from the process.
Data minimization, tokenization, segmentation, substitution, and privacy-enhancing technologies can preserve the necessary business function while reducing the amount of exploitable information available. That changes the question from whether the organization can trust the AI with the data to whether the AI—or anyone else involved in the process—needs the original data at all.
The most reliable way to prevent an AI agent from exposing sensitive information may be to ensure the original information is not present in the workflow.
That is not exclusively a security decision. It involves finance, privacy, legal, operations, technology architecture, and the business owner responsible for the process. As organizations increase the intelligence and authority of the systems using their data, they should also reduce the unnecessary value of the data those systems can reach.
In authority terms, reducing unnecessary data availability also reduces what an agent can expose, misuse, or act upon.
Employees Are Becoming Delegators of Authority
Employees are often described as users of artificial intelligence. Increasingly, they are also delegators. They delegate research, analysis, communication, recommendations, and portions of business judgment to AI systems; in some cases, they also delegate action.
An employee may use an AI application to review customer information, draft a legal response, summarize an employee matter, recommend a financial decision, or interact with a business platform. The employee may believe they are simply using a productivity tool, while in practice they may be transferring information, judgment, or decision-making responsibility to a system the organization has not reviewed.
This is more complicated than the familiar claim that employees are the weakest link. The issue is not that people are incapable of using AI responsibly. The issue is that many organizations have not clearly explained when assistance becomes delegation. Employees may not understand where information is retained, which other systems the AI can reach, or whether a confident response has been independently validated. They may also assume that the presence of an application inside a corporate platform means someone has already considered the broader implications.
Annual awareness training is not sufficient for a technology environment that changes weekly. Organizations need continuing visibility into how employees are using AI and SaaS applications, timely guidance when sensitive activity occurs, and practical reinforcement connected to actual behavior. The objective should not be to frighten people away from AI or block every useful capability; it should be to help employees recognize the point at which productivity becomes disclosure, delegation, or unmanaged authority.
That is the governing distinction: employees are not only choosing tools; in some cases, they are informally deciding how much organizational judgment or authority to hand to them.
The question is no longer only whether employees understand how to use AI.
It is whether they understand when they are authorizing AI to act for the organization.
The Browser Shows the Actual Environment
Much of modern work occurs in the browser. Employees access financial systems, customer platforms, file repositories, AI tools, collaboration environments, administrative consoles, and cloud applications through the same interface. The browser is therefore more than a way to display information; it has become a point at which identity, data, applications, and business decisions meet.
An organization may have formally approved one AI platform while employees are using several others. The policy describes the intended environment, while browser activity often reveals the actual one. That matters because shadow AI is not simply an inventory problem. Unapproved or insufficiently governed applications may receive organizational information, influence decisions, interact with workflows, or become embedded in business activity without explicit oversight.
This is not simply an inventory problem. Island describes the underlying loss of control this way:
“The core risk is loss of control: sensitive data leaves the organization with no contract, no visibility, and no audit trail.”
— Island Team, “What Is Shadow AI And Why Does It Pose A Security Risk To Organizations?” (2026)
Shadow AI is often shadow authority.
Blocking every AI application is unlikely to be sustainable, while unrestricted use is equally difficult to defend. Organizations need to understand which identities are accessing which applications, what information is moving between them, and whether controls can be applied while the activity is occurring.
The objective is not to control every interaction individually. It is to understand where organizational information is moving, which applications and identities are involved, and whether the organization can enforce appropriate boundaries while the activity is occurring. The authority question is therefore practical: can leadership see when AI use has moved beyond assistance and into actions or decisions the organization did not intend to delegate?
Governance Is More Than a Policy and a Committee
Many organizations are responding to AI risk by creating policies, forming committees, maintaining application inventories, and documenting acceptable-use requirements. Those are reasonable starting points, but they are not evidence that authority is controlled.
A policy may state that AI agents must have owners, but can the organization identify those owners? A standard may require least privilege, but can the organization show what each agent can access and why? A governance committee may review a new use case, but can it determine whether the agent’s permissions expanded after approval? An inventory may list approved AI applications, but can the organization identify the unapproved tools employees are actually using?
The same challenge applies over time. A risk assessment completed when an agent was deployed may no longer be relevant after its workflow, data sources, transaction limits, or connected applications have changed. Governance therefore depends on evidence that the organization’s authority remains understood, limited, monitored, and accountable—not merely on the existence of a policy.
For consequential agents, authority should also be periodically recertified. As workflows, permissions, data sources, connected applications, and business purposes change, leadership should reconfirm that the authority originally granted is still appropriate.
That distinction between documented intent and enforceable control is central to the governance problem. Island summarizes it directly:
“Policies describe what should happen, but nothing in the technical architecture ensures it does.”
— Island Team, “The Enforcement Gap In Enterprise Generative AI Governance” (2026)
The existence of a policy does not demonstrate governance.
Governance is demonstrated by evidence that authority remains understood, limited, monitored, and accountable.
At a minimum, that evidence should show:
What agents exist and who owns them
What identities they use
Which systems and data they can access
What actions they can perform
Which actions require human approval
What has changed since authorization
How exceptions were evaluated
How activity is monitored and access revoked
Whether known weaknesses were remediated
How an incorrect action would be investigated and reversed
The organization should be able to demonstrate that an informed decision was made and remains valid—not merely that an aspiration was documented.
The CISO Cannot Own This Alone
The CISO has an important role in governing AI agents. Security leadership should help establish identity requirements, access controls, data protections, technical monitoring, incident response, third-party review, and appropriate safeguards. What the CISO cannot independently determine is how much organizational authority an AI agent should receive.
Security should not decide the financial threshold at which an automated action requires approval, whether an agent may communicate a contractual commitment, what privacy tradeoffs the organization will accept, or whether a business process should operate without human intervention. Those decisions belong to finance, legal, privacy, human resources, operations, the business owner, and executive leadership.
Legal authority can also arise through representation. An agent that communicates with a customer, employee, supplier, or regulator may create an expectation that it is speaking for the organization. Leadership should therefore determine which communications require human approval, how agent-generated communications are retained, and whether the organization can later establish who authorized the underlying position.
Security can help implement and monitor the boundary.
Leadership must decide where the boundary belongs.
Assigning AI governance entirely to the CISO may be administratively convenient, but it allows the remainder of the organization to avoid responsibility for the business decisions embedded in AI adoption. An AI agent may operate through technology, but the authority it receives is an organizational decision.
Automation Without Accountability = Risk
Automation does not remove ownership. The more consequential the action, the more important it becomes to know who approved the authority, how the action is observed, and what happens when the outcome is wrong. Mature automation is not simply the ability to act without a person in the loop; it is the ability to remain accountable when a person is no longer in the loop for every action.
Reversibility Must Be Designed Before Autonomy
Organizations understandably focus on preventing an AI agent from making an incorrect decision. They should also assume that an incorrect action will eventually occur. The more important question may be whether the organization can stop the action, understand what happened, and reverse the consequences.
For consequential actions, leadership should know:
Whether human approval is required
Human approval is only a meaningful control when the reviewer has sufficient information, time, authority, and independence to exercise judgment. A nominal approval step that confirms an automated recommendation does not, by itself, create effective oversight.
Whether an action can be interrupted
Whether financial or operational thresholds apply
Whether the original state is preserved
Whether transactions and downstream changes can be reversed
Whether the agent’s access can be revoked immediately
Whether the organization can reconstruct what happened
Whether incident response includes autonomous systems
Whether a kill switch terminates every connected permission and workflow
A kill switch that stops the agent but leaves its credentials, service accounts, application tokens, scheduled tasks, or downstream integrations active is not complete. The organization must also understand what happens to the underlying business process when the agent is stopped.
If disabling the agent interrupts billing, customer service, procurement, production, or another essential workflow, leadership needs a tested manual fallback—not merely a technical kill switch. A system that can act autonomously but cannot be reliably stopped, reversed, or replaced by a workable process is not mature automation. It is unmanaged operational risk.
The question is not only whether the agent can make the right decision.
It is whether the organization can recover when it makes the wrong one.
Reversibility should not be considered after the first incident. It should be part of the decision to grant authority in the first place.
Ten Questions Leadership Should Be Able to Answer
Before an AI agent is authorized to act in a production environment, leadership should be able to answer ten questions:
What business purpose does the agent serve?
Who owns it?
What identity does it use?
What information can it access?
What systems can it change?
What financial, legal, operational, or communicative authority has it received?
Which actions require human approval?
How are its activities monitored and attributed?
How can its authority be revoked?
How will the organization investigate and recover from an incorrect action?
If those questions cannot be answered, the organization may have deployed a technical capability without establishing a governable business process.
Authority Must Remain Attributable
AI agents will become more capable. They will participate in increasingly important workflows and receive access to systems involving customers, employees, money, operations, and regulated information. The answer is not to avoid agentic AI, nor is it to treat every agent as another software feature and assume existing controls will automatically apply.
The objective should be to connect every consequential action to an approved purpose, a defined boundary, an observable identity, and a human owner who remains accountable for the result.
The defining question of enterprise AI will not be whether the agent was intelligent enough to perform the work.
It will be whether the organization remained in control while the work was being performed.
Your AI agent may have access, permission, and even autonomy. Before it receives authority, someone should be prepared to explain who granted it, why it was necessary, where that authority ends, and who will answer for what happens next.
References and Further Reading
Agentic AI Security, Governance, and Accountability
“AI Agent Security Cheat Sheet” | Publisher: OWASP Cheat Sheet Series | Author: OWASP Cheat Sheet Series Contributors | URL: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
“Artificial Intelligence Risk Management Framework (AI RMF 1.0)” | Publisher: National Institute of Standards and Technology | Author: Elham Tabassi | URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
“Four Security Principles for Agentic AI Systems” | Publisher: Amazon Web Services | Author: Mark Ryland, Riggs Goodman III, and Todd MacDermid | URL: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/
“Governing Agent Identities” | Publisher: Microsoft Learn | Author: Microsoft | URL: https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
AI Security Evaluations and Incident Learnings
“Anthropic Says Claude Hacked 3 Organizations During Cybersecurity Tests” | Publisher: WIRED | Author: WIRED | URL: https://www.wired.com/story/anthropic-says-claude-hacked-real-systems-during-cybersecurity-tests/
“OpenAI and Hugging Face Partner to Address Security Incident During Model Evaluation” | Publisher: OpenAI | Author: OpenAI | URL: https://openai.com/index/hugging-face-model-evaluation-security-incident/
Applications, Browsers, and Shadow AI
“Enterprise DLP Can't See What AI Is Doing With Your Data” | Publisher: Island | Author: Island Team | URL: https://www.island.io/article/enterprise-dlp-generative-ai
“The Enforcement Gap In Enterprise Generative AI Governance” | Publisher: Island | Author: Island Team | URL: https://www.island.io/article/generative-ai-governance-enforcement-gap
“Turn Blind Trust into Verified Control with Prompt Security for Agentic AI” | Publisher: SentinelOne | Author: SentinelOne | URL: https://www.sentinelone.com/blog/prompt-security-for-agentic-ai/
“What Is Shadow AI And Why Does It Pose A Security Risk To Organizations?” | Publisher: Island | Author: Island Team | URL: https://www.island.io/article/what-is-shadow-ai-why-its-a-risk-to-organizations
Data Protection, Discovery, and Tokenization
“Evolving Data Governance Practices in the Age of Generative AI” | Publisher: Cyrisma | Author: Cyrisma | URL: https://www.cyrisma.com/blog/good-data-governance-in-the-age-of-genai
“How Eliminating Stored Cardholder Data Enables PCI Scope Reduction” | Publisher: Rixon Technology | Author: Rixon Technology | URL: https://rixontechnology.com/2026/02/11/pci-scope-reduction/
Human Risk, Identity, and Oversight
“AI and Social Engineering: The New Threat Landscape” | Publisher: INFIMA Security | Author: INFIMA Security | URL: https://infimasec.com/resources/guides/ai-social-engineering
“The Identity Problem Hiding in AI Agent Deployments” | Publisher: CrowdStrike | Author: Atul Tulshibagwale | URL: https://www.crowdstrike.com/en-us/blog/the-identity-problem-hiding-in-ai-agent-deployments/
“The Invisible Workforce You Haven’t Secured” | Publisher: Cynet | Author: MacKenzie Brown | URL: https://www.cynet.com/blog/the-invisible-workforce-you-havent-secured/