Summary
Surveys suggest that employees are creating and deploying AI agents faster than many IT departments can govern them. Visibility, permissions, lifecycle controls, endpoint management and access to sensitive data are emerging as central security challenges for enterprise AI.
AI agents are becoming operational actors, not just software features
Enterprise AI is moving beyond systems that wait for a person to click a button or enter a prompt. AI agents can read local files, call tools and application programming interfaces, and carry out tasks across multiple steps. They may be embedded in approved enterprise applications, or created by employees through informal workflows outside established procurement and review processes.
That shift changes the security object that organizations need to manage. The issue is no longer limited to whether a company has purchased a particular application or adopted a particular model. An agent can have a place in the environment, a set of credentials, access to internal data and the ability to take action. The resulting risk depends not only on what the software is, but also on what it is authorized to do and how it behaves over time.
Gartner forecasts that task-specific AI agents will be integrated into 40% of enterprise applications by the end of the year, compared with less than 5% previously. The forecast may not translate evenly across industries, but it captures the direction of travel: agents are moving from isolated experiments into business systems, while many of the controls designed for conventional software have not yet adapted.
Visibility is the first governance gap
A survey commissioned by Dataiku and conducted by The Harris Poll asked 685 CIOs across the United States, the United Kingdom, France, Germany, the United Arab Emirates, Japan, South Korea and Singapore about enterprise AI practices. It found that 81% of respondents lacked complete oversight of agents created by employees outside formal channels.
The result resembles the older “shadow IT” problem, but agents introduce a more active form of exposure. An unapproved application may sit unused until someone opens it. An agent may continuously monitor a workflow, retrieve information, invoke another service or perform a sequence of actions based on changing inputs. If an organization does not know where the agent is running, what credentials it uses or which data sources it can reach, it will struggle to assess whether its behavior meets internal policy or regulatory expectations.
The survey also points to a gap between tracking and understanding. Ninety percent of CIOs said they had complete tracking of all their agents, yet 72% said they could not consistently confirm whether those agents were delivering the business outcomes for which they were built. Monitoring that an agent is active is therefore not the same as knowing whether its decisions, outputs and downstream effects are appropriate.
Other findings reinforce the scale of the management challenge. Sixty-seven percent of respondents estimated that 51 or more agents were running in production. Eighty-three percent lacked standardized lifecycle management, and 60% lacked a central governance layer covering their applications, tools and IT environments. Only 21% had full, near-real-time visibility into AI costs by team or use case.
Endpoint management must evolve from inventory to behavior
Traditional endpoint management has focused on a relatively static question: which software is installed on a device? Automox’s survey found that 46% of organizations currently automate endpoint inventorying and monitoring. That leaves a substantial portion of the environment dependent on manual or incomplete visibility, even as agent-based software changes the meaning of an endpoint asset.
An agent is not merely a package installed on a laptop or server. It may read local content, access a credential store, connect to internal systems, call an external API or initiate a multistep workflow between formal reviews. The relevant questions therefore become behavioral: What permissions does the agent have? Which files and services can it reach? What actions has it taken? Can those actions be explained, stopped and reversed?
Vendor telemetry cited in the source material also indicates sharp growth in endpoint-based AI applications and enterprise AI agents. Those measurements are not a complete representation of the industry and should not be treated as universal adoption rates. They do, however, point in the same direction: agent activity is expanding across devices and workflows faster than many organizations are upgrading their control systems.
The most serious failure may not come from one agent making one mistake. A flawed configuration or an incorrect instruction on a single device might be investigated and corrected. The same decision distributed across a fleet can become a broader incident involving excessive permissions, data exposure or operational disruption. As Automox chief executive Justin Talerico argued in the source material, the difference is between correcting one error and managing a crisis created when that error is applied at scale.
Ownership and lifecycle controls remain unsettled
As the number of agents increases, organizations need processes covering creation, testing, approval, deployment, updating, suspension and retirement. The Dataiku survey found that 83% of CIOs lacked standardized lifecycle management. It also found that 47% had already decommissioned more than 20 agents during the year. Decommissioning is taking place, but the findings do not show that organizations have a consistent, auditable method for deciding when and how an agent should be removed.
Accountability is similarly divided. CIOs identified shared teams, central IT, data or AI teams, and security, risk and compliance functions as possible owners when an agent fails. A distributed model can work if responsibilities are explicit. Without a named system owner, permission owner, approval authority and incident-response path, however, a failure can create uncertainty at exactly the moment a rapid decision is needed.
Cost visibility is part of the same governance problem. An agent may repeatedly invoke models, tools and external services, with spending shaped by task frequency, context size and workflow design. If only a small minority of organizations can see AI costs in near real time by team or use case, they may have difficulty distinguishing approved productivity gains from inefficient, unintended or unauthorized activity. Cost controls are not a substitute for security controls, but they can provide another signal of abnormal operation.
Governance needs continuous control, not a one-time approval
A practical governance framework begins with a unified inventory. It should cover formally purchased agents, employee-built workflows, embedded capabilities and automation tools connected to corporate data or credentials. The inventory needs more than a product name and deployment location. It should record the owner, purpose, data sources, permissions, dependent services, operating environment, review date and conditions for suspension.
Permissions should then be limited to the minimum necessary for a defined task. The ability to read a category of data should not automatically imply the ability to modify, export or forward that data, or to call other systems. Access to sensitive records, external communications, code execution and bulk actions may require stronger approval, segmented credentials and human confirmation.
Monitoring also needs to cover outcomes, not only uptime. Organizations should be able to determine what an agent accessed, which tools it called, what consequential actions it took and whether those actions matched the intended workflow. High-impact operations may require rollback mechanisms, anomaly detection and a clear human takeover path. Predeployment testing should evaluate more than functional correctness; it should also examine privilege escalation, prompt injection, data leakage and the possibility that an error could spread across many systems.
Finally, governance must assign decisions to specific roles. Business teams understand the intended use case. IT teams manage platforms and endpoints. Security, risk and compliance teams focus on data, permissions and regulatory obligations. Those functions need a shared process defining who may create an agent, who approves production use, who monitors it, who can suspend it and who leads the response when it fails.
The enterprise adoption of AI agents is therefore not simply the addition of another productivity category. It introduces more active software participants into the identity, endpoint, data and access-control environment. Organizations that establish visibility, least-privilege access, lifecycle discipline and accountable oversight before deployment scales will be better positioned to capture automation benefits without allowing speed to become a new source of operational and security risk.
Source: link