Five New Prompt-Injection Attacks Steal AI Agent Credentials

Five disclosures, one root cause

Each of these findings was reported by a different team, against a different product, for a different bug class. Read individually, they look like five unrelated vendor patches. Read together, they describe the same architectural gap: an AI agent is given a tool, the tool is backed by a real credential (an API key, an OAuth token, a cloud IAM role, an authenticated session), and the agent's instructions can come from untrusted text it was never supposed to trust as a command.

That gap is not new — security researchers have called it the "lethal trifecta" for over a year: untrusted input, access to sensitive data or credentials, and an outbound channel. What's new in this wave of disclosures is the breadth of products where researchers found all three ingredients sitting in the same place at once, from a public lead-capture form to a cloud metadata endpoint.

Repeat-After-Me: six frameworks, one borrowed sentence

Researchers from Penn State, Université Montpellier, and Dartmouth College found that six widely used agent orchestration frameworks — LangChain's LangGraph, Microsoft Agent Framework, Microsoft AutoGen, Google's Agent Development Kit 2.0, AWS Strands Agents, and CrewAI — could be tricked into executing attacker-controlled tool calls simply by framing the call as text for the model to repeat back. The orchestration layer treated the model's structured tool-call output as sufficient authority to execute, even when the model's own text separately refused the request. In one demonstration on LangGraph 1.2.0 running Meta's Llama 3.1 8B, a dummy launch_missiles tool fired before the model's refusal text had even finished generating.

The bug isn't in the model's judgment — it's in the plumbing. The orchestrator extracted a tool call from the model's output and ran it without checking whether the rest of the response disagreed.

AgentCorruption: one prompt, every agent in the account

Zenity Labs disclosed AgentCorruption on October 8, 2026: a chain of flaws in Amazon Bedrock AgentCore, AWS's managed platform for running agents, that let a single prompt to one public-facing agent reach the AWS Instance Metadata Service and pull temporary credentials tied to a default execution role. Those credentials weren't scoped to the one agent — they reached across every AgentCore agent in the same account and region, including internal agents the attacker was never authorized to use. From there, Zenity's team could retrieve API keys, OAuth tokens, and other credentials stored in AWS Secrets Manager and environment variables, including credentials AgentCore agents use to connect to third-party services beyond AWS.

AWS's public response was that the research "inaccurately paints expected and documented behavior as a vulnerability." Regardless of how the finding is categorized, AWS made IMDSv2 the default for AgentCore deployments after the disclosure and reduced the default execution role's permissions, including removing the ability for one agent to invoke others or read secrets meant for different agents.

SalesBleed: a lead form becomes a data-exfiltration channel

Also from Zenity Labs, SalesBleed is a set of three vulnerabilities disclosed on September 24, 2026 in Salesforce Agentforce. The attack starts with an attacker submitting an ordinary-looking lead through a public Web-to-Lead form, with a hidden prompt injection payload embedded in one of the fields. When an employee's Agentforce agent later processes that lead as part of routine work, the embedded instructions hijack its behavior — pulling additional CRM records, including Accounts data, and exfiltrating it over DNS to bypass Salesforce's Trusted URL output filtering. Zenity's researchers were explicit about why this worked: the injection didn't need to escalate any privileges, because the permissions it abused were already granted to the CRM agent for its normal job.

Cryptographic Context Injection: hiding the command in ciphertext

Adversa AI researcher Rony Utevsky demonstrated a technique called Cryptographic Context Injection against Grok roughly two months before a near-identical chain surfaced in GitHub Copilot CLI. The idea: encrypt the malicious instructions with AES before placing them on a web page, so plaintext-scanning guardrails see only ciphertext. The agent is then induced to decrypt the payload inside its own code-execution runtime — and once decrypted, it treats the result as trusted context rather than untrusted input. Against Grok, an ordinary "summarize this page" request was enough to exfiltrate a user's chat history with no click and no warning. Against Copilot CLI running in autopilot mode, the technique read a local .env.prod file and sent its contents to an attacker-controlled endpoint within 28 seconds, with no visible confirmation step.

GitHub validated the Copilot CLI finding but declined to treat it as a product vulnerability, arguing the user had explicitly directed the CLI to fetch untrusted content while granting it full autonomous permissions. The researchers disputed that framing, noting Copilot rejects the identical instructions as plaintext and only acts on them once they're encrypted and decrypted.

The ChatGPT Lockdown Mode bypass

OpenAI introduced Lockdown Mode in June 2026 as an optional setting meant to reduce the risk of prompt-injection-driven data exfiltration. Check Point Research found that a nested frame inside a rendered HTML preview could reach an unmodified popup function, escaping the sandbox restrictions Lockdown Mode was supposed to enforce. Content opened through that popup was no longer subject to the same restrictions — which Check Point demonstrated by having a malicious custom GPT silently leak a victim's chat messages to an external server, and separately by using a spoofed "ChatGPT update" popup to push malware. OpenAI confirmed a fix on September 18, and Check Point's retesting found the technique no longer works.

What makes this one worth grouping with the other four isn't the bypass mechanic — it's that Lockdown Mode was built on the premise that you can contain prompt injection by cutting off specific outbound channels after the fact. A new rendering path was enough to open a channel nobody had closed.

Why patching the input doesn't fix the output

Every vendor involved patched something: OpenAI fixed the popup escape, AWS changed default IMDS and IAM behavior, Salesforce hardened Trusted URL filtering, and the framework maintainers named in the Repeat-After-Me research can tighten how tool calls are validated. Those patches are worth shipping. None of them change the fact that the agent, once invoked, is the thing holding the credential.

Prompt injection defenses — content filters, instruction hierarchies, output sandboxing — all assume you can reliably tell trusted instructions from untrusted content before the model acts on them. Every one of these five disclosures found a way around that assumption: hide the instruction in a repeat-back request, inside AES ciphertext, inside a CRM lead field, inside a nested HTML frame. Treating this purely as a detection problem means playing an open-ended game against whoever finds the next encoding trick.

The mitigation that survives being framework-agnostic

This is where the architecture question becomes unavoidable. If an agent process never holds the real API key, OAuth token, or cloud secret in a form it can read or forward, tricking the agent into "sending the credential to an attacker" stops being a one-step attack — there's no credential in its memory or environment to send. That's the premise behind injecting credentials at the network egress point rather than into the agent's runtime: the agent calls an endpoint through a gateway, the gateway attaches the real secret to the outbound request, and the response comes back through the same gateway. The agent authenticates to the gateway, not to the third-party API directly.

This doesn't make an agent immune to prompt injection — a compromised agent can still be manipulated into making a request it shouldn't make, within the scope it's been given. What it removes is the specific failure mode running through AgentCorruption, SalesBleed, and the Cryptographic Context Injection cases above: an attacker reading the long-lived credential itself out of agent memory, logs, or environment variables and reusing it anywhere, outside the gateway's visibility. KnoxCall's model — third-party API keys injected at the egress wire so the app process, CI runner, or AI agent never holds the real credential — is built around exactly that distinction. It's worth being honest about what it doesn't do: it won't stop a tool-call orchestrator from executing an attacker-framed request within the permissions the agent was granted, the way Repeat-After-Me does. Scoping those permissions tightly, and auditing what each agent's gateway credentials can actually reach, is still the operator's job. For teams evaluating that split of responsibility, the AI gateway architecture and general security model are a reasonable place to start.

What this means if you're shipping an agent

• Inventory every credential an agent process can read today — environment variables, mounted secret files, IAM roles — not just the ones it's supposed to use.
• Assume any text the agent ingests from outside your control can contain instructions, regardless of how it's encoded or where it comes from.
• Scope tool permissions to the narrowest action the agent's job requires, and treat "the agent has access" as a standing risk, not a one-time approval.
• Where possible, move credential handling out of the agent's process entirely so a successful injection has a request to make, not a secret to steal.

None of this is specific to one framework or one vendor, which is exactly the point of treating these five disclosures as one story rather than five.