Prompt injection in AI agents exposes legacy identity controls

At a glance

What this is: This is Teleport's analysis of how prompt injection affects AI agents and why the resulting risk is really an identity and execution problem, not just a model-safety problem.

Why it matters: IAM, PAM, and NHI teams need to treat agent behaviour as an access-control issue because injected instructions can still drive valid identities into harmful actions.

By the numbers:

• 31 of 36 systems

👉 Read Teleport's analysis of prompt injection risk in AI agents

Context

Prompt injection is what happens when untrusted text changes how an AI system interprets instructions. In agentic workflows, that becomes an identity governance issue because the model is not just generating text, it is choosing actions, tools, and targets with delegated access.

The primary security gap is not that infrastructure loses control entirely. It is that a manipulated model can still operate within approved permissions and turn trusted credentials against the enterprise, which is exactly where conventional IAM assumptions start to fail.

This makes prompt injection relevant to NHI governance, agentic AI identity, and access-boundary design across human and machine programmes. The starting point is atypical only in the sense that the attack path begins in the model context, not in a traditional exploit chain.

Key questions

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by controlling what an agent can do, not by trusting the prompt. The practical steps are distinct agent identities, narrow tool permissions, runtime authorization, and full audit trails. If injected instructions can only reach a limited set of actions, the attack becomes far easier to contain and investigate.

Q: Why do AI agents make prompt injection harder to govern than chatbots?

A: AI agents are harder to govern because their outputs can become real actions through delegated credentials. A chatbot may only produce unsafe text, but an agent can call APIs, move data, or trigger infrastructure changes. That turns instruction manipulation into an access problem, which means IAM and PAM controls must operate at execution time.

Q: What breaks when prompt injection meets shared service accounts?

A: Shared service accounts break accountability and blast-radius control. If multiple agents or workflows reuse the same identity, you lose the ability to prove which actor performed which action, and you increase the chance that a manipulated session can reuse broad access. Distinct identities are essential when the system can be influenced at runtime.

Q: Who is accountable when an AI agent follows malicious instructions?

A: Accountability sits with the organisation that granted the agent access and failed to constrain its execution boundary. The governance question is not whether the model was tricked, but whether the agent was allowed to make irreversible decisions without adequate policy checks, identity separation, and auditability.

Technical breakdown

How prompt injection changes instruction precedence in agentic systems

Prompt injection exploits the fact that modern LLM applications merge system prompts, retrieved content, user input, and tool context into one working frame. The model then infers which signals to trust when they conflict. In a simple chatbot, that may only distort text output. In an agentic system, the same ambiguity can alter tool selection, API calls, environment choice, and the identity used to carry out the action. The risk is architectural: once the model's output becomes executable, untrusted instructions can steer real operations without breaking traditional access controls.

Practical implication: separate instruction sources and treat any model-fed context as untrusted until execution-time policy checks pass.

Why delegated credentials turn prompt injection into infrastructure risk

Prompt injection becomes materially worse when an agent can act through shared service accounts, long-lived tokens, or broad operational roles. The model does not need to bypass IAM if it can simply use legitimate access in the wrong way. That is why attacks can succeed even when PAM and RBAC are functioning as designed. The weak point is the decision layer, not the permission layer. Once the agent is allowed to initiate deploys, rollbacks, or data retrieval, manipulated instructions can turn valid access into unintended execution.

Practical implication: narrow the actions exposed to agents and remove shared credentials from any workflow that can reach production systems.

What runtime authorization changes for AI agent governance

Runtime authorization matters because prompt construction is not the same as permission to act. If authorization is only checked before the prompt is formed, a manipulated model output can still generate a harmful request later in the chain. Runtime enforcement checks the request at the moment the agent tries to execute it, which is where the trust boundary actually sits. This is the right control plane for agentic systems because the model's intent may change during the session while the access policy remains fixed.

Practical implication: enforce policy at execution time, not just at prompt assembly, and log the agent identity behind every action.

NHI Mgmt Group analysis

Prompt injection is an identity problem because it lets untrusted context steer trusted credentials. The attack does not need to defeat the infrastructure control plane if it can influence what the agent chooses to do next. That means access governance, not model output quality, becomes the decisive control surface for agentic systems. Practitioners should treat this as a boundary problem between instruction and execution.

Least privilege was designed for actors with stable intent, but prompt-injected agents can change behaviour mid-session. That assumption holds when humans request actions and systems respond. It fails when a model can reinterpret instructions, select tools, and execute operations from mixed context without a human approval gate. The implication is that access reviews alone do not capture the real risk window.

Ephemeral access is necessary, but it is not sufficient if the agent can still choose the wrong action within its window. Short-lived credentials reduce exposure time, yet prompt injection can still direct a valid session toward unintended systems or data. This is why blast-radius control must extend beyond token lifetime to runtime decision constraints. Practitioners should design for constrained agency, not just shorter credentials.

Strong agent identity is the named concept that matters here: a distinct identity for each agent makes misuse visible and containable. Shared service accounts blur accountability and make it harder to distinguish routine automation from compromised behaviour. When every action is traceable to a specific agent identity, incident response and governance both improve. Practitioners should stop relying on generic automation identities for systems that can be manipulated at runtime.

Auditability becomes a governance requirement once models can turn text into action. Telemetry must show which identity acted, what was requested, which tool was invoked, and which target system was reached. Without that chain, investigations cannot separate prompt injection from normal automation failure. Practitioners should assume that if they cannot reconstruct the action path, they do not really control the agent.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control lens, see OWASP NHI Top 10 for agentic application risks and defensive priorities.

What this signals

Strong agent identity is becoming the minimum viable control for AI systems that can act on behalf of the business. Once an agent can select tools and execute actions, shared identities no longer provide enough accountability or containment. The operational signal is simple: if you cannot attribute every action to a distinct actor, you do not have governance, only convenience.

The 80% figure from our research on AI agents as a new attack surface should force a programme-level reset. These are not edge cases in lab environments, they are already showing up in production deployments, which means the question is no longer whether to govern agent behaviour, but how much damage the current control model can absorb.

Prompt injection also links directly to the wider agentic threat model in the OWASP Agentic AI Top 10. The practical planning implication is that security teams should align identity controls, runtime policy, and auditability before agent adoption scales further.

For practitioners

• Separate instruction sources from execution inputs Keep system prompts, user content, retrieved documents, and tool parameters in distinct control paths so untrusted text cannot masquerade as operational instruction. Validate every execution request after model generation and before the action is allowed to reach infrastructure.
• Replace shared automation identities with distinct agent identities Give each agent its own identity, scope, and audit trail instead of letting multiple workflows inherit the same service account or token. This makes misuse easier to detect and limits how far a manipulated session can move.
• Constrain tools and environments available to agents Expose only the smallest set of commands, APIs, and targets needed for the task, and block broad dump-style access to configs, variables, and internal state. Use policy to prevent agents from reaching production systems unless the action is explicitly approved.
• Add runtime approval gates for irreversible actions Require human or policy-based approval before deploys, rollbacks, privilege changes, or data exports can execute. Approval should occur at the moment of action, not at prompt creation, so injected instructions cannot ride through earlier checks.

Key takeaways

• Prompt injection is dangerous because it can steer agents that already hold valid access, turning trusted identities into attack paths.
• The evidence is now operational, not theoretical, with 80% of organisations reporting AI agents acting beyond intended scope and 52% lacking full audit visibility.
• The control that matters most is runtime governance of agent identity, access, and action boundaries, not prompt-only filtering.

Key terms

• Prompt injection: Prompt injection is an attack in which untrusted text changes how a model interprets instructions. In agentic systems, that manipulation can alter tool use, data access, and execution decisions, turning a language issue into an operational security problem.
• Agent identity: Agent identity is the distinct identity assigned to an AI system when it acts on behalf of an organisation. In governance terms, it is the unit of accountability that lets teams scope access, enforce policy, and trace every action back to a specific autonomous or semi-autonomous actor.
• Runtime authorization: Runtime authorization is the practice of checking whether an action is allowed at the moment it is executed, not just when a prompt or workflow is created. For AI agents, this is critical because model intent can change during a session and input can be manipulated midstream.

What's in the full article

Teleport's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how prompt injection enters through emails, calendar invites, and pull requests
• Specific agent control patterns for replacing broad roles with narrower task-scoped permissions
• Implementation guidance for runtime approval gates inside CI/CD and infrastructure workflows
• Teleport's own Agentic Identity Framework primitives for auditability and policy-governed access

👉 Teleport's full post covers the attack patterns, access-boundary controls, and agent identity model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.