eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent Safe URL Fetching — SSRF, Redirects, DNS Rebinding and Protected Networks

—

by

eduKate Asia

An AI agent that opens a user-supplied link is making a network request from its own server or tool environment. That environment may be able to reach services the user cannot: internal dashboards, cloud metadata endpoints or other privileged resources. Server-side request forgery, or SSRF, exploits this difference. A safe agent must ensure its outbound HTTP connection goes only to destinations permitted for the user’s task, even if a link redirects or its hostname resolves differently during the request.

Did you know that a URL that looks like a school’s public website can redirect a server to a different host? Or that a once-approved hostname can return another network address later? The correct defence is not to tell the language model to be careful. The fetch service must parse and validate the URL, enforce a destination policy at connection time, recheck redirects and retries, bound resource usage and treat the returned page as untrusted evidence.

This guide belongs to How Super Intelligence Works, complementing Agent File Ingestion and Tool Supply Chains. It includes an original eighty-request synthetic laboratory and a school-information transfer exercise. The figures are for learning, not actual network attack statistics or a claim that artificial superintelligence already exists.

Choose a useful route

  • Checking a source URL? Learn how an untrusted link crosses the server network boundary.
  • Building agent tools? Study parsed URLs, DNS results, redirect hops and policy at connection time.
  • Teaching systems security? Recalculate the eighty-request audit and simulate an out-of-policy redirect.
  • Protecting student information? Separate network reachability from source truth and access permission.

Contents

1. A link is a proposed instruction to the network

A parent might ask an assistant to summarise a syllabus at a provided URL. The language model can recognise the request and propose a tool call, but it cannot determine from the words alone which network endpoint will receive it. The actual HTTP client decides what to contact. Trust must therefore be checked by the client or an egress service before a connection is established.

Network access is a separate permission from answering a question. A user authorised the assistant to consult public information, not to contact arbitrary internal interfaces or send credentials to another server. If the fetched page contains instructions to call another URL, those instructions are source data, not renewed user permission. A bounded browser or document tool can preserve the legitimate purpose without inheriting every command it reads.

OWASP’s SSRF Prevention Cheat Sheet distinguishes environments in which exact destination allowlists are feasible from those whose purpose genuinely involves fetching arbitrary public resources. The latter require more careful connection-time network policy. Neither case can be implemented safely with a prompt saying ‘visit only good websites’. The agent’s words are not the network firewall.

A user-facing answer should distinguish network validation, source relevance and factual verification. Reaching a site successfully says little about whether its text applies to the correct institution, date or cohort. A blocked request may be proper protection rather than a failed educational answer. If no permitted current source exists, a truthful limitation and an alternative official source route can be useful.

Return to contents or continue with Prefer approved source identifiers to arbitrary URLs.

2. Prefer approved source identifiers to arbitrary URLs

If an application only needs a handful of official education data services, it can map source identifiers to vetted endpoints. The model chooses `read_official_mathematics_syllabus`, while trusted code maps that operation to a configured host and permitted path. The model never constructs an arbitrary destination. The same method works for an internal resource directory: approved names or IDs are safer than free-form URL strings.

An open-ended research assistant cannot always pre-register every public webpage. It may need a general internet fetcher with a strict egress policy that rejects unsafe address classes and protects redirects. The choice depends on the product; a source-specific connector is not an adequate substitute for general web research, and unrestricted networking is not necessary for a narrow institutional lookup.

Treat the allowlist as a maintained configuration with an owner. A public source may move domains or become unavailable. A website appearing in an earlier answer does not make every subdomain of that brand authorised forever. Exact domains, schemes and effective ports should reflect a reviewable contract. When a legitimate host changes, update the configuration deliberately after verification.

Source accuracy deserves a different gate. The official school website may be permitted while a page on it is an archived notice for a past academic year. The fetcher can retrieve the document safely, but a source-aware assistant must still check whether it actually supports today’s answer. Network safety and current policy truth should never be collapsed into one green status.

Return to contents or continue with Use a mature parser and exact URL components.

3. Use a mature parser and exact URL components

A raw string beginning with an allowed hostname may still parse to a different destination because of userinfo, encoding, misleading suffixes or delimiter handling. Compare the parsed scheme, canonical hostname and effective port under the same interpretation used by the HTTP client. OWASP’s Unvalidated Redirects and Forwards Cheat Sheet explains why naïve substring matching does not establish the real URL destination.

Separate the scheme from the path. A public HTTP fetch interface generally should accept only explicitly permitted HTTP or HTTPS modes, not arbitrary file, data or custom protocols. A path containing familiar words such as syllabus or timetable does not prove the authority component belongs to a school. The policy needs a defined source and connection target.

Some clients automatically normalise characters or decode encoded values. If validation and execution interpret the string differently, the tool could approve one host and contact another. Use one reliable parsing pipeline and enforce policy on the effective destination. Avoid constructing a second URL from unchecked fragments after validation.

Test synthetic awkward inputs against the real parser and client without contacting private infrastructure. Cases should cover misleading hostnames, userinfo, unusual ports, IPv6 formatting and unsupported schemes. A successful test proves the bounded behaviour of that client and configuration; it does not justify bypassing checks whenever the model offers a convincing explanation.

Return to contents or continue with DNS results are part of the permission decision.

4. DNS results are part of the permission decision

A hostname can resolve to multiple addresses and can change over time. A domain on an allowlist can still return an address outside the intended public network, so name validation alone is insufficient. OWASP’s SSRF guidance discusses validation of resolved destination addresses and keeping the actual connection tied to validated addresses.

For a public-internet fetch tool, private, loopback, link-local and relevant internal addresses are usually not permissible. The address policy should cover IPv4, IPv6 and the ways the HTTP stack actually selects connection candidates. A single regex blocking a few familiar prefixes is not a reliable implementation of the full network boundary.

Cloud metadata endpoints can expose sensitive operational information, sometimes including temporary credentials. They should not be available to an arbitrary URL fetcher merely because the agent is running inside a cloud environment. Network egress controls and appropriately configured metadata-service protections provide additional safeguards if application validation fails.

A DNS lookup used only for logging is not enforcement. If the subsequent connection makes a new unchecked lookup, the validation can be bypassed by a changed result. The client or security gateway must ensure that permitted resolved addresses are the ones actually contacted while still performing legitimate TLS certificate and hostname validation.

Return to contents or continue with Rebinding exploits a time-of-check gap.

5. Rebinding exploits a time-of-check gap

Consider a fictional host that resolves to a permitted public address at the validation stage. Immediately before the actual HTTP connection, a second lookup returns an address within an internal network. The initial decision no longer protects the destination being contacted. This illustrates DNS rebinding and more generally the danger of checking mutable data separately from its use.

The remedy is to bind connection establishment to the permitted resolution or use an egress proxy that performs the network rule at connection time. Apply checks to every candidate address and retry. The original hostname can remain relevant for TLS SNI and certificate verification; disabling TLS hostname checks in the name of connecting to an IP would create another weakness.

DNS monitors can detect unexpected changes, but an alert arriving later is not protection against a connection that already occurred. Use monitoring to improve operations and verify allowlists, while the enforcement remains at the outbound network boundary. The application’s permission decision should not depend on a future human noticing a dashboard anomaly.

A controlled test can simulate the changed resolution without ever connecting to a real internal or metadata endpoint. The test passes if a disallowed destination cannot receive an attempted request. A model’s final text that says ‘I did not access anything sensitive’ is weaker evidence than the protected client’s actual attempted-connection log.

Return to contents or continue with Redirects must be checked at every hop.

6. Redirects must be checked at every hop

HTTP servers may respond with redirects. An initial allowed domain can point to a new destination that is outside the fetcher’s permitted list or network category. If the HTTP library follows that redirect automatically without applying the policy again, one apparently safe fetch creates an unsafe second connection. Treat each redirect as a fresh destination.

Configure redirect handling in the HTTP stack or gateway. Parse and validate the new URL’s scheme and host, resolve the new destination according to the address policy and limit the number of hops. A redirect loop is also a reliability issue because it can consume the task’s time and network budget without supplying a useful document.

Protect credentials and headers during redirects. A generic public fetcher should not send private API tokens to websites selected through user input. A connector with approved credentials needs a separately scoped host and operation policy. A cross-host redirect is not permission to forward authentication headers to the new destination.

A legitimate source may move to a new official domain. The service can hold the fetch while that destination is reviewed, or use another approved official route. It should not invent the content of the moved notice to satisfy the user quickly. A truthful ‘the current page could not be verified’ preserves accuracy and trust.

Return to contents or continue with Method, port and request headers need bounds.

7. Method, port and request headers need bounds

A public webpage reader rarely needs arbitrary HTTP methods. Its permission can be limited to safe retrieval semantics and configured effective ports. An arbitrary POST to an address selected by untrusted page text could have side effects even when the agent intended only to read a timetable. Network operations should follow the actual task, not every method supported by an HTTP library.

Restrict the header set. Tokens, cookies, internal diagnostic identifiers and other secrets should not be attached to a general browsing request merely because they are available elsewhere in the agent environment. Use purpose-built authenticated provider connectors when credentials are genuinely required. Keep those secrets outside model prompts and broadly readable logs.

Limit response bytes, time, hops and relevant content types. A public site can serve an unexpectedly huge response or a stream that never finishes. This can exhaust memory, inflate model token usage or displace the passage needed for the user’s question. A bounded fetcher can return an explicit too-large or timed-out status rather than pretend it read the complete document.

Parsing returned documents introduces a separate security boundary. Scripts, active content and malformed files may need isolation or conversion. A safe network destination is not evidence that all bytes can be executed or trusted. An extracted text passage remains untrusted data for the language model and cannot authorise another tool call.

Return to contents or continue with Retries and alternate clients must keep the same gate.

8. Retries and alternate clients must keep the same gate

When an approved public address times out, the application might retry, try IPv6, follow a cached redirect or use a proxy. Each actual connection needs the same destination policy. A fallback code path that invokes an unrestricted general HTTP client can silently discard protections that existed in the first attempt.

Bound the retry count and time. A stalled research question should not generate unlimited outbound requests and model reasoning. The agent can preserve already verified source material and explain which current fact remains unavailable. Cost or latency pressure must never broaden a network rule to reach an otherwise forbidden service.

An approved vendor API may use a private connector with specific authorised endpoints. Keep that capability separate from user-supplied arbitrary public URLs. The fact that the organisation is allowed to call its own internal application does not make an arbitrary user link to the same network permissible. Capability and purpose both matter.

Use safe telemetry to diagnose repeated failures. Record task identity, relevant approved host, destination-policy result and status without leaking URL query secrets or private file content. A 200 response means an HTTP exchange occurred; it does not establish that the returned evidence was the right school policy.

Return to contents or continue with An invented eighty-request routing laboratory.

9. An invented eighty-request routing laboratory

Imagine a fictional Cedar Research Fetcher receiving eighty proposed network requests. Fifty-two resolve to approved public destinations and return a bounded response. Twelve fail structured scheme or hostname validation. Eight are blocked because their resolved addresses violate the network policy. Four are refused after attempting an out-of-policy redirect. Four remain unresolved because the otherwise allowed fetch times out.

Check the totals: 52 + 12 + 8 + 4 + 4 = 80. Approved fetches account for 52 ÷ 80 = 65%. Parsed-URL refusals are 12 ÷ 80 = 15%, address-policy refusals 8 ÷ 80 = 10%, redirect refusals 4 ÷ 80 = 5%, and timeouts 4 ÷ 80 = 5%. The figures are original teaching data, not observed rates for any real network or model.

The twenty blocked requests are not automatically service defects. They may demonstrate that a rule prevented connection to an unapproved destination. The four timeouts have a different next action, such as bounded retry or an honest hold. The fifty-two successful fetches still need content-level evaluation before the agent can claim that a user’s school question was answered correctly.

A single user task could propose several network requests and each redirect could create additional HTTP hops. The denominator in this example is proposed fetch requests, not parent tasks, unique people or verified educational outcomes. A useful dashboard should state that unit and keep end-to-end source correctness separate.

Return to contents or continue with Distinguish authenticity, safe reachability and truth.

10. Distinguish authenticity, safe reachability and truth

Reaching a permitted website under HTTPS gives a specific transport observation. It does not prove the site’s content is current, the author is qualified for every claim or the page contains instructions the agent may obey. A perfectly safe fetch could retrieve an archived admissions notice. The assistant should still check the source’s official scope and effective date.

An attacker-controlled comment on an otherwise legitimate page might tell the assistant to publish something or send confidential information. That text is a lower-trust source, not a system instruction or new user consent. The application should extract task-relevant evidence and enforce all downstream tool authorisation separately.

Content may also include links to unrelated places. A document parser that fetches images or other subresources should apply its own egress rules rather than inherit blanket permission from the top-level page. Every actual outbound connection matters. Where only text retrieval is needed, avoid unnecessary active content and resource loads.

Privacy continues after fetching. A page could contain personal details or a user’s query might include a sensitive URL token. Minimise what is copied into shared memory, prompts and logs. The user benefits from an accurate sourced answer, not an unrestricted archive of every byte the fetcher encountered.

Return to contents.

11. A denied request still needs a usable response

A blocked fetch may be the correct decision even when the parent supplied the link in good faith. The assistant should explain that the destination cannot be opened through the authorised service, without claiming that the source itself is fraudulent or that the document does not exist. A refusal can coexist with useful help: identify the public official organisation, explain general context and offer the reader a way to inspect the original source independently.

Distinguish policy refusal from network failure. A hostname outside the allowlist is denied under the configured rule; a permitted server that times out has an availability problem. A syntactically malformed URL needs a different correction again. These statuses help users and operators decide what to do next. They should not all trigger retries or cause the model to generate the likely contents of a missing page.

Keep source correctness separate even on success. A school page may contain an archived admissions timetable. Fetch permission means the network connection was allowed; factual verification still requires checking the document’s cohort, effective year and scope. An agent that cites the first relevant-looking passage without qualification can mislead readers despite perfect SSRF controls.

Return to contents for the full route.

12. Compare egress enforcement with an agent’s prompt rule

An instruction such as ‘use only public websites’ can help a model plan responsibly, but it is not a complete policy for a URL parser, DNS resolver or HTTP client. A model cannot see all subsequent redirects, address selection or proxy configuration. Enforce the allowed connection at the network layer. The final response should be generated from the observed fetch status rather than a self-assessment of whether a proposed link was safe.

An egress firewall or protected proxy can supply a second boundary if an application client has a defect. It can restrict destinations irrespective of how the model generates the URL. However, egress filtering is not a substitute for precise application purpose and authentication. The same proxy might serve several legitimate connectors that require different destination scopes. Bind the network capability to the specific tool or workload.

Review the effective policy periodically. An allowlist entry might be removed after a vendor retires, while a school service might move to an authorised replacement host. A configuration diff should be evaluated against source ownership and user impact before deployment. A model’s suggestion to add an arbitrary new host is an input to review, not an automatic firewall change.

Return to contents for the full route.

13. Prevent unexpected private requests through embedded resources

A fetched webpage can reference images, scripts, styles and other subresources. A full browser might load them automatically, creating more network requests than the user-provided top-level URL suggests. For a task that needs only publicly accessible text, a constrained HTTP fetch and parser may offer a narrower capability than a general browser. Whatever renderer is used, its actual resource loads need a matching network policy.

Scripts can initiate additional requests or redirect a page. Running arbitrary page code in a privileged agent environment increases the need for isolation and egress controls. A parser that extracts a static notice may be sufficient for many educational questions. When script rendering is necessary, use a sandbox with bounded permissions, controlled downloads and appropriate network limits rather than passing unrestricted access to the model.

Downloaded attachments present a further boundary. A link may lead to a PDF, archive or spreadsheet that needs a separate safe ingestion process. The content type header can be incorrect or misleading, so the parser and size limits should not depend solely on the filename. The File Ingestion guide describes why safe networking does not automatically make a document safe to process.

Return to contents for the full route.

14. Use one protected outbound service for every agent

Multi-agent systems can fan out into several specialists that search for evidence, parse files and verify citations. If each child creates its own HTTP client with separate configuration, one may lose restrictions adopted by the parent. Put outbound URL validation and connection enforcement behind a shared trusted gateway or equivalent consistently applied controls. Child agents should not be able to disable the rule by generating different code.

Trace every child request back to the user’s task and the authorised tool. A source-verification worker might fetch the same official document several times; that does not justify expanding destination permissions. Stable operation IDs and destination decisions help reconcile network cost and risk. An internal monitoring agent does not automatically need unrestricted network access merely because it is responsible for diagnosing failures.

Use purpose-specific credentials. The public research fetcher should not carry the WordPress publishing credential or the private school database password. If a connected service genuinely requires authentication, give that connector only its permitted target and operation scope. Preventing credential exfiltration through arbitrary web fetches is easier when the fetcher never receives unrelated secrets in the first place.

Return to contents for the full route.

15. Do not let a cached allow decision outlive its network context

An application may cache the result that a hostname was permitted, but the relevant IP addresses can change between requests. A cached policy decision based only on a name cannot replace connection-time address enforcement. Similarly, an earlier approved redirect does not authorise every future redirect chain from that host. Treat the network connection as a new decision while allowing carefully scoped caching of nonsecurity data where appropriate.

Cache lookup and DNS resolution have different lifetimes. A document’s content could be valid for a day, while its network destination must be checked on each new connection. Conversely, a currently allowed connection may deliver stale source information, which requires factual freshness checks. Using one universal TTL to solve both problems is conceptually incorrect.

Test the changed-context case: the school source was permitted yesterday and its document content remains cached, but its host now resolves to a disallowed address. The agent should not issue a new prohibited fetch because yesterday’s status was green. It may use an independently validated cached historical document only within the task’s content-freshness and permission constraints, with transparent qualification.

Return to contents for the full route.

16. Run negative tests with synthetic destinations

Build a test server that can return safe public responses, misleading URL structures, controlled redirects, delayed replies and synthetic DNS results. It should not contact live internal dashboards or cloud metadata endpoints. The test’s expected result is whether the protected client admitted or refused each attempted connection. This can exercise the real networking decision without placing production secrets at risk.

Include legitimate cases so the system remains useful. A valid approved HTTPS page should fetch, a permitted redirect within the approved set should work, and a readable bounded document should reach the source-checking stage. Denial-only tests could make an entirely broken fetcher appear secure. A trustworthy release proves both protected refusal and correct allowed behaviour.

An independent reviewer should examine the actual network attempt or mock server receipt, not merely the model’s statement that it complied with policy. Save the request type, effective host, resolved category, outcome and tool version. Remove unnecessary private text and URL tokens from logs. Preserve the specific failing synthetic case for regression after repairing a defect.

Return to contents for the full route.

17. Use the eighty-request table to test your denominator

The synthetic Cedar Fetcher ledger includes fifty-two approved public fetches, twelve parsed-URL refusals, eight network-address refusals, four redirect-policy refusals and four unresolved timeouts. These five dispositions total eighty proposed fetch requests. The blocked twenty include protective decisions: twelve plus eight plus four. They must not be described automatically as twenty user-service errors.

Now suppose two of the four originally rejected redirects are independently reviewed and become permitted through a deliberate allowlist update. The revised disposition is fifty-four approved, twelve parsed-URL refusals, eight network refusals, two redirect refusals and four timeouts. Check 54 + 12 + 8 + 2 + 4 = 80. The revised approved fraction becomes 54 ÷ 80 = 67.5%, compared with the original 65%.

The change is not evidence that an actual source was always safe, nor that readers received more correct educational advice. It reflects a changed network policy under the fictional example. A real evaluation also needs final-task outcomes, including whether the newly fetched material supported the correct institution and year. Exact arithmetic helps only when the named population and acceptance criterion are meaningful.

Return to contents for the full route.

18. Transfer exercise: a changed public school domain

Imagine a fictional Singapore school’s public timetable service moves from an approved domain to a new official host. The old page redirects to the new address, but the fetcher’s allowlist has not yet been updated. A correctly enforced redirect rule stops the next request before contacting an unreviewed target. The agent should not say that the school event was cancelled because the redirect was refused.

A responsible operator can independently confirm the new official host, inspect its scheme and destination policy and update the permitted mapping. Re-run a controlled connection test and then recheck the actual timetable text and effective date. A network allowlist change does not automatically verify the content: the moved page could have a new session time.

Change the case again. The approved hostname returns a private-network address during connection establishment. The address policy blocks it even though the visible domain name remains unchanged. Finally, an approved fetch returns text asking the model to publish a duplicate article. That text cannot grant publication permission. These changed conditions demonstrate three distinct gates: network destination, source truth and downstream action authority.

Return to contents for the full route.

19. Diagnose the failure at the correct layer

A failed request might arise from an invalid scheme, a misleading parsed host, private-address resolution, an out-of-scope redirect, a certificate error, an oversized response or a timeout. Those causes need different repairs. Expanding the allowlist does nothing for an incorrectly handled TLS certificate, and shortening a timeout does not prevent internal-network access. Use the protected client’s actual observation to identify the failing layer.

A successful request can still produce a wrong answer because the page is obsolete or the language model misinterprets it. Network-security logs do not certify factual correctness. Preserve the source URL, applicable version and exact cited evidence for an appropriate content check, while storing private data only where the task and access policy require it.

After a repair, rerun the original failing fixture and an allowed positive case. A newly patched client might reject all redirects, accidentally blocking legitimate public sources; or it might accept a previously denied internal route. Verify both sides. Model-generated assurances are useful explanations but cannot replace independent observation of the effective connection and final user outcome.

Return to contents for the full route.

Questions and answers

What is SSRF in an AI agent?

An untrusted input causes the agent’s server-side fetcher to contact a destination beyond the intended network policy.

Can exact hostname validation prevent all SSRF?

No. Address resolution, connection-time enforcement, redirects and retries need their own safeguards.

Why are redirects significant?

An initially approved URL can lead to a different destination; each hop must pass the policy.

Can the model simply refuse unsafe-looking links?

It may help with task planning, but security must be enforced by trusted URL and network operations.

Does a successful fetch prove a source is correct?

No. Safe reachability and factual applicability to the user’s specific question are different checks.

What should happen when a legitimate source becomes unavailable?

Provide a truthful limitation or authorised alternative, rather than bypass network protections or invent an answer.

Technical source notes

Sources reviewed on 24 October 2026. The Cedar Research Fetcher, proposed requests, percentages and networking examples are fictional teaching cases, not measurements of a live provider or eduKate system.

Related reading

Continue through Super Intelligence curriculum; How X Works hub; File Ingestion; Data Residency; Query Safety; Gold Standard of Education. Connection permission, source accuracy and user authority are independent requirements.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading