← All articles
Agentic AI

Agent Security Is Being Patched, Not Solved

Vishal Sharma·July 19, 2026·8 min read

In three weeks: a GitHub agent tricked into publishing private repositories by an unauthenticated stranger, a coding assistant that executed untrusted config on repo open, and a run of permission-bypass fixes in a major agent CLI. The pattern is consistent, and it is architectural.

A snapshot as at 19 July 2026, drawn from disclosures and changelogs in the preceding three weeks.

If you want an honest read on the state of agent security, do not read the vendor marketing. Read the changelogs and the disclosures. Over the three weeks to 19 July 2026 they tell a consistent and slightly uncomfortable story: the industry is shipping agent capability faster than it is establishing the boundaries that capability requires, and the gap is being closed by patches — after discovery, in production.

Three weeks, three shapes of the same problem

GitLost: an agent talked into leaking private repositories

On 6 July 2026, Noma Labs disclosed a flaw in GitHub's Agentic Workflows. The attack requires no credentials, no access and no coding skill. An unauthenticated attacker files an ordinary GitHub Issue on a public repository, with plain-English instructions in the issue body. The agent — which holds cross-repository read access — reads the issue as part of its context, follows the instructions, and posts private repository contents as public comments.

The detail that should stay with you: the researchers report that prefixing the injected instruction with the word "Additionally" was sufficient to get past GitHub's guardrails. The vulnerability was responsibly disclosed before publication.

This is the canonical dangerous shape, and it is worth naming precisely because it recurs. Combine three ingredients — untrusted input, access to private data, and a channel to the outside world — and you have an exfiltration primitive. Any two are usually fine. All three together, in a loop that acts autonomously, is a breach waiting for someone to notice.

CVE-2026-12957: untrusted configuration, executed on open

Disclosed publicly on 26 June 2026 by Wiz Research, this one is about a different failure: trust boundaries around configuration. The Amazon Q Developer extension for VS Code automatically loaded and executed the MCP configuration file found in an opened repository — no prompt, no consent, no workspace-trust check. Spawned processes inherited the developer's full environment, including AWS access keys and session tokens.

Merely opening a malicious repository yielded arbitrary code execution and cloud credential theft. It scored 8.5 on CVSS 4.0. To Amazon's credit the remediation timeline was sound — reported 20 April, patched 12 May in Language Servers for AWS v1.65.0, disclosed 26 June.

The lesson generalises well beyond one extension. An MCP configuration file is executable content. A repository is untrusted input. Treating a file that arrives with a git clone as trusted configuration is the same mistake as running a downloaded script without reading it, wearing better clothes.

The patch stream

Then there is the steady evidence from release notes. Across eight days in July, one widely used agent CLI shipped fixes for:

  • 11 July — a plugin shell-injection issue, where configuration values interpolated into shell form are now rejected.
  • 14 July — hardening of the agent tool against indirect prompt injection, plus a fix for isolated worktree subagents performing git mutations against the main repository. That second one is an isolation escape: the sandbox was not containing what it claimed to contain.
  • 18 July — a cluster of permission-bypass fixes. Single-segment directory allow rules were auto-approving writes to nested directories anywhere in the tree. Permission checks could be bypassed in Windows PowerShell 5.1, and via file-descriptor redirects, commands over ten thousand characters, and shell variable subscripts.

Read that last group carefully. These are not exotic research attacks. They are the ordinary, grubby ways that shell environments defeat naive command inspection — and they had to be found and fixed one at a time.

What the pattern tells us

I want to be fair to the vendors here, because the naive reading of the above is wrong. A high volume of security advisories against a project is not evidence that it is less secure than a quieter one. It is evidence of scrutiny and release velocity. The OWASP GenAI Security Project's June 2026 report on agentic security tracks 53 agentic projects, of which 28 are coding agents, and notes that the five fastest-growing projects in the space are all coding agents. Projects under that much attention accumulate advisories. Projects nobody looks at do not.

The more useful observation is structural. Prompt injection maps to six of the ten categories in OWASP's Top 10 for Agentic Applications. That is not a bug class sitting in one corner of the threat model. It is a solvent that dissolves most of the others, because an agent that can be instructed by its input can be made to misuse every legitimate permission it holds.

And this is why "we hardened the model against injection" is a comfort, not a control. Every hardening measure in the list above was a response to a bypass that got through the previous hardening measure. Filtering is a mitigation with an unknown false-negative rate against an adversary who gets unlimited attempts and only needs one success.

What to actually do

If injection cannot be reliably filtered, the defensible strategy is to make a successful injection boring — to ensure that an agent following hostile instructions cannot reach anything that matters.

  • Break the trifecta deliberately. For any agent, write down its untrusted inputs, its private data access, and its egress channels. If it has all three, remove one by design rather than trying to filter your way to safety. An agent that reads public issues should not also hold cross-repository private read access.
  • Scope credentials to the agent, never to the human. The Amazon Q issue was severe because spawned processes inherited a developer's full environment. Agents should hold their own narrow, short-lived, auditable credentials.
  • Treat repository-supplied configuration as untrusted. Require explicit consent before any file arriving via clone or pull can configure tool execution.
  • Distinguish connection-time authorisation from runtime authorisation. Establishing that an agent may connect to a system is not the same as establishing that a specific action should proceed. The MCP Enterprise-Managed Authorization extension is explicit on this point about its own scope.
  • Assume your sandbox leaks until you have tested it. The worktree isolation escape is a reminder that isolation is a claim requiring verification, not a property you get by naming a feature after it.
  • Log agent actions as security events. If an agent were induced to exfiltrate data tomorrow, would you be able to tell from your logs? For most teams the honest answer is no.

The measured view

None of this argues against deploying agents. It argues for deploying them with the assumption that their instruction-following is, for the foreseeable future, attacker-influenceable — and designing the blast radius accordingly.

The encouraging signal in these three weeks is that the disclosure and patch machinery is working. Real researchers found real flaws, disclosed them responsibly, and vendors shipped fixes quickly. That is a functioning ecosystem. The sobering signal is what it implies about the flaws that have not been found yet in systems attracting far less scrutiny than GitHub, Amazon and Anthropic.

Filtering prompt injection is a mitigation with an unknown false-negative rate, against an adversary with unlimited attempts who needs to succeed once. Architecture is the only control that does not depend on winning every exchange.

Sources

Agentic AISecurityPrompt InjectionMCPDelivery Leadership

Want to see it in action?

Try the live Document Intelligence demo.

Agent Security Is Being Patched, Not Solved | Vishal Sharma Cloud