How to Handle Untrusted AI-Generated URLs

AI systems generate URLs constantly.

They appear in:

model answers;
tool arguments;
web-search results;
citations;
fetched documents;
MCP resources;
generated Markdown;
automated workflows.

A URL that looks plausible can still be malformed, deceptive, or dangerous.

The safe rule is:

Treat model-generated URLs exactly like any other untrusted input.

Parse first, never string-match casually

Do not authorize a URL with checks such as:

urlString.startsWith("https://trusted.example")

That can be fooled by values such as:

https://trusted.example.attacker.com/
https://trusted.example@attacker.com/

Use a real URL parser and inspect normalized components:

scheme
host
port
path
query
fragment
userinfo

Restrict schemes explicitly

If a tool is intended for web access, allow only the schemes you actually support.

For example:

https

and perhaps explicitly approved:

http

for narrow local-network workflows.

Reject unexpected schemes such as:

file:
data:
javascript:
ssh:
ftp:
custom-app-scheme:

unless the feature intentionally supports them.

Userinfo is a red flag

A URL can contain credentials-like syntax:

https://user:password@example.com/

Even when technically valid, this complicates logging and trust evaluation.

For AI-generated outbound URLs, rejecting userinfo is usually safer than attempting to support it.

Hostnames need normalization

Hosts can be represented in ways that make visual inspection misleading.

Examples include:

uppercase/lowercase differences;
trailing dots;
internationalized domain names;
IPv4/IPv6 literals;
alternate textual forms.

Normalize using platform networking APIs rather than building a homegrown parser.

SSRF-style risks apply to AI tools

Suppose the model can call:

fetch_url(url)

An attacker-controlled document may instruct it to fetch:

http://127.0.0.1:...
http://localhost:...
http://169.254.169.254/...
http://10.0.0.5/...

Depending on where the tool runs, that can expose internal services that were never intended to be reachable through the AI workflow.

This is the same class of trust-boundary problem commonly associated with server-side request forgery.

Classify destination ranges

A networking policy may need to distinguish:

public internet
loopback
link-local
private IPv4 ranges
private IPv6 ranges
local DNS names
configured private network

Do not assume a hostname is public just because it does not look like an IP address.

DNS can resolve it to a private address.

Re-check after DNS resolution

If the security policy is based on network range, validate the resolved destination too.

Otherwise a hostname can pass a textual allowlist and resolve to a protected internal address.

Be aware that DNS answers can change over time, so authorization should be close to the actual request.

Redirects need the same validation again

A safe initial URL can redirect to an unsafe one.

For example:

https://public.example/start

may redirect to:

http://127.0.0.1/admin

Every redirect target should pass the same scheme, host, network-range, and credential-forwarding policy as the original request.

Do not validate only the first hop.

Prevent HTTPS-to-HTTP downgrade by default

A redirect from:

https://example.com

to:

http://example.com

changes the confidentiality and integrity properties of the request.

For ordinary public web access, reject transport downgrade unless the user has explicitly configured an insecure private-network workflow.

Credentials must not follow arbitrary URLs

If a tool can fetch a model-generated URL, it should not automatically attach provider credentials, cookies, or custom protected headers.

A good separation is:

provider networking -> connection-bound credentials
web fetch tool -> no provider credential by default

Never let a generated URL choose where an API key is sent.

Protect local metadata and admin services

The exact sensitive addresses depend on the execution environment.

Examples can include:

cloud instance metadata endpoints;
loopback-only admin panels;
local database dashboards;
router configuration pages;
developer services;
private inference servers.

If the tool does not need access to them, block those destinations explicitly.

Client-side and server-side execution differ

A URL fetched from a phone has access to the phone’s network environment.

A URL fetched from your backend has access to the backend’s network environment.

A URL fetched by a provider-hosted tool has yet another boundary.

Do not write one generic “safe URL” policy without considering where the request executes.

Opening a URL for the user is lower risk than fetching it silently, but not risk-free

If the model renders:

[Open this site](https://example.com)

and the user taps it, the OS/browser still provides an interaction boundary.

The app should nevertheless:

display the real destination;
reject dangerous schemes;
avoid auto-opening generated links;
consider confirmation for suspicious/unfamiliar destinations.

Link text can be deceptive

Markdown can say:

[apple.com](https://attacker.example)

The visible label is not the destination.

For high-trust workflows, show the parsed host in the confirmation UI.

Generated URLs may contain secrets

A model can reproduce sensitive values already present in context:

https://example.com?token=SECRET

Before logging, rendering, or sharing generated URLs, apply the same secret-handling rules used elsewhere.

See Why API Keys Should Never Be Put in URLs.

URL fetch tools should have resource budgets

Security also includes availability.

A malicious URL can point to:

a huge download;
a very slow stream;
redirect loops;
decompression bombs;
endless chunked responses.

Enforce limits such as:

maximum redirects
maximum response size
connect timeout
read timeout
overall deadline
allowed content types

Content type matters

If the tool is intended to retrieve text for grounding, do not blindly pass arbitrary binary payloads into downstream parsers.

Validate:

Content-Type
content length
actual parser result

and fail safely on unsupported formats.

URL allowlists should match the actual need

A narrow enterprise tool may only need:

https://docs.example.com/*

Then an allowlist is appropriate.

A general web-search tool needs broader access, so it may rely on network-range blocking plus explicit user approval for sensitive actions.

Do not overfit one policy to every tool.

Model output cannot authorize destination access

The model may say:

This URL is safe.

That statement has no security authority.

Authorization is based on application policy and normalized request data.

See Prompt Injection vs Tool Authorization.

Store provenance for generated URLs

Useful metadata includes:

source=model answer
source=search result
source=tool result
source=user message

This helps UI and diagnostics explain where a link came from.

A URL copied from a trusted user message may be treated differently from one embedded in an untrusted webpage, depending on product policy.

Test deceptive URL cases

Include cases such as:

https://trusted.example.attacker.com
https://trusted.example@attacker.com
https://127.0.0.1
https://[::1]
http://169.254.169.254
https://public.example -> redirect -> http://localhost
file:///etc/passwd
javascript:alert(1)
data:text/html,...

Also test:

IDN hostname
very long URL
embedded credentials
encoded query values
redirect loops
DNS resolving to private address

A safe outbound-fetch pipeline

The policy should run before every network hop that can cross a new trust boundary.

Where BYOKchat fits

A BYOK client may combine provider networking, local endpoints, MCP tools, web search, and generated Markdown links.

Those are different network capabilities and should not share one permissive URL handler.

Provider connections should use configured destinations and connection-bound credentials. Generated web URLs should be treated as untrusted data with independent scheme, destination, redirect, and authorization policy.