Security teams spent decades controlling what software does; Agentic AI is forcing them to control what it decides to do next — and that starts with knowing it's there at all.
The other day, a friend and former coworker told me she needed to build a drip email campaign targeting their company’s entry-level customer base after her team identified a cross-sell opportunity. She needed to identify which customers were likely fits for the related product, pull the matching accounts from Salesforce, organize them in a dynamic spreadsheet, draft a cross-sell email for each one, and log it all back into Salesforce so the reps could review, send, and follow up—and then make the whole thing repeatable for the next campaign.
So, she used her personal Claude Pro account to build an agent that would automate these processes into a multistep workflow. And she did so by describing what she wanted in plain English.
Agentic AI Poses a New Threat
The most obvious security issue is the shadow AI one: under pressure to get this up and running, she built her agent outside her organization’s approved AI tools and fed it confidential customer data.
And I can’t blame her. She had a deadline and leveraged a tool that worked.
But even if she had built a comparable agent using ChatGPT Enterprise, security practitioners face a problem that goes beyond which application built the agent: How do you control what the agent decides to do? Unlike a traditional application, an AI agent can get to its goal more than one way. If direct export of the customer data is blocked, the agent keeps trying—a shared drive, an API call—until it finds a way.
And who approved this agent? No one. No interview, no access review, no manager. Worse, there’s a good chance you won’t even know it exists.
That last claim isn’t me being dramatic. In a survey the Cloud Security Alliance published last spring titled Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises, 82% of organizations said they’d discovered AI agents running in their environments that IT or security teams didn’t know existed.
AI agents—they’re just like us! And that’s the security problem.
Traditional applications, no matter how complex, execute a fixed sequence. If a given step fails, the application breaks down. To get it working again, you need a capable, intentional actor—a human being, if you will.
But AI agents work more like the proverbial intern eager to prove their value, exhausting all avenues if necessary to achieve an objective. If the task is drafting a first-pass summary of last week’s support tickets, this persistence is harmless for the most part. But once the task involves downloading a file, executing a script, or installing something the agent decides it needs to finish the job, that same persistence is exactly what burns you.
More troubling: you usually can’t see how an agent gets from point A to point B (and beyond). Without that visibility, you can’t easily determine whether it’s broken a security protocol along the way. That’s what makes an agent more like an employee than an application: it makes judgment calls. Except this employee skipped the interview, the background check, and the security training.
An unmonitored agent puts your organization at risk twice over.
-
There’s the insider-style risk: an agent with legitimate access doing things no one authorized, like our cross-sell agent hunting for a workaround to a blocked export. Then there’s the external one: attackers now target AI tools and agents directly, and a compromised agent inherits every blind spot you’ve left around it.
-
That second risk runs on a clock. CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time—the time from initial access to lateral movement—at 29 minutes. The fastest breakout on record clocked in at 27 seconds. In one documented intrusion, data exfiltration began within four minutes of initial access.
You can’t respond in 29 minutes—let alone 27 seconds—to activity you can’t see. And agent activity is exactly what most organizations can’t see.
The Workforce Nobody Hired (but Attackers Love)
Attackers have noticed. The CrowdStrike report shows that AI-enabled adversary activity rose 89% year over year in 2025. Attackers are using AI across the whole lifecycle—recon, credential theft, evasion—while hiding behind legitimate identities and SaaS platforms. The result: intrusions that move faster, look more like routine activity, and leave defenders with less time to respond.
AI itself has become a target, too. At more than 90 organizations, attackers manipulated legitimate generative AI tools with malicious prompts that produced working commands for credential and cryptocurrency theft. They exploited weaknesses in AI development platforms to maintain access and deploy ransomware. They stood up malicious AI servers masquerading as trusted services to intercept sensitive data. Prompts, models, plugins, agent infrastructure—all of it can be turned against you.
Which brings us back to my friend’s cross-sell agent. Shadow agents emerge inside the same automation, scripting, LLM, and custom-assistant environments your teams already use to get work done, so their activity looks legitimate even when an agent is unauthorized, compromised, or acting beyond its intended scope. From the outside, an agent doing its job and an agent doing an attacker’s job can look remarkably alike.
So, treat your agents like the employees they resemble. You’d never let a new hire touch customer data before anyone checked their references, scoped their system access, or at minimum learned their name. Agents deserve the same scrutiny: know which ones are running, what tools and data they can reach, what actions they’re taking, and whether those actions comply with policy. You can’t govern a workforce you haven’t met.
Preparing for a Secure Future with Agentic AI
AI agents are becoming part of the enterprise workforce, whether security teams approve them or not. The first step toward governing them is knowing they're there. Watch our on-demand webinar Redefining Application Control for a Post AI World, featuring Paddy Harrington, Senior Analyst, Security and Risk at Forrester to learn more.
Agentic AI Control & Governance FAQs
This ability to carry out multi-step work can improve speed and productivity, but it also creates new security and governance requirements. Organizations need visibility into which agents are operating, clear boundaries around what they may do, controls over what they can execute, and ongoing monitoring of their activity.
An AI agent is an autonomous software entity or workflow that pursues an objective, selects and sequences actions, invokes tools, and may adapt or replan when an action is blocked or fails.
The distinction matters because an organization may trust an Agentic AI application while still needing to govern the individual agents operating through it.
This means blocking one command or execution path may not prevent an agent from reaching the same outcome through another route. An agent may also access files, execute commands, connect to services, or interact with business systems on a user’s behalf. As its capabilities and access expand, so does the potential impact of misuse, compromise, or unintended behavior.
Securing AI agents therefore requires controls that account for their objectives, behavior, resources, execution paths, and operating context—not only the application through which they run.
Different agents operating through the same application may have different objectives, permissions, tools, and levels of access. A user may also create an agent or workflow that exceeds the boundaries originally considered when the application was approved.
Organizations must therefore govern both levels: which Agentic AI applications are permitted and what the agents operating through them are allowed to do. Approval should be treated as conditional trust, with boundaries applied to individual agent behavior and execution.
It often emerges when employees or teams adopt new capabilities faster than procurement, IT, and security teams can evaluate them. Shadow AI does not necessarily indicate malicious intent. Instead, it may reflect a legitimate business need that existing processes or approved tools are not meeting.
The security concern is that organizations may not know which agents are operating, who is responsible for them, what data or systems they can access, or what actions they can perform. Without that visibility, security teams cannot make informed decisions about approval, permissions, restrictions, or risk.
Organizations need to look beyond their list of approved AI applications. Agents may be introduced through formal procurement, embedded within existing software, installed by individual users, or created by teams to address a specific need.
A useful discovery baseline should establish:
- which AI applications and agents are in use
- who uses, owns, or is responsible for them
- what business need each agent supports
- what activities the agent performs.
Understanding activity is particularly important. Knowing that an agent exists does not reveal whether it can read sensitive data, modify files, access credentials, invoke tools, execute commands, or interact with other systems.
The initial goal is not to investigate every action in depth. It is to create enough visibility and context to identify unmanaged use, prioritize risk, and make sound governance decisions.
Behavioral governance defines the agent’s permitted operating space. Policies may account for the agent’s business purpose, the user or service on whose behalf it acts, the commands it issues, the resources it accesses, and the environment in which the activity occurs. They should also establish which actions are prohibited and which require additional authorization or human approval.
Execution restrictions control the applications, scripts, interpreters, utilities, processes, and other executable components an agent can use to carry out its work. This is important because agents may chain together existing tools—such as command shells, browsers, package managers, PowerShell, or Python—to find alternate ways to complete a task.
Together, these controls limit both what an agent is permitted to do and the execution paths available for doing it.
Execution policies should be tested before enforcement and introduced in stages. Employees also need clear processes for requesting access, obtaining exceptions, and proposing additional tools when an approved option does not meet a valid need.
Monitoring then provides evidence about whether the controls are working. Security teams can review the commands agents issue, the resources they access, the files they touch, and the policy decisions their activity triggers. That evidence can reveal both risky behavior and legitimate workflows that were not fully understood when the policy was created.
The objective is not to eliminate Agentic AI autonomy. It is to keep that autonomy within boundaries the organization can define, enforce, review, and refine as agent use evolves.