Companies are giving AI agents access to databases, cloud infrastructure, internal documents and production systems faster than security teams can establish meaningful controls over what those agents do.
The problem isn't simply that artificial intelligence can make mistakes. It's that organizations are increasingly giving AI systems the authority to turn those mistakes into actions, often without fully understanding the consequences.
Peyton Kennedy, senior security researcher at Endor Labs, says the rush to automate business processes is exposing a fundamental weakness in enterprise AI security: Organizations are trusting agents, orchestration platforms and third-party providers to enforce boundaries that may not exist or may not work as expected.
In the latest episode of CYBR.SEC.CAST, hosted by Michael Farnum and Sam Van Ryder, Kennedy discussed how AI adoption is expanding the enterprise attack surface, why traditional security assumptions are breaking down and what organizations must do to regain control.
His central warning: Giving an AI agent access to a system means accepting the possibility that something else could eventually exercise that access.
Full episode and related article:
, and CYBR.SEC.Media
Bill Brenner
AI adoption is moving faster than security oversight
The pressure to adopt AI is enormous. Developers are using coding assistants to accelerate software development. Business teams are assembling automated workflows. Employees are experimenting with tools that promise to eliminate repetitive tasks.
Increasingly, those tools require little or no programming knowledge.
Kennedy pointed to no-code orchestration platforms that allow users to build powerful applications by dragging and dropping workflow components. The accessibility is a major advantage, but it also creates opportunities for employees to deploy systems with significant privileges without understanding the security implications.
A workflow that appears to do little more than process documents or automate routine business tasks may also have access to employee records, customer information, databases and other sensitive resources.
And the people building those workflows may assume the underlying platform has already taken care of security.
That assumption can be dangerous.
Kennedy described conversations with platform maintainers who argued that securing deployments was the customer's responsibility. Organizations deploying those platforms, meanwhile, may believe the vendor is responsible for enforcing the necessary protections.
The result is a familiar cybersecurity problem with much greater potential consequences: Everyone assumes someone else owns the risk.
The problem with trusting AI agents
Traditional applications generally operate within relatively predictable execution paths. AI agents introduce another layer of uncertainty because they can interpret information, choose actions and interact with tools in ways their operators may not anticipate.
That doesn't necessarily mean an agent is acting maliciously.
An agent might delete files, modify a codebase, access an unintended database or interact with another system while attempting to complete an otherwise legitimate task.
The distinction between malicious behavior and unintended behavior becomes less important when the consequences are the same.
Kennedy argues that organizations need to stop evaluating agents solely on whether they can perform their assigned tasks and start examining what happens when those tasks go wrong.
What systems can an agent access? What credentials does it possess? Can it interact with other environments? Can it execute commands? Can it move beyond its intended workspace?
These are familiar questions in traditional security architecture. But the speed of AI adoption is making them newly urgent.
Least privilege must apply to AI agents, too
One of Kennedy's strongest recommendations is also one of cybersecurity's oldest principles: least privilege.
AI agents should receive only the permissions required to perform their assigned functions.
That sounds straightforward until organizations begin connecting agents to cloud infrastructure, development environments, enterprise databases and other automated systems.
Kennedy warned that even granting an agent root access to a dedicated cloud instance may be excessive.
The concern isn't limited to the initial environment. If an agent can communicate with other systems or access additional credentials, a compromise or unintended action could extend far beyond its original assignment.
Security teams need to consider not only what an agent is supposed to do, but what it could do with everything it can reach.
Kennedy's advice goes further: Organizations should assume that privilege restrictions and isolation mechanisms might fail.
That means examining the consequences of a boundary failure before deploying the agent, rather than discovering them during an incident.
Prompt injection makes the trust problem worse
Kennedy's own research illustrates why these concerns aren't theoretical.
In research on AI orchestration platforms, he investigated how prompt injection and insecure execution mechanisms could be exploited to achieve remote code execution.
During CYBR.SEC.CAST, he explained that malicious instructions don't necessarily have to come from someone directly interacting with an AI assistant.
An agent may encounter those instructions in documents, repositories or other external information it processes as context.
That creates a dangerous trust relationship: An attacker who cannot directly access a protected system may still be able to influence an agent that already has legitimate access.
If the agent treats attacker-controlled information as instructions, it could perform actions its operator never intended.
The risk grows as organizations connect agents to more systems and give them increasingly broad authority.
Kennedy's separate research into a sandbox vulnerability in brig also demonstrates why organizations shouldn't assume isolation mechanisms are foolproof.
The larger lesson is that securing the model alone isn't enough. Organizations must secure the surrounding execution environment, the data entering the workflow and the systems the agent can reach.
Monitoring agents is becoming a security requirement
Limiting access is essential, but Kennedy argues that organizations also need visibility into what agents are actually doing.
That means monitoring the commands they execute, the resources they access and the actions they take across connected environments.
Security teams should be able to identify potentially destructive behavior and, where possible, block it before damage occurs.
The challenge is that AI agents may operate across multiple tools, systems and workflows, making it difficult to reconstruct their actions after something goes wrong.
Farnum raised another important consideration during the podcast: resilience.
If an agent deletes information, corrupts an environment or makes an unauthorized change, the organization needs to know what happened and be able to recover.
And if an agent interacts with systems outside the organization's environment, maintaining detailed records becomes even more important.
These are not entirely new security requirements. Logging, access controls, segmentation and incident recovery have been part of cybersecurity for decades.
What has changed is the speed and autonomy with which AI systems can exercise their permissions.
Security cannot become the department of no
Kennedy isn't arguing that organizations should stop experimenting with AI.
In fact, he sees continued learning and experimentation as essential to helping security teams understand emerging threats.
The answer, he argues, is to equip security professionals with the tools, knowledge and authority to evaluate AI deployments before those systems become deeply embedded in business operations.
That includes threat modeling new applications, examining how data is stored and processed, identifying unnecessary privileges and challenging assumptions about what third-party platforms are securing.
It also requires security teams to communicate risks in terms that developers and business users understand.
An employee assembling a no-code workflow may not understand the technical details of remote code execution. But that employee can understand the consequences of exposing customer information, losing access to business systems or allowing an unauthorized party to control a computer.
Kennedy's point is that security teams must bridge that gap rather than simply reject new technology.
The real AI security problem is unchecked authority
The industry has spent years promoting zero trust, least privilege and assume-breach architectures. AI agents are testing how seriously organizations have embraced those principles.
An agent with excessive permissions is still an overprivileged identity. A workflow that trusts unverified external content is still exposing a trust boundary. A system that cannot explain what its agents did still has a visibility problem.
AI makes those failures more difficult to manage because a single agent can interpret instructions, make decisions and execute actions across multiple connected systems.
The technology may be new, but the underlying security failures are painfully familiar.
Organizations don't need to eliminate every possible AI mistake before deploying agents. They need to make sure those mistakes cannot automatically become enterprise-wide incidents.
The question security leaders should be asking isn't simply whether an AI agent can do the job.
It's how much damage that agent could do if something goes wrong.
![[un]prompted II: Full Coverage](https://storage.ghost.io/c/ab/67/ab676516-71e3-473d-8f73-9e0692f5aaee/content/images/size/w1304/format/webp/2026/10/20db4c11-e6e0-4989-9cf5-9b6e767a8f5f.png)
