AI agent attacks are bypassing legacy controls and leaving no trace

At a glance

What this is: This research report tests real attacks against AI agents and finds that coding, productivity, and first-party agents fail in different ways, with remote code execution, silent exfiltration, and broad trust-boundary exposure among the key outcomes.

Why it matters: For IAM and security teams, the risk is that AI agents already behave like privileged non-human identities, so access governance, secrets handling, and runtime controls must extend beyond human identity programmes.

By the numbers:

• 36% of successful attacks on coding agents in scope, including Cursor, Claude Code, and GitHub Copilot, reached remote code execution on the developer’s machine, the same machine that holds source code and cloud keys.
• 91% of successful attacks on productivity agents ended in silent data exfiltration.
• 24% of 17,651+ tracked Model Context Protocol servers carry at least one vulnerability.
• 28.6% of 130,667 cataloged tools are high risk on their face.

👉 Read Straiker’s STAR Labs threat report on AI agent attack paths and blast radius

Context

AI agents are becoming operational systems, not just chat interfaces, which means they now inherit credentials, tools, and data access that were previously bounded by human workflows. Once an agent can read email, browse the web, or invoke internal tools on behalf of a user, the security problem shifts from model quality to access governance and runtime control. That is where the primary AI agent identity risk sits.

Straiker’s report is useful because it does not treat agentic AI as a theoretical concern. It runs adversarial scenarios against production coding, productivity, and first-party agents, then measures what actually breaks: remote execution on developer machines, silent data theft, and shared supply-chain exposure through Model Context Protocol and third-party tools. For IAM, PAM, and NHI teams, the finding is that agent behaviour must be governed as a living identity surface, not an application feature.

Key questions

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why coding agents create a credential-exposure problem

Coding agents sit close to the most sensitive developer assets: source code, build pipelines, cloud credentials, and local shells. When they are tricked into executing malicious instructions, the result is not only bad output but machine-level execution on a trusted workstation. That matters because the workstation often already contains cached secrets, authenticated sessions, and access paths into production systems. In practice, the agent becomes an execution layer that can inherit the user’s authority while also amplifying it through tool calls and file access. The control gap is not just prompt safety. It is the absence of per-agent identity, scoped secrets, and runtime containment around the machine that the agent can influence. Practical implication: treat coding agents as privileged execution surfaces and bind them to isolated credentials and restricted tool permissions.

Practical implication: Treat coding agents as privileged execution surfaces and bind them to isolated credentials and restricted tool permissions.

How productivity agents turn trusted access into silent exfiltration

Productivity agents are embedded in email, documents, chat, browser activity, and search, which makes them high-context systems with broad read access. They do not need malware in the traditional sense to cause loss. If the agent can see sensitive content and decide to forward, summarise, or store it elsewhere, exfiltration can occur as a normal-looking workflow step. That is why no jailbreak or phishing link is required for many of these attacks. The main weakness is implicit trust in what the agent is allowed to read and where it is allowed to send information. Security teams need policy boundaries that are specific to data classes, destinations, and agent tasks. Practical implication: define which data categories agents may access, transform, or export, and enforce those boundaries at runtime.

Practical implication: Define which data categories agents may access, transform, or export, and enforce those boundaries at runtime.

What shared tool ecosystems mean for agentic supply-chain risk

Model Context Protocol servers, plugins, and marketplace skills create a shared dependency layer across many agents. That layer behaves like a supply chain because one vulnerable or malicious component can be consumed by multiple agents across different workflows. Straiker’s findings show this is not a fringe problem. Vulnerable MCP servers and high-risk tools are already present at scale, and a poisoned skill can function like prompt injection with distribution. The architectural issue is that trust is transitive. Once an agent loads a tool or server, its decisions may be shaped by a component the enterprise did not directly build or review. Practical implication: inventory external tool dependencies, assess them continuously, and treat agent integrations as a supply-chain control problem rather than a plugin preference.

Practical implication: Inventory external tool dependencies, assess them continuously, and treat agent integrations as a supply-chain control problem rather than a plugin preference.

Threat narrative

Attacker objective: The attacker aims to turn the agent’s own authority and context into a covert path to code execution, data theft, or enterprise system access.

1. Entry occurs when the attacker manipulates an AI agent through poisoned content, malicious tools, or credential-harvesting tricks that target the agent’s workflow context.
2. Escalation follows when the agent is allowed to invoke privileged tools, open sessions, or act on cached credentials that were never scoped for machine-speed decision making.
3. Impact appears as remote code execution, silent data exfiltration, or enterprise-wide blast radius when a first-party agent operates inside the corporate trust boundary.

NHI Mgmt Group analysis

AI agent identity is now a governance category, not a feature set. Once agents can read mail, browse the web, invoke tools, and touch credentials, they behave like non-human identities with delegated authority. That means the identity problem is no longer limited to human users or service accounts. It now spans agent lifecycle, privilege scope, and tool access, which is exactly where IAM and PAM programmes must extend their model.

Silent agent failure creates a detection problem that legacy controls do not solve. Traditional endpoint, firewall, and vulnerability tooling can miss attacks that occur through the semantic layer of instructions, context, and tool choice. The result is not a noisy compromise but a workflow that looks normal while data leaves the environment. For practitioners, this elevates policy enforcement, telemetry at the agent boundary, and behavioural monitoring over retrospective review.

Agentic supply chain sprawl is the named concept security teams should watch. Shared MCP servers, plugins, and skills create a distributed trust graph where a single compromised dependency can influence many agents at once. That collapses the assumption that each agent is independently governed. Identity teams should treat those dependencies as part of access governance, because the real question is who or what is allowed to shape agent decisions.

Blast-radius control matters more than static approval models for first-party agents. Enterprises that build their own agents inside the trust boundary are concentrating risk, not reducing it, unless those agents are heavily segmented. A compromised first-party agent can reach systems and data that external-facing agents cannot. The practical conclusion is that agent governance must be designed around containment, revocation, and scoped execution.

The report validates the shift from model risk to operational identity risk. The hard problem is no longer only what the model generates, but what the agent is authorised to do with that output. That moves the control conversation into NHI governance, secret management, and delegated access review. Teams that still frame agents as applications will understate the threat surface and overtrust their existing controls.

What this signals

Agentic AI will force identity programmes to move from account management to action management. The practical shift is that teams must govern what an agent can do, not just what it can authenticate to. That means access policy, secret scope, and runtime telemetry all need to describe permitted actions in context, especially where human and machine workflows overlap.

AI agent governance debt is building faster than most programmes can absorb. The more agents connect to browsers, mail, documents, and internal tools, the more hidden dependencies accumulate across identity, data, and application layers. Teams should expect audit demand to increase first around privileged tool use, then around data egress and accountability evidence.

In risk terms, the next control gap is not discovery alone but containment after discovery. Organisations that can identify agent identities but cannot quickly revoke tools, isolate sessions, or trace delegated actions will still be exposed, even if they have a policy on paper. That makes agent runtime controls a near-term priority for IAM, PAM, and security architecture teams.

For practitioners

• Scope each agent to a dedicated identity Assign separate credentials, tokens, and tool permissions to each AI agent so that compromise cannot inherit broad human or shared service-account access. Keep the identity tied to task and environment, not to a general user profile.
• Contain coding agents on isolated workstations Run coding agents in restricted environments that limit file access, shell execution, and cloud credential exposure. The goal is to prevent a single prompt injection from turning into machine-level compromise or lateral movement.
• Classify data access for productivity agents Define which document types, mailbox folders, chat channels, and web destinations a productivity agent may touch, then block any cross-boundary export that has not been explicitly approved.
• Inventory MCP servers and marketplace tools Track every Model Context Protocol server, skill, and plugin in use, then review them for vulnerabilities, excessive permissions, and unapproved distribution paths. External tool trust should be owned like any other third-party access path.
• Build revocation paths for agent permissions Make it possible to disable an agent, revoke its tokens, and cut off tool access without waiting for a full change cycle. Fast containment matters because agent abuse can unfold inside a single workflow session.

Key takeaways

• AI agents are emerging as non-human identities with real execution authority, which makes legacy access models insufficient on their own.
• Repeated successful attacks against coding and productivity agents show that silent compromise and exfiltration are already operational risks, not theoretical ones.
• The control priority is to bind each agent to scoped identity, constrained tools, and fast revocation so that abuse cannot spread across the enterprise.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• 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.
• Silent Exfiltration: Data loss that happens through normal-looking agent actions rather than obvious malware or alarm-triggering behaviour. Because the agent may summarise, forward, or copy sensitive information as part of a legitimate workflow, detection depends on boundary controls and auditability, not just threat signatures.
• Agentic Supply Chain: The collection of models, tools, plugins, prompts, memory stores, and middleware that an AI agent depends on to operate. Weaknesses in this chain can introduce hidden instructions, poisoned context, or exposed secrets, so security teams need inventory, trust validation, and isolation controls across the entire path.

What's in the full report

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

• Per-agent attack findings across coding, productivity, and first-party deployments, useful if you need scenario-level evidence for internal risk reviews.
• Research details on how malicious tools, prompt injection, and compromised contexts led to remote execution or silent exfiltration.
• The report’s full breakdown of Model Context Protocol and tool-chain exposure, including the shared dependency patterns that expand blast radius.
• The STAR Framework for AI Agent Security, which is the source’s structural model for mapping attack surface across layers and agent types.

👉 Straiker’s full report covers the attack scenarios, tool-chain exposure, and agent security framework in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control model needed for agents, workloads, and delegated access.