Skip to content
Start with Identity
Join free
SWI-T025 · Non-human identity

Agent instruction injection

An AI coding agent reads whatever text is in front of it, an issue, a title, a comment, and treats it as instruction. If that runner also holds workflow secrets, the text an anonymous account typed becomes something the credential can execute.

EmergingHard to detect
First observed: 2023

Agent instruction injection is indirect prompt injection aimed at an AI agent that holds credentials. The attacker plants instructions in content the agent will read, such as a GitHub issue, a web page, a repository rules file, or an MCP tool response, and the agent follows them using its own tokens, keys, and cloud role. The identity failure is not the model being fooled; it is that anyone who can put text in front of the agent can borrow every permission the agent holds. MITRE ATLAS catalogs the trigger as AML.T0051.001 (LLM Prompt Injection: Indirect) and the payoff as AML.T0098 (AI Agent Tool Credential Harvesting).

How it works

  1. Find an agent that reads untrusted input. Coding agents triggered by issues, CLI agents told to fetch a URL, chat agents with HTTP tools, and agents on third-party MCP servers all qualify. Greshake et al. demonstrated the class in February 2023: content an LLM application merely retrieves can carry instructions the model follows as if the operator typed them.
  2. Plant the instruction. Plain text in an issue body, hidden Unicode in a rules file, an encrypted payload, or fragments split across tool responses so none looks malicious alone.
  3. The agent acts with its own identity. It runs shell commands, reads files, calls APIs, or makes HTTP requests, all as itself. ATLAS calls this AML.T0053, AI Agent Tool Invocation.
  4. Credentials leave. Workflow secrets, .env files, SSH keys, cloud role credentials from an instance metadata service, or tokens for every connected tool are read and sent to an attacker URL, often encoded into a request parameter (AML.T0086).
  5. Reuse. The attacker uses them directly, outside the agent, where no guardrail applies.

Documented cases in 2025 and 2026 cover each delivery path:

Research Input the attacker controlled What the agent's identity reached
Novee Security, August 2026 A GitHub issue opened by an account with no repository rights Workflow API keys and repository credentials on the CI runners behind Gemini CLI and Claude Code
Zenity Labs, October 2026 A chat message to a public Amazon Bedrock AgentCore agent The execution role's credentials from the metadata service, with region-wide rights to other agents' conversations, memory, and Secrets Manager
Adversa AI, October 2026 An encrypted web page fetched by GitHub Copilot CLI in autopilot A local .env.prod file, sent to an attacker URL in 28 seconds
ASSET Research Group (GhostSplice), August 2026 Instruction fragments across MCP tool responses .ssh/id_rsa, .env files, and source repositories

Gemini CLI before 0.39.1 carried CVE-2026-12537 and Claude Code 0.2.54 through 2.1.163 carried CVE-2026-54316 in the Novee research; both shipped fixes, and OpenAI addressed its Codex repository by separating CI jobs.

Why it works

Two trust models collide. CI and cloud IAM assume that whoever triggers a job or calls a role was already authorized, so the credential can safely be available to the process. LLM agents assume input is data the model will reason about. Once an agent reads attacker-supplied text inside a process that holds credentials, untrusted input has become executable with the process's privileges. The control assumption that fails is that scoping the agent's instructions or training the model to refuse is a security boundary. GhostSplice showed several models that refused an intact malicious instruction every time complied every time when it arrived in pieces. The only boundary that holds is what the agent's workload identity can reach, because that is fixed outside the model.

How to detect it

  • Credentialed steps reached from untrusted triggers. CI runs started by issue creation, comments, or fork pull requests that read secrets or reach credentialed steps not normally reached by that trigger type.
  • Agent egress to destinations not in configuration. Outbound requests from an agent runtime to domains absent from its documented integrations, especially with long query strings.
  • Metadata service access from agent sandboxes. Calls to 169.254.169.254 from an agent's tool environment, and role credential use (GetSecretValue, InvokeAgentRuntime in AWS CloudTrail) that does not match the agent's purpose.
  • File access outside the task. Agent processes reading .env, .ssh, or cloud CLI profile files during a task that did not need them.
  • Tool-call sequences that diverge from the agent's prior runs on the same repository.

The limit: agents take varied action by design, so baselines are weak and an unusual run may be an unusual ticket. Content filtering fails against encrypted and split payloads built to pass it. Detection is a backstop; isolation is the control.

How to stop it

Ranked by effect:

  1. Separate untrusted-input jobs from credentialed jobs. The job that reads an issue, comment, external pull request, or fetched page never shares a runner, filesystem, or token with the job that deploys. GitHub's own secure use guidance warns against pull_request_target and workflow_run with untrusted content because those workflows "may have repository write access and access to referenced secrets."
  2. Scope the agent's identity to the task. Per-agent roles, never a default role shared across agents; OIDC-issued short-lived tokens for one repository and one action instead of stored keys; GITHUB_TOKEN read-only by default. Enforce IMDSv2 or block metadata access from agent sandboxes.
  3. Keep secrets out of the agent's reach. No production .env files on machines where agents run; pull credentials from a secrets manager at runtime into processes the agent cannot read.
  4. Require human approval for credential and egress actions, and do not combine autonomous modes with fetching arbitrary URLs. OWASP's LLM01:2025 lists least privilege, human approval for high-risk actions, and segregating external content among its mitigations.
  5. Treat every text source as attacker-controlled: rules files, PR titles, commit messages, MCP server output. Block one tool's output from flowing unchecked into another tool's arguments.
  6. Govern agents as non-human identities, with an owner, an expiry, and access review. See agentic identity, securing AI agent identities, and secrets in repositories and CI.

Seen in the wild

No incident in the SWI Identity Breach Database is attributed to agent instruction injection. Everything above is coordinated research, not observed attacks. The closest real incident is adjacent rather than an injection: in July 2025 an attacker used an inappropriately scoped GitHub token in the Amazon Q Developer extension's CodeBuild configuration to commit a destructive agent prompt, which shipped in version 1.84.0 and failed to run only because of a syntax error (AWS-2025-015, CVE-2025-8217; ATLAS case study AML.CS0047). Same lesson from the other side: the credential around the agent was the weak point.

Sources

This brief cites no enterprise ATT&CK ID because the mechanism, an AI model following instructions embedded in data, is outside ATT&CK's scope. MITRE covers it in ATLAS instead: AML.T0051.001 (LLM Prompt Injection: Indirect), AML.T0053 (AI Agent Tool Invocation), AML.T0086 (Exfiltration via AI Agent Tool Invocation), and AML.T0098 (AI Agent Tool Credential Harvesting), per ATLAS data version 5.6.0.

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.