Enterprise security still assumes human intent sits somewhere near the center of the system. A person opens the document, merges the code or pushes the change. A person decides whether something feels wrong. That assumption is starting to break.
AI agents are now wired into everyday enterprise workflows. They write code, update tickets, query databases, call APIs and manage cloud resources. In many cases, they are already inside the workflow, operating through service accounts, OAuth grants and API tokens designed for more predictable automation. The agent does not need to "break in" if it has already been invited.
Enterprises have seen what happens when organizations trust the path. SolarWinds [1], 3CX [2] and MOVEit [3] were not AI breaches, but they showed that trusted update mechanisms, signed applications and routine file-transfer workflows can all carry hostile content. Agentic AI adds a new actor to those same paths: one that can read, interpret and act on the artifacts moving through them.
An agent can behave exactly as designed and still create a serious security incident. It might process the wrong file, trust the wrong instruction, pass a poisoned artifact to the next system or call a tool it is technically allowed to use but should not be invoking in that context. All of this can happen while the logs show nothing more than a legitimate workload carrying out a legitimate task.
Zero Trust matters more than ever in the agentic era. Distrusting content by default is not a new idea, but the untrusted object is. It is no longer a user, a file, or a network request. It is everything that flows into the agent's context and out through the agent's actions.
The most dangerous agent in an enterprise may not look malicious. It may look helpful. An engineering team uses an agent to keep dependencies up to date. The agent checks a package, reads the release notes, updates the version, runs tests and prepares a deployment. Now put something hostile in the path.
The dependency includes a malicious post-install script, or the release notes contain a hidden instruction aimed at the agent rather than the human reader. Nothing in this scenario requires the agent to be malicious. It simply must move untrusted content through a trusted process.
Once an agent is authorized to consume content and act, the content itself becomes part of the control plane. OWASP's Top 10 for LLM Applications puts prompt injection, supply-chain vulnerabilities, improper output handling and excessive agency among the core risks [4].
The early examples are already here. Research into GitHub Copilot has shown how malicious issues or hidden pull request comments can influence assistant behavior and expose sensitive data [5][6]. EchoLeak (CVE-2025-32711) demonstrated a zero-click prompt-injection path in Microsoft 365 Copilot, where a crafted email could create a route for data disclosure without the user executing code [7]. A malicious instruction hidden in an email, web page or support ticket may not be executable code, but if an authorized agent reads it and changes behavior, the result is operationally equivalent.
The supply chain risk also includes what agents recommend. In 2024, Lasso Security found that multiple LLMs persistently hallucinated a Python package called huggingface-cli [8]. The package did not exist. Lasso registered the name on PyPI as a proof of concept and reported over 30,000 downloads in three months. The model's hallucination became the supply-chain vector.
Agentic workflows are rarely single-step processes. One agent calls a tool, which queries an API, which returns a file that another model summarizes before a separate system turns that summary into an action. Every handoff in that sequence is a place where trust can leak.
Even within a single agent, there are multiple trust boundaries. The model generates a response. The agent layer decides what to do with it: which tool to call, what parameters to pass. The harness or orchestration layer dispatches that action into the real world with access to credentials and execution environments. A prompt injection targets the model. A misconfigured tool definition targets the agent. A weak permission boundary in the harness turns a benign-looking action into an unsafe one. Treating "the agent" as a single unit of trust misses the layered attack surface.
In human workflows, ambiguity creates friction. Autonomous workflows do not naturally do that; ambiguity can simply become execution. That is why provenance matters: what created this artifact, which tool touched it and whether it has changed since the last step. Those questions must be answered while the workflow is running, not reconstructed after an incident occurs. Human oversight only helps if the person has enough context to see the poisoned input, the tool chain and the action being approved.
Zero Trust began as a response to the fading network perimeter: do not trust a request just because it comes from "inside." Verify it, limit it, and keep checking. That principle still holds, but agentic systems stretch it into places where many organizations have not yet applied it properly.
In an agentic workflow, content does not stay still. A PDF becomes a summary, the summary becomes a ticket, the ticket becomes a code change, the code change becomes a build and so on. By the end of that chain, the original object may be invisible, but its influence may still be present.
So, the control point must move. It cannot sit only at login, network access or endpoint execution; instead, it must sit around the artifact and the action. Is this file structurally valid? Has active content been removed or neutralized? Does this tool call appropriate for the task? Is the agent allowed to perform this action now, with this data, at this stage of the workflow?
The agent's authority also needs to become situational. Permissions must be scoped to the task, the tool, the data and the risk of the action. Access should expire, and tool use should be conditional. Monitoring alone is not enough, because by the time a dangerous action appears in a dashboard the agent may already have taken it. Some decisions need to be mediated before execution, not explained afterward.
The emerging agent toolchain makes that point sharper. In 2025, a malicious npm package called postmark-mcp presented itself as an MCP server for sending emails through Postmark but secretly copied email contents via a hidden BCC [9]. In 2026, OX Security reported what it characterized as systemic command-injection risk in MCP's STDIO handling, with multiple CVEs across AI tooling and MCP-related implementations [10]. Anthropic reportedly treated the behavior as expected protocol operation rather than a protocol flaw [11]. The tool-connection layer has become part of the trust boundary.
Most organizations have invested in identity governance, conditional access, network segmentation and cloud posture management. Those controls matter but do not close this gap. The identity layer can confirm an agent is who it claims to be, but it cannot tell you whether the PDF it just read is structurally safe.
Techniques like content disarm and reconstruction, structural validation, runtime permission scoping and provenance tracking already exist. At Glasswall, we have spent years building on the assumption that content cannot be trusted by default. That principle now applies directly to the artifacts moving through agentic workflows. The practical answer is to make agentic workflows policy-enforced by default: validate objects before agents consume them, constrain tools before agents invoke them and mediate high-impact actions before execution. The more authority we delegate, the more precise the trust boundary has to become.
The breach that forces this conversation into the boardroom will look ordinary. An authorized agent, using approved tools, processing a malicious artifact and passing the result into a trusted workflow. The identity was valid. The API call was allowed. The file came from a known source. Every system behaved as designed. The failure was the chain between them.
The agent is already inside the perimeter. The question now is what, if anything, it should trust.
References
.png)
George is an Applied AI Engineer at Glasswall, with a strong background in machine learning and software engineering. He has experience building end-to-end ML solutions and data-driven systems across the speech and cybersecurity domains. At Glasswall, George applies AI to complex engineering problems in file security and threat detection.
A tailored walkthrough of how Glasswall rebuilds files to a known-good state, removes hidden threats, and provides the intelligence you need to understand file risk.
What's in the demo
“
Beazley's security is paramount, and this integration has significantly reinforced our cybersecurity framework.
.png)