Web content

Read a link without your own servers fetching it

Firecrawl performs the request and returns the page text, which is why handing a workflow a hostile address does not reach anything inside Aestus.

Join the waitlist See the Firecrawl example

Firecrawl with Aestus

Keep the tool. Change what the team can see.

Letting a product fetch any address a user types is one of the older ways to get hurt. The address does not have to be a web page; it can be a machine only your own servers can see. Aestus avoids the whole class of problem by not being the thing that fetches. Firecrawl makes the request, from its own infrastructure, and hands back the text. An address aimed at something private finds nothing, because nothing private is on that side.

The step that does the fetching is kept narrow on purpose: it holds Firecrawl and no other tool. A page full of confident instructions therefore has nothing to act on, since the step it arrives in cannot do anything except fetch.

When the connection is missing the run stops and says so. That sounds obvious and it is the part that goes wrong most often elsewhere — a summary that reads perfectly well and was written without ever opening the link.

Good first workflows

Summarize a link somebody shared
Get the argument, the numbers and what is missing, each tied to the part of the page it came from.
Watch a page that keeps changing
Re-read a pricing or changelog page on a schedule and report only what moved since last time.
Keep the fetch outside your network
The request originates on Firecrawl's side, which is why a pasted address is not a way in.

A complete Firecrawl example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

Example — fictional team and data. Not a live run or customer result.

Inside the connected tool

What the Firecrawl connection can and cannot do

One operation, and it only reads: Firecrawl fetches the address and returns the text. Aestus never makes the request.

firecrawl · connectedRead-only

Runs without an approval

Fetch one address and return its text

Held for a named person

Nothing in this connection

The request is made by Firecrawl, never by Aestus.

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Read a link on the team's behalf without the server fetching it

Someone drops a long changelog into a ticket. The page is fetched by Firecrawl, summarized, and cited back to the section it came from.

TriggerA link is handed to the summarize workflow

1
Aestus workflow
Passes the address to Firecrawl
Aestus never makes the request itself, so a hostile address cannot reach anything inside the network.
fetch off-network
2
Firecrawl
Retrieves the page and returns its text
The crawl runs on Firecrawl's infrastructure and returns readable content, not a screenshot.
1 page · text returned
3
Aestus workflow
Writes the summary with a source per point
Each point names the heading it came from, and anything the fetch missed is stated as missing.
EXAMPLE-FC-01 · 7 points
4
Ada · Support
Reads the summary on the ticket
The link, the fetch outcome and the run cost stay attached to the ticket that asked.
read-only · no approval needed

Example — fictional team and data. Not a live run or customer result.

Illustrative product example — not a production run

Summarize the linked changelog

Example run		Runtime	Outcome
EXAMPLE-FC-01	Aestus workflow	aestus	Completed	$0.0143	24.6s

Tokens in / out: 8,900 / 540
Failure code: —
Agent: —

Illustrative Aestus workflow; actual costs and results vary

Example run cost

$0.0143 in the illustrative product example

A fixed example standing for one link summarized from 8,900 input tokens of page text. Fetching and summarizing are both inside that run.

Set it up in four steps.

Follow the real Firecrawl connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Connect Firecrawl
Connect it in Settings, Integrations like any other toolkit. It belongs to the organization and appears in the same connected-account list.
Read the provider docs
02
Understand who makes the request
The fetch runs on Firecrawl's infrastructure, not from Aestus. That placement is the safety property, not a detail of hosting.
Read the provider docs
03
Keep the fetching step to one toolkit
The node that fetches a page holds Firecrawl and nothing else, so a page cannot talk a run into using an unrelated tool.
Aestus product guide
04
Hand it a link
Give a workflow an address. It returns the summary with each point tied to the part of the page it came from.
Aestus product guide

The boundary stays visible while the work moves.

See what Firecrawl can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

Fetching is off your network

Aestus never issues the request itself, so an address pointed at an internal host has nothing on the inside to reach.

A read needs no gate

Retrieving a public page changes nothing anywhere, so the run is not held and no approver is interrupted.

The fetching step holds one tool

That node carries the fetch and nothing else. Content arriving from a stranger cannot widen what the step can do.

What Aestus records

The address and the outcome

The link, whether the fetch succeeded, and what came back stay on the task, so a thin summary is explained by a thin page.

A source under each point

Points name the section they came from, and anything the page did not cover is stated as absent rather than filled in.

When there was no tool

A run with no Firecrawl connection fails with a stated reason instead of inventing a summary of a page it never saw.

Questions teams ask

Why not just fetch the page yourselves?

Because a first-party fetcher turns any pasted address into a request from inside our network. Firecrawl makes the request from its own infrastructure, so an address aimed at something internal finds nothing.

What happens without the connection?

The run fails and says the Firecrawl tool was not available to it. It does not produce a summary of a page it could not read.

Can a page tell the agent what to do?

The fetching step carries Firecrawl alone and no other tool, so instructions hidden in a page have nothing to reach for.

See all integrations See the security controls

Start with one Firecrawl run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Read a link on the team's behalf without the server fetching it

Someone drops a long changelog into a ticket. The page is fetched by Firecrawl, summarized, and cited back to the section it came from.

TriggerA link is handed to the summarize workflow

1
Aestus workflow
Passes the address to Firecrawl
Aestus never makes the request itself, so a hostile address cannot reach anything inside the network.
fetch off-network
2
Firecrawl
Retrieves the page and returns its text
The crawl runs on Firecrawl's infrastructure and returns readable content, not a screenshot.
1 page · text returned
3
Aestus workflow
Writes the summary with a source per point
Each point names the heading it came from, and anything the fetch missed is stated as missing.
EXAMPLE-FC-01 · 7 points
4
Ada · Support
Reads the summary on the ticket
The link, the fetch outcome and the run cost stay attached to the ticket that asked.
read-only · no approval needed

Example run

Runtime

Outcome

EXAMPLE-FC-01

Aestus workflow

aestus

Completed

$0.0143

24.6s

Questions teams ask

Why not just fetch the page yourselves?

What happens without the connection?

The run fails and says the Firecrawl tool was not available to it. It does not produce a summary of a page it could not read.

Can a page tell the agent what to do?

The fetching step carries Firecrawl alone and no other tool, so instructions hidden in a page have nothing to reach for.

Read a link without your own servers fetching it