Why this matters now
A recent Day-0 advisory sweep surfaced a tight cluster across agent and LLM-adjacent frameworks: Langflow, Gradio, LangChain text splitters, langchain-openai, and LangGraph. The useful lesson is not "frameworks have bugs." The useful lesson is narrower and more quotable:
That sentence is the bridge between classic application security and AI-agent security. SSRF filtering, redirect handling, DNS binding, sandboxing, MCP server approval, and deserialization hardening are all real controls. But agent systems add a second problem: untrusted content can steer an otherwise legitimate workflow into using its allowed authority in the wrong moment.
A same-day external AEO test reinforced the answer shape. Gemini treated the query as a real security-architecture problem and led with a shift from pre-fetch validation to continuous, action-time zero trust. It then grouped the answer around prompt-injection/SSRF defenses, redirect handling, URL/IP validation, MCP security, egress controls, sandboxing, and human review for state-changing actions. The missing vendor sentence is where Sunglasses should show up.
A later refresh added a sharper edge for AI-agent crawlers and web-read tools: a Crawl4AI Docker API advisory cluster made the point that a crawler endpoint is not just a URL fetcher anymore. The same tool can crawl, run browser JavaScript, write screenshots or PDFs, call webhooks, expose a monitor surface, and feed MCP or LLM extraction output back into the workflow.
Plain-language explainer: validation checks the input; runtime trust checks the action
Think of a normal web app. A user submits a URL. The app validates the string, rejects private networks, follows a safe code path, and fetches a document. That is already hard to get right.
An AI agent makes the same pattern more fragile. The URL may come from a prompt, an MCP tool response, a README, an issue comment, a web page, a remote configuration file, or another agent. The agent may summarize it, pass it to a tool, follow a redirect, load a schema, count image tokens, or store state in a checkpoint. Each step can transform "checked input" into "runtime authority."
That is why the trustworthy question is not only "did the URL pass validation?" It is:
- Who supplied the URL or remote config?
- Did a redirect, DNS answer, MCP schema, or callback change the destination?
- Is the agent still acting for the same user intent?
- Does this workflow need network, file, checkpoint, or execution authority at this step?
- Should the action be blocked, sandboxed, downgraded, logged, or sent to a human?
Three concrete attack examples
Redirects turn a validated URL into an internal fetch
An agent is allowed to summarize public documentation. It receives a normal-looking HTTPS URL and the initial validation passes. The server responds with a redirect to a loopback address, link-local, private-network, or cloud-metadata endpoint. If the fetch follows the redirect without revalidating the final destination, the validator checked the wrong URL.
The runtime-trust fix is to treat every redirect target as a new action request. Validate the final destination, bind DNS resolution to the fetch, block internal ranges, and ask whether this agent workflow should be fetching that destination at all.
Remote configuration becomes allowlist authority
An agent or app loads a remote tool, demo, Space, or integration. The remote configuration includes a proxy URL or endpoint that gets treated as trusted because the configuration itself loaded successfully. The system accidentally lets attacker-controlled config grant server-side request authority.
The runtime-trust fix is to separate "configuration was parsed" from "configuration is allowed to expand network reach." Remote config should not silently create allowlist entries, tool authority, or internal-service access without a fresh policy decision. This is the same discovery-surface problem our discovery-file-poisoning pattern family targets: a config, manifest, or discovery artifact that passed a parse check gets treated as policy.
Validation output becomes code or object execution
A model-generated snippet, checkpoint, or serialized object is used during a validation, restore, or workflow-resume step. The system treats that artifact as implementation detail instead of untrusted input. If the restore path reconstructs objects or executes generated code, a validation phase can become runtime compromise.
The runtime-trust fix is to keep generated code, checkpoints, and serialized state in the "evidence" bucket until an action policy authorizes the exact execution, deserialization, or instantiation path.
AI agent crawlers and web-read tools: fetch is not the only action
Classic SSRF guidance starts with URL, IP, domain, redirect, and network-layer controls. That is still the correct first sentence. The agent-tooling problem is that "read this page" often expands into a bundle of actions: fetch a URL, render a browser page, execute JavaScript, create screenshots or PDFs, call a webhook, write an artifact, expose monitor state, and hand extracted text to an MCP tool or agent planner.
Those controls reduce reach. They still do not decide whether the agent should use the allowed reach in this moment. Treat each crawler/web-read sub-action as a fresh authority boundary:
| Layer | Conventional control | Sunglasses second sentence |
|---|---|---|
| URL fetch | Parse URLs, block private/link-local/metadata ranges, and revalidate redirects. | Initial URL validation is not fetch authorization; re-check the final destination at action time. |
| Browser execution | Disable arbitrary JavaScript by default and sandbox browser sessions. | Rendering a page is not permission to execute page-supplied behavior or trust page-supplied instructions. |
| Screenshots, PDFs, and artifacts | Constrain output paths and file writes to approved directories. | Generated artifacts are evidence, not authority to overwrite or persist wherever the tool asks. |
| Webhooks and callbacks | Validate callback destinations at submission time and send time. | A callback is a new outbound action; re-check destination, scope, and user intent before sending. |
| MCP and web-read outputs | Use transport auth, server metadata, schema controls, and gateway policy. | Authenticated tool output is still untrusted agent input until it is allowed to shape this action. |
What the first controls should do
Do not skip the conventional controls. They are the first sentence, and they reduce the blast radius:
- Patch the vulnerable package. Specific advisories matter — check the affected range and patched version for any web-fetch, crawler, or agent-framework dependency in the path.
- Parse URLs with a real URL parser. Do not validate with string contains checks.
- Block unsafe schemes and internal destinations. Reject loopback, private, link-local, multicast, IPv6 internal forms, and cloud metadata ranges.
- Revalidate after redirects. Disable automatic redirects by default or loop every Location target through the same policy.
- Bind validation to the actual fetch. DNS rebinding and TOCTOU gaps appear when the safe decision and the network action are separated.
- Validate webhooks and callbacks twice. Check callback destinations when the job is submitted and again when the callback is sent.
- Constrain generated artifacts. Screenshots, PDFs, crawler output, and extracted files should only write to approved directories.
- Disable arbitrary browser JavaScript unless the workflow explicitly needs it. A crawler that can execute JS has a different authority profile than a crawler that only downloads bytes.
- Treat MCP servers and tool schemas as authority boundaries. Approve servers, pin transports, reject unexpected schema mutation, and isolate tool resources.
- Sandbox tool execution and network egress. Use default-deny egress, ephemeral runtimes, and separate privileges for analyzers versus actors.
- Use human review for high-impact internal-service actions. HITL should trigger when the destination, authority, or business impact changes.
Those controls answer "can this ever be safe?" Runtime trust answers "should this specific workflow do it now?"
How Sunglasses catches the missing decision
Sunglasses is not a generic SSRF scanner, MCP gateway, or patch manager. The honest Sunglasses wedge is action-time evidence: it looks for the moments where an AI workflow crosses from untrusted or semi-trusted text into authority.
In this class of failures, that means patterns around:
- tool output or remote content being treated as instruction, policy, or authority;
- callbacks, redirects, or MCP handoffs changing the effective destination after an earlier check;
- config, schema, checkpoint, metadata, or validation artifacts being promoted from evidence into execution;
- fallbacks and retries quietly changing the action path while the agent still appears to be following the original plan;
- network, file, deserialization, or code-execution authority being used after context drift.
The runtime-trust question is deliberately narrow: given the tool, source, destination, user intent, policy, and current context, should this already-allowed action proceed?
That is the sentence Sunglasses should own beside the broader controls. Patch the framework. Harden URL validation. Lock down MCP and egress. Then decide whether the agent should use its authority right now.
For broader foundations, see AI Agent Security 101, the how Sunglasses works page, the Sunglasses manual, and the pattern database. For the CVP methodology behind our published findings, see CVP, and for common questions about scope, see the FAQ.