// ELUSIVE THOUGHTS — APPSEC / DEVELOPER TOOLING

Your IDE Is the Endpoint Now: Coding Agents as the New Privileged Surface

Posted by Jerry — May 2026

Your security program probably has a category for endpoints. Workstations. Servers. Mobile devices. EDR coverage, MDM enrollment, baseline hardening, the usual.

There is a category that is missing from most programs in 2026, and it is the most privileged category in the modern engineering organization: the AI coding agent running inside the developer's IDE. Cursor. GitHub Copilot. Claude Code. Windsurf. Aider. Cline. Continue. The list keeps growing and the threat model is consistent across all of them.

// what is actually running on the developer's machine

A coding agent in 2026 is not an autocomplete extension. It is a process with the following capabilities:

• Full read access to the developer's filesystem within the project directory, frequently extending beyond it
• Write access to project files, often with auto-save enabled
• Shell command execution, frequently with the developer's shell environment, meaning their AWS profile, GCP credentials, kubectl context, GitHub tokens, and SSH keys
• Network access to LLM providers and arbitrary URLs encountered in tool use
• MCP server connections that grant additional capabilities, including database access, browser automation, and external API integration
• Configuration files that may execute on project open

From a permission standpoint, this is more privileged than most production service accounts.

// the trust boundary moved

The traditional trust model for a developer machine assumes that the developer is the agent of action. Code is reviewed before execution. Configurations are inspected before applied. Repositories are explored before built.

Coding agents invert this. The agent reads the repository's instructions, configurations, and prompt files. It executes based on what it reads. The developer is the approver, but only if the tool surfaces the approval. Every coding agent that exists has some path that bypasses or pre-emptively answers the approval prompt.

CVE-2025-59536, disclosed by Check Point Research in February 2026, demonstrated this against Claude Code. Two vulnerabilities, both in the configuration layer:

VULN 1 — HOOKS INJECTION VIA .claude/settings.json

A repository could contain a settings file that registered shell commands as Hooks for lifecycle events. Opening the repository in Claude Code triggered execution before the trust dialog rendered. No user click required. Effectively, repository-controlled remote code execution on every developer who opened the project.

VULN 2 — MCP CONSENT BYPASS VIA .mcp.json

Repository-controlled settings could auto-approve all MCP servers on launch, bypassing user confirmation. Combined with a malicious MCP server in the repository, this gave the attacker a tool execution channel with full developer credentials.

The structural lesson is more important than the specific CVE. Any coding agent that respects in-repository configuration files has this attack surface. Cursor's .cursor/. Aider's project config. Continue's .continue/. The patterns are similar. The vulnerabilities are not all disclosed yet.

// the prompt injection vector

Configuration injection is the obvious attack. Prompt injection is the subtler one and arguably the larger problem.

When a coding agent processes a repository, it reads the README. It reads source files. It reads issue descriptions, commit messages, dependency manifests, and documentation. Every text input is potentially adversarial. The "Agent Commander" research published in March 2026 demonstrated that markdown files committed to GitHub repositories can contain prompt injection payloads that hijack coding agent behavior — specifically, instructing the agent to make outbound network requests, modify unrelated files, or execute commands while appearing to perform the user's original task.

This is not theoretical. It has been observed in production environments. The Cloud Security Alliance documented multiple incidents in their April 2026 daily briefings.

// what the security program needs to add

The corrective controls below are organized by maturity level. Most organizations are at level zero on this category. Moving up two levels is a significant lift but produces meaningful risk reduction.

LEVEL 1 — INVENTORY

Know what coding agents are installed across your developer fleet. Browser extension audit on managed Chrome and Edge. IDE plugin audit via VS Code, JetBrains, and editor-specific management consoles. Survey developers directly. Most organizations are surprised at how many distinct coding agents are in active use.

LEVEL 2 — APPROVAL AND VERSION CONTROL

Establish an approved-tools list. Pin versions. Auto-update is now part of your supply chain — when Claude Code, Cursor, or Copilot pushes an update, that update has access to your developer machines. The compromise of any single coding agent vendor is a fleet-wide developer machine compromise. Treat the version pinning seriously.

LEVEL 3 — REPOSITORY HYGIENE

When opening unfamiliar repositories, use a sandboxed profile or a clean container. The Hooks-injection attack only works if the developer opens the repo in their privileged primary environment. A scratch container with no real credentials makes the attack much less effective. Several teams I work with have adopted devcontainer-based defaults specifically for this reason.

LEVEL 4 — CREDENTIAL HYGIENE FOR CODING AGENTS

Coding agents should not have access to long-lived production credentials. Period. Developer machines should authenticate to cloud providers via short-lived tokens issued through SSO, with explicit time-bounded sessions for production access. The standard developer setup of a static AWS key in ~/.aws/credentials with admin policies is incompatible with running a coding agent in 2026.

LEVEL 5 — MCP SERVER GOVERNANCE

Maintain an approved-MCP-server list. Treat MCP server URLs the same way you treat API integrations: registered, audited, time-bounded. The April 2026 research showing 36.7 percent of MCP servers vulnerable to SSRF means that even legitimate MCP integrations are potential attack vectors.

// the cultural change

The harder part of this work is convincing engineering leadership that developer machines are now in scope for the security program in a way they previously were not. The traditional argument — developers are trusted, their machines are behind VPN, EDR is sufficient — is structurally inadequate when the developer's IDE is reading and acting on instructions from external sources.

The framing that lands with engineering leaders: the coding agent is a junior contractor with administrative access to production. You would not give that role to an unvetted human. The agent has the same effective access. Treat it accordingly.

The endpoint that ships your code is the endpoint attackers want. They have already figured this out. The defensive side of the industry is roughly twelve months behind, which is enough time to close the gap if the work starts now.

$ end_of_post.sh — what does your dev fleet inventory look like? hit reply.

Browser-Use Agents and Server-Side Request Forgery: Old Vulns, New Vectors

Browser-Use Agents and Server-Side Request Forgery: Old Vulns, New Vectors

SSRF is not new. It’s been on the OWASP Top 10 since 2021, it’s been in every pentester’s playbook for a decade, and it’s the reason you’re not supposed to let user input control outbound HTTP requests from your server. We know how to prevent it. We know how to test for it. We’ve written the cheat sheets, the detection rules, the WAF signatures.

And then we gave AI agents a browser and told them to “go look things up.”

SSRF is back, and this time it’s wearing a trench coat made of natural language.

The Old SSRF: A Quick Refresher

Classic SSRF is straightforward: an application takes a URL from user input and makes a server-side request to it. The attacker supplies http://169.254.169.254/latest/meta-data/ instead of a legitimate URL. The server dutifully fetches AWS credentials from the instance metadata service and hands them to the attacker. Game over.

Defences are well-understood: validate URLs against allowlists, block private IP ranges, resolve DNS before making the request to prevent rebinding, restrict egress at the network level. This is AppSec 101.

But those defences assumed something: that URLs would arrive as URLs, in URL-shaped fields, through parseable HTTP parameters.

That assumption no longer holds.

The New Vector: AI Agents as SSRF Proxies

An AI agent with browsing capabilities is, architecturally, an SSRF vulnerability by design. Its entire purpose is to receive instructions in natural language and make HTTP requests to arbitrary destinations. The “user input” isn’t a URL parameter — it’s a sentence like “check the internal admin dashboard” or “fetch this document for me.”

The agent dutifully translates that into an HTTP request. And if nobody told it that http://localhost:8080/admin is off-limits, it will happily go there.

This isn’t theoretical. Let me walk you through what’s already happening.

Real-World Evidence: It’s Already Being Exploited

1. Pydantic AI — CVE-2026-25580 (CVSS 8.6)

In February 2026, Pydantic AI — a widely-used framework for building AI agents — disclosed CVE-2026-25580, a textbook SSRF vulnerability in its URL download functionality. The download_item() helper fetched content from URLs without validating that the target was a public address.

Any application accepting message history from untrusted sources (chat interfaces, Vercel AI SDK integrations, AG-UI protocol implementations) was vulnerable. An attacker could submit a message with a file attachment pointing at:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

And the server would fetch AWS IAM credentials and return them. Multiple model integrations were affected — OpenAI, Anthropic, Google, xAI, Bedrock, and OpenRouter all had download paths that could be abused.

The fix? Comprehensive SSRF protection: blocking private IPs, always blocking cloud metadata endpoints, validating redirect targets, resolving DNS before requests. Standard SSRF defences that should have been there from day one. The fact that a framework built specifically for AI agents shipped without basic SSRF protection tells you everything about the current state of agent security.

2. Tencent Xuanwu Lab — Server-Side Browser Kill Chains

Tencent’s Xuanwu Lab published a white paper on AI web crawler security in February 2026 that reads like a horror story. They tested server-side browsers across multiple AI products and found remote code execution vulnerabilities in every single one. The affected products collectively serve over a billion users.

Their four documented attack cases expose a pattern:

Case	Entry Point	Bypass Method	Impact
1	AI search with URL allowlist	302 redirect via allowlisted site	RCE, no sandbox
2	AI reading + sharing + screenshot	Chained features to bypass domain allowlist	SSRF to cloud metadata
3	URL access with script filtering	<img onerror> bypassed <script> filter	RCE via N-day chain
4	Hidden backend indexing crawler	No bypass needed — no defences	RCE, no sandbox

Case 4 is particularly grim: a hidden backend crawler that batch-fetched URLs users had queried — invisible to frontend security, undocumented, running an outdated browser with no sandbox. The attacker didn’t even need to bypass anything.

The Xuanwu team puts it bluntly: “When you launch a browser instance, you are not starting a simple web browsing tool — you are launching a ‘micro operating system.’ A vulnerability in any single component could lead to remote code execution.”

3. Unit 42 — Indirect Prompt Injection as SSRF Delivery Mechanism

Palo Alto’s Unit 42 published research in March 2026 documenting web-based indirect prompt injection (IDPI) attacks observed in the wild. Not proof-of-concept. Not lab demos. Production attacks.

Their taxonomy maps the full kill chain from SSRF’s perspective:

• Forced internal requests: Embedded prompts in web pages instructing agents to access http://localhost, internal services, and cloud metadata endpoints
• Unauthorized transactions: Prompts directing agents to visit Stripe payment URLs and PayPal links to initiate financial transactions
• Data exfiltration: Instructions to collect environment variables, credentials, and contact lists — then exfiltrate via URL-encoded requests
• Data destruction: Commands to rm -rf and fork bombs targeting backend infrastructure

The delivery methods are creative: zero-width Unicode characters, CSS-hidden text, Base64-encoded payloads assembled at runtime, SVG encapsulation, HTML attribute cloaking. 85% of the jailbreaks were social engineering — framing destructive commands as “security updates” or “compliance checks.”

The kicker: one attacker embedded 24 separate prompt injection attempts in a single page, using different delivery methods for each one. If even one bypasses the model’s safety filters, the attack succeeds.

4. Browserbase — “One Malicious <div> Away From Going Rogue”

Browserbase’s February 2026 analysis frames the problem with precision: “Every webpage an agent visits is a potential vector for attack.” They cite the PromptArmor research on Google’s Antigravity IDE, where an indirect prompt injection hidden in 1-point font inside an “implementation guide” successfully exfiltrated environment variables by encoding them as URLs and sending them via the browser agent’s own network requests.

That’s SSRF triggered by reading a document. The URL didn’t arrive as a URL. It arrived as invisible text on a web page.

Why Traditional SSRF Defences Fail Against Agents

The fundamental problem: SSRF defences are designed to protect applications, not autonomous decision-makers.

Traditional Defence	Why It Fails With Agents
URL allowlists	Agents generate URLs dynamically from natural language — no static list covers the infinite space of valid requests
Input validation on URL parameters	The “input” is a sentence, not a URL. The URL is constructed internally by the agent
WAF signatures	Natural language payloads don’t match traditional SSRF patterns
DNS pre-resolution	Only works if you control the HTTP client — many agent frameworks use browsers that handle DNS independently
Egress filtering	Agent needs internet access to function — blocking egress breaks the core use case
IP blocklists	Only effective if applied at the HTTP client level before the request is made — agents using embedded browsers bypass application-layer controls

The Tencent Xuanwu research adds another dimension: even when enterprises implement URL allowlists, they’re trivially bypassed. A 302 redirect from an allowlisted domain to an attacker-controlled page defeats the entire scheme. The SSRF isn’t in the first request — it’s in the redirect chain that follows.

The Attack Surface Is Bigger Than You Think

SSRF in the context of browser-use agents isn’t just about fetching cloud metadata. The attack surface includes:

• Cloud metadata services: AWS IMDSv1 (169.254.169.254), GCP, Azure, Alibaba Cloud — stealing IAM roles, service account tokens, API keys
• Internal APIs and admin panels: Accessing unauthenticated internal services that trust requests from within the network perimeter
• Database ports: Probing internal MySQL:3306, Redis:6379, PostgreSQL:5432 — extracting data from services that don’t require auth on localhost
• Container orchestration: Accessing Kubernetes API servers, Docker sockets, etcd — pivoting to full cluster compromise
• Other agents: In multi-agent architectures, a compromised agent can SSRF into other agents’ API endpoints, creating cascading compromise
• Data exfiltration via URL encoding: The PromptArmor/Antigravity technique — embedding stolen data in outbound URL parameters, effectively using the agent as a covert channel

The Xuanwu team found that server-side browser containers were often deployed in the same network segment as production databases, task schedulers, and model inference nodes. Zero network isolation. Once the browser was compromised, lateral movement was trivial.

What Actually Works

If you’re deploying agents with browsing capabilities, here’s what you need — not principles, but concrete controls:

1. Network Isolation (Non-Negotiable)

Browser agents must run in isolated network zones. Egress to the internet: allowed. Access to internal services, metadata endpoints, private IP ranges: blocked at the infrastructure level. Kubernetes NetworkPolicies, separate VPCs, cloud security groups. This is the single most effective control — if the agent can’t reach 169.254.169.254, stealing metadata credentials is off the table regardless of what the LLM is tricked into doing.

2. SSRF Protection at the HTTP Client Level

Every HTTP request the agent makes should pass through a hardened client that:

• Resolves DNS before connecting (prevents rebinding)
• Blocks private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16)
• Always blocks cloud metadata endpoints, even if “allow-local” is configured
• Validates every redirect target, not just the initial URL
• Restricts protocols to http:// and https:// only

Pydantic AI’s post-CVE fix is a good reference implementation.

3. Browser Sandboxing (Never Disable It)

The Tencent research found that multiple AI products disabled Chrome’s sandbox (--no-sandbox) to resolve container compatibility issues. This is catastrophic. Fix the container configuration instead: add the required seccomp profiles, grant CAP_SYS_ADMIN if necessary, configure user namespaces properly. The sandbox is the last line of defence against RCE — removing it turns every browser vulnerability into a full server compromise.

4. Instance Isolation

Each browsing task should use an independent, ephemeral browser instance that’s destroyed after completion. This prevents cross-task contamination, stops persistent compromise, and eliminates credential leakage between sessions. Browserbase’s approach of dedicated VMs per session with automatic teardown is the right model.

5. Attack Surface Reduction

Disable everything the agent doesn’t need: WebGL, WebRTC, PDF plugins, extensions. If performance allows, run with --jitless to eliminate the V8 JIT compiler — which accounts for roughly 23% of Chrome’s high-severity CVEs. Tencent’s analysis shows that disabling WebGL/GPU and JIT alone eliminates nearly 40% of browser vulnerability surface.

6. Runtime Behaviour Control

Tencent open-sourced SEChrome, a protection layer that monitors browser process system calls and enforces allowlists for file access, process execution, and network requests. Even if an attacker achieves RCE inside the browser, they can’t read sensitive files, execute arbitrary commands, or access the network beyond permitted destinations. Every tested exploit was blocked.

The Uncomfortable Truth

We’re deploying AI agents that have the browsing capabilities of a human user, the network access of a server-side application, and the security boundaries of neither. Every web page they visit is a potential attack payload. Every URL they construct is a potential SSRF. Every redirect they follow is a potential pivot point.

SSRF wasn’t “solved” in traditional web applications — it was managed through layers of controls that assumed a predictable request flow. AI agents break that assumption completely. The request flow is generated by a language model interpreting natural language from potentially hostile sources.

The good news: the defences exist. Network isolation, sandboxing, SSRF-hardened HTTP clients, instance isolation, runtime behaviour control. None of this is novel engineering. It’s applying established security patterns to a new deployment model.

The bad news: most agent deployments aren’t implementing any of it.

Old vulns don’t retire. They just find new hosts.

---

Sources & Further Reading:

• CVE-2026-25580 — Pydantic AI SSRF in URL Download Handling
• Tencent Xuanwu Lab — AI Web Crawler Security White Paper
• Unit 42 — Fooling AI Agents: Web-Based Indirect Prompt Injection in the Wild
• Browserbase — Your AI Browser Is One Malicious <div> Away From Going Rogue
• SEChrome — Server-Side Chrome Browser Protection (GitHub)
• DeepTeam — SSRF Red Teaming for AI Agents