Agentic AI security needs its own framework for context attacks

At a glance

What this is: This is an analysis of why agentic AI security needs a separate framework, because attacks target context, tools, and deployment posture rather than only the model itself.

Why it matters: It matters because IAM, PAM, and broader governance teams now have to treat AI agents as systems with access, context, and operational blast radius, not just as user-facing software features.

By the numbers:

• Straiker says it ran more than 1,700 successful exploits against real coding, productivity, and first-party agents.
• Against coding agents, 36% of successful attacks in Straiker’s testing reached remote code execution on the developer’s machine.
• 91% of successful attacks in Straiker’s testing ended, s in Straiker’s testing ended in silent data exfiltration.

👉 Read Straiker’s report on the STAR Framework for agentic AI security

Context

Agentic AI changes the security problem because the system can act, not just generate text. In this setting, the key risk is agentic AI context security, where instructions embedded in emails, documents, comments, or tool responses can redirect legitimate automation into attacker-controlled actions.

Straiker’s article argues that traditional controls still assume a hostile user or a hostile model, while real-world agent attacks often exploit trusted context and connected tools. That makes the governance question one of access, runtime oversight, and control placement across the agent stack, including the identity of the agent itself when it can reach sensitive systems.

Key questions

Q: How should security teams control context in agentic AI systems?

A: Security teams should treat context as a governed input, not an implementation detail. That means classifying sources, restricting who can write or retrieve from them, filtering sensitive content, and logging every context change that affects agent behavior. If an agent can only act safely when its inputs are trusted, context provenance becomes a core control.

Q: Why do agentic AI systems create more security risk than standard chatbots?

A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.

Q: What do organisations get wrong about prompt-based safety for agentic AI?

A: They assume better instructions can compensate for broad tools. In practice, prompts do not reliably prevent misuse when the agent can browse, email, or write data, so safety has to come from tool scoping, permission boundaries, and enforced session state.

Q: How can organisations reduce blast radius when an AI tool is compromised?

A: Limit the tool's scope, separate high-risk functions from general collaboration data, and make revocation fast enough to matter. Pair least privilege with short-lived tokens, clear ownership, and logging that links the agent, the user, and the downstream system. Containment only works when those paths are visible.

Technical breakdown

Indirect prompt injection in agentic AI

Indirect prompt injection occurs when attacker instructions are placed in content the agent is already expected to read, such as an email, webpage, code comment, or tool response. The model is not “broken” in the classic sense. It follows the instructions it sees in context, because the attack targets the agent’s interpretation layer rather than the underlying model weights. This is why prompt filtering alone misses the issue. The real security boundary is the trust relationship between retrieved context and downstream action.

Practical implication: inspect and constrain the content sources agents can read before you rely on prompt-level filtering.

The agentic attack surface across tools and MCP

Straiker’s framework separates agent architecture from deployment context, which is useful because tools and connectors are where abstract risk becomes operational exposure. The Model Context Protocol and similar tool layers turn the agent into a broker across APIs, documents, and execution environments. If a malicious or vulnerable server is trusted, the agent can inherit that risk at runtime. This is also where NHI governance becomes relevant, because agent tokens, service credentials, and delegated permissions determine how far a compromise can travel.

Practical implication: map every connector, secret, and delegated permission to a named owner and a scoped business purpose.

Why blast radius depends on agent role

The same injection can produce very different outcomes depending on whether the agent is coding, productivity, or first-party. A coding agent may reach local shell execution, while a productivity agent may expose sensitive data through over-broad access, and a first-party agent may operate with higher trust in internal systems. That means risk is not only about whether an agent exists, but what it can touch, what it can invoke, and what identity it uses to do so. This is the part most governance models still flatten.

Practical implication: classify agents by role and privilege before you decide whether a control belongs in the model, tool, or identity layer.

Threat narrative

Attacker objective: The attacker’s objective is to turn a legitimate agent into a trusted execution path for data theft, code execution, or broader system compromise.

1. Entry occurs when attacker-controlled language is embedded in a source the agent is already permitted to read, such as an email, document, code comment, or tool response.
2. Credential access and action abuse follow when the agent accepts the injected instruction and uses its delegated permissions, API access, or connected tools to execute it.
3. Impact occurs when the compromised workflow leaks data, executes code, or expands into connected systems through the agent’s own trust boundary.

NHI Mgmt Group analysis

Context has become the real control plane for agentic AI. The article’s central point is that the model is often not the failure point, because it is behaving as designed. The failure is the assumption that a legitimate user and an aligned model are enough to make the system safe. For identity teams, that means the security boundary has shifted toward what the agent can read, what it can invoke, and which credentials make those actions possible. The practitioner conclusion is that context must be governed like access.

Agent identity should be treated as a governance object, not a product feature. Once an agent can call tools, traverse MCP servers, or reach internal APIs, it functions as a non-human identity with real operational reach. That makes the interaction between identity governance, secrets management, and runtime authorization central to the problem. OWASP-NHI and the NIST AI Risk Management Framework both become relevant here because the issue is no longer only model risk, but the identity and containment of the agent system itself. The practitioner conclusion is that agent privileges need lifecycle control, not informal enablement.

Blast-radius design matters more than static trust assumptions. The article’s own data shows that the same technique produces remote code execution in one role and silent exfiltration in another. That is a governance signal, not just a technical curiosity. It means agent architecture and deployment context have to be evaluated together, or controls will be attached to the wrong layer. The practitioner conclusion is that control design should start with what damage each agent role can cause, then place approvals, monitoring, and identity restrictions accordingly.

Tools and MCP servers are emerging as the weak link in the agent supply chain. If a trusted connector can widen access across multiple agent roles, then the problem is not isolated prompt safety but shared dependency risk. This is where the agentic ecosystem starts to resemble other supply chain problems in cybersecurity, except the attacker can steer behavior through natural language rather than code alone. The practitioner conclusion is to govern connectors as privileged infrastructure, with registration controls, trust review, and explicit ownership.

AI-powered persistent threats change the cadence of defence. The article describes attackers using agentic methods for reconnaissance, exploit generation, and persistence, which compresses the time defenders have to observe and respond. That makes quarterly review cycles and static assessments too slow for the environment being described. The practitioner conclusion is that runtime observation, rapid policy adjustment, and identity-aware telemetry become part of the minimum control set.

What this signals

Context-aware governance will become the differentiator for agent programmes. The question is no longer whether teams can deploy agents, but whether they can prove what each agent saw, what it touched, and what identity it used at the moment of action. That pushes auditability, provenance, and delegated access control into the same conversation as model safety, and it does so quickly because the deployment pace is accelerating.

Agent sprawl will expose an NHI lifecycle gap unless ownership is formalised. As agents multiply, their tokens, keys, and connector credentials will behave like other unmanaged machine identities unless they are brought into lifecycle processes. That makes identity review, rotation, and offboarding operational requirements, not optional hygiene, and the lifecycle discipline documented in the Ultimate Guide to NHIs , Why NHI Security Matters Now becomes directly relevant.

AI agent security will increasingly be evaluated as a control-mapping problem. The practical question for programme owners is whether the current identity, data, and runtime controls attach to the places where the agent actually makes decisions. If they do not, the organisation will have policy language without enforcement depth, which is the pattern attackers exploit first.

For practitioners

• Define agent privilege boundaries Classify every AI agent by role, data reach, tool access, and identity used for execution. Remove default trust from productivity and first-party agents, and require explicit approval for any tool that can write, execute, or export data.
• Govern context sources before prompts Allow agents to read only approved mailboxes, repositories, documents, and tool outputs. Add content provenance checks so poisoned context is less likely to become trusted instruction, especially where the agent can take downstream action.
• Treat connectors as privileged dependencies Inventory every MCP server, API connector, and plugin the agent can reach. Enforce owner assignment, approval for new registrations, and periodic review of the permissions each connector can inherit.
• Add runtime controls to the agent layer Use monitoring that can see prompts, context, tool invocation, and resulting actions together. Pair alerting with policy enforcement so suspicious instructions can be blocked before the agent completes a task.
• Map agent risk to NHI governance Review the credentials, tokens, and delegated permissions used by agents as non-human identities. Rotate exposed secrets, limit standing access, and record each agent’s business purpose in the same lifecycle process used for other high-value NHIs.

Key takeaways

• Agentic AI risk is a context and access problem as much as a model problem.
• The article’s data shows that attacks against agents can lead to code execution, silent exfiltration, and wider tool-chain compromise.
• Security teams need role-based agent governance, scoped credentials, and runtime controls that follow the action path, not just the prompt path.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Agentic AI attack surface: The set of AI workloads, tools, prompts, and connected services that can be influenced or abused at runtime. It includes not only the model itself but also the identities and integrations that let the system act. For governance, the surface is defined by behaviour as much as by deployment.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full report

Straiker’s full research covers the operational detail this post intentionally leaves for the source:

• A breakdown of the 1,700-plus successful exploit paths across coding, productivity, and first-party agents.
• The full twelve-cell STAR map showing how application, model, tools and MCP, and data layers behave by agent role.
• Named case studies, including the Claude Code source leak, with the attack sequence and outcome for each one.
• The five-control defender playbook mapped to NIST AI RMF and OWASP categories for implementation work.

👉 The full Straiker post covers the exploit data, agent-role mapping, and control framework in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the broader security and AI governance programmes they already run.