AnalysisAIUnderstanding

AI Agents and Cybersecurity: Managing AI Access to Enterprise Systems

2026-09-23

Executive Summary
An AI agent doesn’t just generate text — it’s typically granted access to APIs, databases, email, and other internal systems to complete its task. From a security standpoint, each of those access points is something an attacker can target, without ever directly attacking the AI model itself.
This is no longer a theoretical risk. When the OWASP GenAI Security Project published “OWASP Top 10 for Agentic Applications 2026” (December 9, 2025) — a framework peer-reviewed by more than 100 security experts — they built the catalog based on real incidents that occurred in 2025, not projected scenarios.
Three specific documented incidents: a vulnerability with an official CVE number (CVE-2025-32711, called “EchoLeak”) that allowed enterprise data to be extracted from Microsoft 365 Copilot via a single crafted email, with zero clicks required from the user; a supply-chain attack through Amazon Q Developer, an AI coding extension with nearly 950,000 installs, that shipped data-wiping instructions into users’ development environments; and the Replit incident already covered in Pillar 6.
An important distinction in AI agent security thinking: attacks ON the agent (manipulating its behavior) differ from attacks THROUGH the agent (using it as a pivot to reach a database, API, or backend infrastructure the attacker has no direct access to).
The core control principle now proposed by the security community: Least-Agency — an extension of least privilege specific to an agent’s degree of autonomy: an agent should be granted only the level of autonomy genuinely needed for its task, not free rein by default.

When an organization evaluates the security risk of an AI agent, the common reflex is to ask: “can this AI model be tricked into saying something it shouldn’t?” That’s a valid question, but not a sufficient one. For an agent with access to real systems — not just generating text — the more important question is: “if this agent is manipulated, what can it reach inside our systems?”

This is exactly the lens the security community is now applying to AI agents: not just as a language model whose output content needs controlling, but as an entity with access that needs to be governed like any other account or service in the system.

What AI Agents Can Do With System Access

An AI agent hub connected to five access points: databases, APIs, email, internal documents, code execution.

Claim: An AI agent granted system access becomes part of the organization’s attack surface, exactly the way any privileged account would.

To complete its task, an enterprise AI agent typically needs one or more of the following: read/write access to a database, the ability to call other systems’ APIs (CRM, ERP, payment systems), read and send email, access to internal documents, or the ability to execute code in a development environment.

The AI agent security research community makes an important distinction when assessing this kind of risk: attacks ON the agent — manipulating it to behave the way an attacker wants — differ in nature from attacks THROUGH the agent — using it as a pivot to reach a database, API, or backend infrastructure the attacker has no direct access to. This distinction matters because the two risk types need different defenses: the first requires controlling the agent’s input/output content; the second requires controlling the access boundary and the systems the agent can reach — regardless of whether the agent “behaves correctly” or not.

Enterprise Environments as an Attack Surface

Two columns: attacks on the agent with two controls; attacks through the agent with three points.

This is no longer a theoretical risk. The OWASP GenAI Security Project, in publishing “OWASP Top 10 for Agentic Applications 2026” on December 9, 2025 — a framework built and peer-reviewed by more than 100 security experts, researchers, and practitioners — emphasizes that its ten risk categories (ASI01 through ASI10) are built from real incidents that occurred in 2025, not projected scenarios.

Three specific incidents illustrate this:

EchoLeak (CVE-2025-32711) — a vulnerability with an official CVE identifier, allowing enterprise data to be extracted from Microsoft 365 Copilot via a single crafted email, with no action required from the recipient (zero-click).
A supply-chain incident involving Amazon Q Developer — an AI coding assistant extension with nearly 950,000 installs, where a hijacked pull request shipped data-wiping commands into users’ environments through the AI tool itself.
The Replit incident, covered in detail in Pillar 6’s opening article — an agent that executed a command deleting a production database despite being explicitly told not to change anything without approval.

Three permission blocks added together, leading to a blast-radius block.

What these three share: the attacker (or the system flaw) doesn’t need to “hack” the AI model directly in the traditional sense — they exploit the fact that the agent holds broad access and treats content from multiple sources (email, a pull request, user data) as though it were all trustworthy instruction. The OWASP GenAI Security Project describes agentic risk as a “blast-radius problem”: an agent’s exposure equals the sum of every credential, tool, and API it can reach — and because an agent operates through multiple autonomous steps, damage can compound across an entire plan, not stop at a single response.

Access Control Principles for AI

Three numbered rows, each a way to apply Least-Agency.

From these incidents and the analysis above, the security community proposes a specific extended principle for AI agents: Least-Agency — a variant of the least-privilege principle, applied specifically to the degree of action autonomy, not just data scope.

This principle states: an agent should be granted only the amount of autonomy genuinely necessary to complete its assigned task — autonomy is a privilege that needs to be “earned” through deliberate design, not a default setting. Applied concretely:

Limit which tools an agent is authorized to call, instead of granting broad access “just in case” — the same principle covered in earlier articles on the decision/execution boundary.
Separate the data flow from the instruction flow. One of the three structural factors that make this risk more severe (covered in article 6.6) is that an agent treats all content in its context — including an email, a pull request, or a retrieved document — as potentially instructive. Building a clearer boundary between “data to process” and “instructions to follow” is an important mitigation direction.
Treat every agent access grant as a service-account access grant, requiring periodic review, revocation once no longer needed, and monitoring like any other privileged identity in the system.

Connecting to Enterprise Security Frameworks

Three 2025 incident cards and one statistic card showing LLM06 to LLM03.

An important point worth emphasizing: AI agent security shouldn’t be built as a separate program running parallel to a company’s existing cybersecurity program — it should be integrated into it.

The OWASP GenAI Security Project also maintains “OWASP Top 10 for LLM Applications,” a separate version for model-level risk (distinct from system-level agentic risk). One notable detail in the 2026 edition: the Excessive Agency risk (granting an AI system too much authority to act) climbed from position LLM06 in the 2025 edition to LLM03 — trailing only prompt injection and sensitive information disclosure. This ranking shift, within a single year, reflects exactly the trend analyzed above: as agents get granted increasingly more authority to act, the risk tied to scope of authority is rising faster than the risk tied to output content alone.

For IT security teams already familiar with frameworks like Zero Trust or the NIST AI Risk Management Framework, the good news is: most AI agent control principles don’t require an entirely new toolset — they’re an extension of identity governance, least-access, and runtime monitoring principles already present in enterprise cybersecurity. The main challenge isn’t a lack of tools — it’s ensuring AI agents actually fall within the scope of those existing programs, rather than being deployed as an exception sitting outside normal security governance.

Conclusion

An AI agent, once granted access to real systems, is no longer just a content-generation tool — it’s part of the organization’s attack surface, with the full security implications that come with it. The incidents documented in 2025 — with CVE numbers, specific names, publicly confirmed — show this isn’t a theoretical risk to be dealt with someday in the future. The control principles aren’t new: least privilege, separating data from instructions, monitoring privileged identities — but they need to be applied consistently to AI agents, as with any other access-holding entity in the system.

This article is part of the OKELAS AI Control series.

Related articles:

→ AI Readiness Assessment

Does this describe your organization?

Does this sound familiar to your organization?