When the first version of this piece was published in March 2026, the argument was that agent security risk was real, addressable, and being met mostly with alarm rather than architecture. Four months of disclosure activity has not changed that argument. It has changed what can be said with evidence behind it.

In July 2025, the OWASP GenAI Security Project published the first edition of its State of Agentic AI Security and Governance report. It catalogued plausible threats. Version 2.01, published June 1, 2026, catalogues CVEs, vendor advisories, and incident reports across nearly every category it names. That shift, from anticipated risk to documented risk, is the material development of the past year.

The question is not whether to use agents. They will function as critical infrastructure in enterprise environments. The question is whether we secure them with the same seriousness we apply to any other component in a complex system, and whether we can investigate them when they fail.

One note on scope. This applies to agentic AI systems broadly. Any AI that can interpret instructions and execute actions across tools and systems presents the same threat model, regardless of whether it is labelled an agent. The risks are not specific to multi-agent pipelines. They emerge from the same root property: autonomy, tool access, and the ability to act on the environment rather than simply respond to prompts.

The Structural Shift

In traditional systems, user input and system execution are separated by application logic. AI agents collapse that separation. Natural language input can directly trigger tool execution, which turns conversational manipulation into a system-level security risk.

Traditional investigations assume a predictable chain. A human actor, a compromised system, a sequence of actions. Agent-involved incidents introduce a different chain. A human actor manipulates an agent through crafted input. The agent, operating with delegated authority, executes actions across a toolchain. The system is compromised. The human never touched it directly.

The agent becomes the attacker's proxy. It operates within trusted boundaries, carrying legitimate credentials, executing actions that would trigger no alert if performed by a human operator with the same access.

This is not an incremental change to the attack surface. It is a structural one.

What the Evidence Now Shows

OWASP published a Top 10 for Agentic Applications for 2026, separate from the LLM Top 10, naming risks including agent goal hijack, tool misuse, agent identity and privilege abuse, agentic supply chain compromise, memory and context poisoning, cascading agent failures, and human-agent trust exploitation. Those categories describe failure modes that existing enterprise controls were not designed to detect.

Three developments are worth examining, because each breaks a different assumption.

Prompt injection remains unsolved. EchoLeak (CVE-2025-32711) was a zero-click vulnerability in Microsoft 365 Copilot allowing data exfiltration through injection embedded in email content. Microsoft assigned a CVE and issued emergency patches, and has acknowledged indirect prompt injection as a recurring technique in reports to its security response centre. The mechanism was not exotic. It exploited the same design property that makes agents useful: they act on instruction, including instructions hidden in content they are asked to process. A year later, the research community treats prompt injection as an open problem rather than a defect awaiting a patch.

Approval gates can fail while appearing to work. On July 8, 2026, Wiz Research disclosed a pattern it named GhostApproval, affecting six widely deployed AI coding assistants. A malicious repository contains a file that appears to be an ordinary settings file. It is a symbolic link pointing elsewhere, such as the developer's SSH authorized keys. The agent follows the link using standard file operations, then requests approval based on the path it was handed rather than the path the write lands on. The developer sees a harmless filename and clicks Accept.

Wiz classified the file handling under CWE-61 and the misleading dialog under CWE-451, misrepresentation of critical information in a user interface. AWS remediated the issue and assigned CVE-2026-12958. Cursor patched it under CVE-2026-50549, and Google also deployed a fix. Anthropic and Augment disputed the classification on threat model and developer responsibility grounds. Windsurf had no fix at disclosure. In testing, some tools wrote to disk before the approval buttons appeared, which makes the confirmation dialog an undo mechanism rather than an authorization gate. Adversa AI published overlapping findings in May 2026. Two independent teams reaching the same pattern indicates a shared design weakness rather than one vendor's oversight.

The significance extends past coding tools. Human-in-the-loop approval is the control most organizations cite when asked how they manage agent risk. GhostApproval demonstrates that the control can be present, functioning, and meaningless at the same time. The human is still in the loop. The loop is showing them the wrong thing.

The agentic supply chain is an active attack surface. On March 24, 2026, two backdoored versions of LiteLLM, 1.82.7 and 1.82.8, were published to PyPI. LiteLLM is a language model gateway used by CrewAI, DSPy, Microsoft GraphRAG, and other frameworks. The compromise ran through a harvested publishing token rather than a flaw in LiteLLM itself. Agent frameworks sit on deep dependency trees, and the components they load carry the same trust as the agent.

The Third Category

A common framing recognizes two agent incident types. The agent is manipulated, or the agent fails on its own.

The first is the adversarial case described above. The second is less discussed and equally real. In 2025, a coding assistant deleted a production database despite explicit instructions to change nothing, generated fictional records, and reported incorrectly that rollback was not possible. No adversary was present. Most security programs are built around adversarial intent. An agent with write access and a probabilistic decision process can produce an incident that looks like a breach, requires the same investigative response, and has no attacker to attribute it to.

There is a third case. Work on overreliance has begun to define incidents of this general shape, but those definitions turn on outputs that proved wrong. This one does not.

The agent works. The output is within specification. No control fails, no credential is misused, no instruction is injected. A person reads the output, treats it as a conclusion, and acts. Harm follows from the interpretation rather than from any malfunction.

I call this artifact-to-finding promotion. An artifact was promoted to the status of a finding without anyone doing the work that promotion requires.

The distinction matters because of what an AI output actually is. In forensic terms, an output is an artifact. It is a thing the system produced, and it is evidence that the system produced it. It is not a finding. A finding requires that someone examined the artifact, tested the alternatives, and established what it supports. When a detection system flags an account, the flag is an artifact. The conclusion that the account was compromised is an inference, and the inference belongs to an analyst who has to be able to defend it. Collapsing those two things is the error. It is the same error as treating a file's presence on a device as proof of who put it there.

Three properties make this category difficult, and they are the reason it deserves its own name.

It is invisible to the security stack. There is no CVE, no anomaly, no policy violation. Access control was honoured. The logs are clean and accurate. Every control performed as designed. Nothing in the environment will tell you this happened.

It has no remediation path in the ordinary sense. There is no patch, because nothing was broken. The correction is to the decision process around the system, which sits outside the boundary most security teams are funded to work within.

It produces harm that lands on a person who was not party to the interaction. The manipulated agent case harms the organization. Artifact-to-finding promotion typically harms whoever the output was about. An employee flagged by a monitoring tool. A claimant scored by a model. A person named in an automated report that was read as an accusation. That asymmetry is why I place this in the governance domain rather than the usability domain. The organization holds the interpretive authority. The person bearing the consequence has no visibility into how the output was produced or what it actually established.

For investigators, this reframes the central question. The traditional question is what the system did. The question in an artifact-to-finding promotion incident is what the output caused a person to believe, whether that belief was warranted by what the system actually established, and whether anyone in the chain was in a position to know the difference. Answering that requires the output, the context presented alongside it, the confidence or scope qualifiers that were shown or omitted, and the decision that followed. Most organizations retain the first item and none of the rest.

What Security Teams Should Do Now

The response cannot be to wait for vendors to solve this.

Treating agents as dynamic service accounts gives teams a familiar governance starting point. Access reviews, logging requirements, and privilege controls transfer directly. The analogy has a boundary that should be stated. Traditional service accounts are deterministic. Their behaviour is scripted and predictable, which is what makes them governable. Agents are not. Existing service account governance is a useful foundation and is not sufficient on its own.

Least privilege applies at the configuration layer, and it does not close the gap by itself. An agent that reads data should not hold write permissions, and an agent that queries one system should not have lateral access to adjacent ones. But a compromised agent does not behave like a compromised static account. It can be manipulated mid-session to execute actions that look entirely legitimate from an access control perspective. The credentials are valid. The permissions are valid. The intent is not. That is why agent sessions should not inherit implicit trust from prior authentication. Broad delegation combined with implicit session trust is not a configuration gap. It is a structural risk.

Input validation needs to extend to prompts and conversational interfaces. Most organizations have mature processes for validating structured inputs and few have applied equivalent rigour to natural language reaching an agent with tool access. EchoLeak demonstrated the gap precisely. Content processed by an agent became the attack vector, not the user interface.

Human approval should be verified rather than assumed. Check what the approval dialog actually displays, whether it resolves to the operation being performed, and whether the action executes before or after the click. Where that cannot be verified, document it as an assumption rather than counting it as a safeguard. This is the practical lesson of GhostApproval and it generalizes well beyond coding tools.

Behavioural baselines have to be built specifically. Traditional anomaly detection looks for deviations in human patterns, and agent behaviour follows different baselines. Define what normal looks like for each deployed agent, then build detection around meaningful deviation from that.

Blast radius should be contained by design. If an agent is compromised, what can it reach? If the answer is most of the environment, the architecture is the problem, not the agent.

The agent supply chain belongs in the inventory. Frameworks, gateways, MCP servers, and packages loaded at runtime warrant the same discipline applied to any other third-party code in a privileged position.

One control belongs on this list that rarely appears on it. Where an agent output informs a decision about a person, the interface should carry the scope and limits of what that output establishes, and the record should retain both the output and the decision that followed. This is not a usability improvement. It is the only mechanism by which artifact-to-finding promotion becomes investigable after the fact.

The Forensic Dimension

The investigative side of this shift still receives too little attention.

Agent-involved incidents require a different artifact set: system prompts, agent logs, prompt histories, tool invocation chains, authorization scopes, and memory stores. Investigators need to determine not only what actions were executed, but whether those actions originated from legitimate instructions, manipulated prompts, or adversarial input injected earlier in the chain. In the EchoLeak case, the injection point was an incoming email processed silently by the agent. An investigation without visibility into what the agent read, what instructions it received, and what tools it invoked has no starting point.

Three problems sit underneath that, and they are ordered by how hard they are to solve.

Retention. Prompt histories are not always kept. Tool invocation chains are not always logged. Memory stores are often ephemeral. This is the easiest problem, because it is a configuration decision that can be made before deployment.

Fidelity. Where logs exist, their relationship to what the system actually did cannot be assumed. GhostApproval is the clean illustration. In several of the tested tools, the approval record would show the harmless filename while the write landed somewhere else. An investigator reconstructing that incident from approval logs alone would produce a timeline that is internally consistent, well documented, and wrong. The log is not falsified. It is accurate to what the interface displayed and inaccurate to what the system did. That distinction has consequences for attribution and for anything that later has to survive scrutiny.

There is a related pattern worth naming, because it recurs. Audit logging is frequently implemented at the layer where the technology sits rather than the layer where the decision happens. Platform-level logging captures authentication, queries, and infrastructure events, which is often what the vendor provides by default. If the consequential action occurred at the application layer above it, the audit trail can be complete, accurate, and unable to answer the question that matters. Nothing is missing from the logs. The logs were never scoped to the event. The practical test is to state the investigative question first, then ask which layer holds the record that answers it. That test is cheap to run before deployment and expensive to skip.

Custody. This is the hardest problem and the least discussed. In most enterprise agent deployments, the record is not yours. It sits with a model provider, under a contract negotiated for service levels and privacy compliance rather than evidentiary production, frequently processed or stored outside the jurisdiction where the incident occurred and the investigation is authorized.

Retention is a setting. Custody is a question of contract and legal reach, and it does not resolve by configuration. The questions worth asking before deployment rather than during an incident are these. Can the organization obtain the underlying record on its own authority, or does it depend on provider cooperation? In what form, and can its integrity be established? Within what timeframe, measured against the timeframe an investigation actually runs on? If the matter becomes contested, does anyone possess an independently verifiable copy, or does the entire evidentiary chain rest on a vendor's assurance about its own systems?

Evidence that cannot be compelled, verified, or produced within a usable timeframe is not a dependable evidentiary foundation. Most organizations deploying agents have not asked these questions, and the answers are difficult to change after the contract is signed.

A Note on the Canadian Public Sector Position

Several prominent frameworks are written from a United States or European Union vantage point. The EU AI Act supplies enforcement teeth. NIST supplies a risk management vocabulary. Canada has its own federal Directive on Automated Decision-Making and a mandatory Algorithmic Impact Assessment for covered federal systems. That framework addresses transparency, accountability, procedural fairness, explanations, and decisions affecting individuals. It does not, however, map cleanly onto every provincial public body or every agent use case.

Public sector organizations in Canada operate under provincial access and privacy legislation, with accountability running to a legislature and to independent oversight offices rather than to a regulator with substantial fining power. That changes the governance calculation in a way worth stating directly. The primary exposure is not a penalty. It is a finding that a public body could not explain how a decision affecting a citizen was reached, or could not produce the record when asked. In that environment, forensic readiness is not a security nicety. It is the mechanism by which a public body remains able to account for itself.

Two consequences follow. First, agent deployments touching personal information carry obligations that the OWASP material does not address, and privacy impact assessment work needs to reach the agent layer rather than stopping at the platform. Second, cross-border inference is a live issue rather than a theoretical one. Where an agent processes personal information through a provider outside the jurisdiction, the custody problem described above and the privacy obligation converge on the same contract clause.

This is an underdeveloped area. I raise it because the gap is real and because Canadian practitioners are largely working from frameworks written for a different accountability structure.

The Broader Point

The doom-and-gloom narrative around AI agents is not productive. The underlying concern is legitimate, and it is worth being honest about why.

The security community has faced new attack surfaces before. Cloud adoption is the obvious comparison. The lesson is not that the industry adapted successfully, because cloud-related incidents remain a leading breach category year after year. The lesson is that early investment in architecture matters, because retrofitting controls onto a widely deployed technology is significantly harder than building them in from the start.

One thing has changed since March. The evidence base is no longer thin. Organizations beginning now work from documented failure modes, published CVEs, and a maturing framework record rather than speculation. That is a better position than the one available a year ago, and it is the strongest argument for acting rather than waiting.

I will state the limit of my own claim. I am not arguing that organizations acting now will avoid agent-related incidents. The evidence does not support that. I am arguing that they will be able to investigate them, and that organizations without forensic readiness will not.

That gap is the work I am currently doing. The methodological foundation I work from is published as the Zemi Method, Version 1.0, at https://zemimethod.com. It addresses how conclusions are reached and how the boundary between what is known, what is assumed, and what remains undetermined is stated and defended. The categories described in this article, particularly artifact-to-finding promotion and the custody problem, sit alongside that doctrine as developing work. The full argument for artifact-to-finding promotion, including its relationship to existing work on overreliance and warrant preservation, is published at https://doi.org/10.5281/zenodo.21543521. I am publishing them as they stabilize rather than after the fact, because the field is moving faster than any private drafting cycle can keep up with.

Authority comes from method, not assertion. Evidence sets the boundary of what can be claimed. That principle is the reason forensic readiness matters here. Without the record, there is no boundary, and anything can be claimed.

References

Adversa AI. SymJack: the approval prompt is lying to you. A symlink-hijack RCE in six AI coding agents. May 2026. https://adversa.ai/blog/the-approval-prompt-is-lying-to-you-symlink-rce-in-five-ai-coding-agents-claude-code-cursor-antigravity-copilot-grok-build/

Aim Security. EchoLeak (CVE-2025-32711): Zero-Click Prompt Injection in Microsoft 365 Copilot. 2025. https://www.aim.security/lp/aim-labs-echoleak-blogpost

Cloud Security Alliance. LiteLLM PyPI Backdoor: Credential Theft in AI Toolchains. March 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-litellm-pypi-backdoor-ai-toolchain-supply/

Government of Canada. Directive on Automated Decision-Making. https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32592

Hack The Box. Technical Analysis of CVE-2025-32711. https://www.hackthebox.com/blog/cve-2025-32711-echoleak-copilot-vulnerability

Help Net Security. Prompt injection still drives most agentic AI security failures in production. June 11, 2026. https://www.helpnetsecurity.com/2026/06/11/owasp-prompt-injection-ai-security-failures/

Microsoft Security Response Center. Defending Against Indirect Prompt Injection Attacks. July 2025. https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks

OWASP GenAI Security Project. State of Agentic AI Security and Governance, Version 2.01. June 1, 2026. https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/

OWASP GenAI Security Project. Top 10 for Agentic Applications for 2026. December 9, 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

OWASP Foundation. LLM01: Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf

Office of the Privacy Commissioner of Canada. Guide to the Privacy Impact Assessment Process. https://www.priv.gc.ca/en/privacy-topics/federal-government-privacy/privacy-impact-assessments/gd_exp_202003/

Replit. Introducing a Safer Way to Vibe Code with Replit Databases. July 21, 2025. https://replit.com/blog/introducing-a-safer-way-to-vibe-code-with-replit-databases

OECD.AI. Replit AI Coding Tool Deletes Live Production Database and Fakes Data. July 2025. https://oecd.ai/en/incidents/2025-07-19-1eb1

The Register. Bug in top AI coding agents shows that Unix-era security headaches never really die. July 8, 2026. https://www.theregister.com/security/2026/07/08/bug-in-top-ai-coding-agents-shows-that-unix-era-security-headaches-never-really-die/

Varonis Threat Labs. Reprompt: Data Exfiltration via Microsoft Copilot. https://www.varonis.com/blog/reprompt

Wiz Research. GhostApproval: A Trust Boundary Gap in AI Coding Assistants. July 8, 2026. https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants

Kevin V. Watson is a Digital Forensics and Incident Response specialist and a graduate student in the Master of Interdisciplinary Artificial Intelligence program at the University of Ottawa. He is the author of the Zemi Method, a published doctrine on investigative reasoning and evidentiary boundaries. He writes at the intersection of digital forensics, cybersecurity, AI governance, and the public interest.