Skip to content
Wingback Security

Endpoints take the first hit: OWASP Agentic Top 10 for coding agents

Wingback Security · 6 min read

Security teams spent years treating a laptop with a developer identity as a privileged system. Coding agents pack that same risk into one session.

A modern assistant can read the repo, open a shell, touch local credentials, call SaaS APIs, and load MCP servers, usually under the same ambient authority the human already has. When the session goes wrong, the failure is often a legitimate tool running with a legitimate identity toward an outcome nobody would have approved, not unsafe model wording.

That is the frame the OWASP Top 10 for Agentic Applications (2026) puts in front of builders and defenders. Microsoft’s Security CTO office later summarized the same list for enterprise operators in Addressing the OWASP Top 10 Risks in Agentic AI with Microsoft Copilot Studio: agentic failures are rarely bad output; they are bad outcomes.

This post covers the slice of that taxonomy that shows up first on developer endpoints, and why alert-only monitoring is not enough once the agent can still write the file or exfiltrate the secret on the next step.

What OWASP is actually ranking

Microsoft’s breakdown of the Agentic Top 10 is a useful plain-language map:

  1. ASI01 Agent goal hijack: injected or poisoned content redirects the plan.
  2. ASI02 Tool misuse and exploitation: legitimate tools are chained, parameterized, or steered into unsafe actions.
  3. ASI03 Identity and privilege abuse: delegated trust and inherited credentials become the attack surface.
  4. ASI04 Agentic supply chain: third-party agents, tools, plugins, registries, and update channels.
  5. ASI05 Unexpected code execution: generated or invoked code becomes unintended execution.
  6. ASI06 Memory and context poisoning: stored context biases later actions.
  7. ASI07 Insecure inter-agent communication: weak authenticity or integrity between agents.
  8. ASI08 Cascading failures: one fault fans out across tools and workflows.
  9. ASI09 Human-agent trust exploitation: authority bias produces unsafe approvals.
  10. ASI10 Rogue agents: drift or compromise beyond intended scope.

For coding agents on a laptop, three entries do most of the practical damage: ASI02, ASI03, and often ASI05. You do not need a novel jailbreak string if the agent already has shell, filesystem, and cloud-credential reach. Industry write-ups aimed at solo developers, such as HasP’s OWASP Agentic Top 10 ranked for coding agents, make the same point: on a single developer box, identity abuse and tool misuse are what turn a hijacked session into a leaked credential.

This sits alongside MCP-specific research about poisoned tool catalogs; the two topics complement each other. Here the tools can be ordinary: Read, Shell, ApplyPatch, a browser fetch, or a project MCP server that was intentionally installed. The risk is authorized capability used the wrong way.

Why developer endpoints concentrate the risk

Enterprise AI programs often start with cloud gateways and approved SaaS agents. Those matter. Coding agents still sit in a different trust pocket:

  • Ambient privilege. The agent inherits the developer’s SSO tokens, SSH keys, cloud CLIs, package registries, and local secrets files. ASI03 is the default runtime, not an edge case.
  • High-impact tools by design. Shell and file tools are the product. Least privilege has to be policy, not hope.
  • Untrusted content arrives early. READMEs, issues, tickets, docs sites, and fetched pages all become instructions. Goal hijack (ASI01) is frequently the setup for tool misuse (ASI02), not a separate incident class.
  • Offline and side-channel reality. A laptop leaves the corporate network. If enforcement only works when a cloud proxy is reachable, the control disappears exactly when the agent is still useful.

Traditional EDR sees processes. It does not reliably see “the coding agent just tried to read .aws/credentials after summarizing a poisoned issue comment.” Agent Detection & Response has to sit where the tool decision happens.

What “good” looks like for coding-agent ADR

Buyers evaluating endpoint AI security should ask operational questions:

Do you discover the real inventory? Sanctioned Copilot is not the whole story. Shadow assistants, personal accounts, local models, skills, and MCP servers on managed devices are inventory problems before they are content-filter problems. Wingback’s public coding agent security positioning puts discovery of those surfaces first.

Can you enforce before the tool runs? Detect-only telemetry after a secret leaves the box is forensics, not control. Fail-closed hooks and local policy (warn, mask, or block a tool call before execution) are the difference between ASI02 as a dashboard chart and ASI02 as a prevented action.

Are identities and paths in scope? Protecting “the model prompt” while ignoring credential stores, shell download-and-run patterns, and protected configuration files misses ASI03 and ASI05. Controls have to reason about what is being touched, not only what was said.

Is there a decision trail? When an agent is blocked, security and platform teams need correlatable logs: which agent, which tool class, which policy, which outcome. OWASP and Microsoft both treat observability as part of governance, not an optional SIEM nicety.

Do red-team findings become standing guards? Mapping to the Agentic Top 10 helps only if validated paths compile into policies that stay on across Cursor, Claude Code, Copilot, and the next IDE that ships next quarter.

How Wingback helps mitigate the issue

Wingback provides Agent Detection & Response across endpoints, cloud/SaaS, and first-party software. For coding agents specifically, the public mitigation story maps cleanly to ASI02 and ASI03:

  • Discover on every device. Browser and native endpoint coverage finds coding assistants, local MCP servers, skills, and local models, and attributes them to a device identity instead of treating each tool as an unknown process.
  • Score posture against known agentic and MCP risks. Risky auto-approve configs, sensitive path exposure, and unsanctioned toolchains become findings before they become incidents.
  • Enforce inline at the edge. Hooks and an embedded policy path can warn, mask, or block unsafe tool activity, including sensitive file access and dangerous shell patterns, and remain useful when the laptop is offline.
  • Feed runtime evidence into the broader ADR loop. Endpoint events sit alongside cloud and software agent controls so identity abuse and tool misuse are not trapped in a laptop-only silo.
  • Close with adaptive red teaming. Techniques mapped to OWASP LLM / Agentic / MCP lists and MITRE ATLAS help prove whether the same unsafe path still succeeds after policy lands.

Wingback does not replace least-privilege credentials or careful project allowlists. It makes those choices enforceable while agents move as fast as developers expect.

See coding agent security, AI agent security, and platform capabilities, or request a demo.

What to do this week

  1. Inventory coding agents and local MCP on managed developer devices, including “temporary” installs.
  2. Treat ambient credentials as in-scope for agent policy: secret files, cloud CLIs, and package tokens are ASI03 assets, not background noise.
  3. Prefer fail-closed enforcement for high-impact tools (shell, credential paths, unprotected outbound fetch) over detect-only mode.
  4. Require human approval gates for irreversible actions; do not rely on model judgment alone (ASI09 meets ASI02).
  5. Map backlog items explicitly to OWASP Agentic Top 10 ASI01 through ASI03 and ASI05 so platform and security share one priority list.
  6. Read Microsoft’s OWASP Agentic mitigations overview as a buyer’s lens: development-time constraints plus continuous operational oversight.

Sources and further reading

Talk with Wingback

If coding agents on your developer fleet are inheriting ambient credentials, chaining tools you would not approve, or leaving you with detect-only telemetry when you need fail-closed control, that is a concrete ADR problem, not a prompt-tuning exercise.

Request a demo and we will walk through how Wingback would discover the real assistant inventory, enforce at the tool boundary, and help you close the specific gap this post describes.

Draft only - not published. For review.