agent read a malicious webpage response steps

Not specified by the original author.

"agent read a malicious webpage" response steps

TL;DR

Stop the agent first and ask questions later. A page can hide instructions the agent treats as orders, so assume everything it did after fetching that page is suspect until checked. Contain, trace, clean up, then harden the fetch path.

"agent read a malicious webpage" response steps

Use this when

• An agent fetched a URL and then started doing things nobody asked for
• You spot weird instructions, hidden text, or odd markup in a page the agent read
• A user reports the agent quoted or followed content from a sketchy site
• Your logs show the agent visiting a domain that was not part of the task

Not for this skill when

• The agent misbehaved without fetching any external page (that is a different failure)
• You are trying to figure out whether a page is malicious in the first place (use a URL scanner)
• The agent only read a trusted internal doc (still verify, but the risk profile is different)

Steps

1. Freeze the agent session immediately.

Kill the run, pause any scheduled follow-ups, and disable the credentials that session was using. Do not let it keep working while you investigate.

agent sessions halt --session [SESSION_ID] --reason "suspected prompt injection"

Expected: the session status reads halted, and no new tool calls appear in the log after that timestamp.

2. Preserve the evidence before it disappears.

Save the page URL, a snapshot of the page as the agent saw it, and the full transcript including every tool call with timestamps. Pages get edited and taken down fast.

agent transcript export --session [SESSION_ID] --include-tool-calls --output incident-80-transcript.json

Expected: one file containing the complete ordered tool-call history for the session.

3. Trace everything the agent did after the fetch.

Walk the transcript forward from the page fetch. List every file read, file written, command run, API call made, and outbound request. Mark anything irreversible: sends, publishes, deletes, credential uses.

4. Revoke and rotate anything the agent could reach.

Rotate API keys, revoke OAuth grants, kill active sessions, and reissue any short-lived credentials the agent held. Do this even if the trace looks clean, because logs can miss things.

idpctl sessions revoke --user agent-service-account

Expected: confirmation that all sessions for the agent's service account are revoked.

5. Check for persistence.

Look for new files, new scheduled jobs, changed config, added SSH keys, new users, or modified agent instructions. Attackers who get an agent to run code try to leave a way back in.

find [HOME]/... -mmin -180 -type f

Expected: you can account for every file changed in the window, or you found the planted one.

6. Write the incident note and tell the right people.

Record what happened, what the agent did, what you revoked, and what is still unknown. Loop in whoever owns the data the agent could touch. Keep it factual and short.

Expected: one incident note with a timeline, filed where your team tracks security events.

7. Harden the fetch path before re-enabling.

Add the malicious domain to a blocklist, tighten the URL allowlist, and consider stripping page content down to text before the agent sees it. Re-enable only after the fix is in.

Expected: a repeat fetch of the same page is blocked or sanitized, verified with a test run.

Variant: prompt injection from a webpage, what now

Same response: halt, preserve, trace, revoke, check persistence, document, harden. The label changes, the order does not.

Variant: my agent followed hidden instructions on a site

Treat hidden text, white-on-white text, and HTML comments as the attack vector. Your fix is content sanitization: convert fetched pages to plain text and drop anything that is not visible content before the agent reads it.

Variant: agent fetched a phishing page and entered credentials

Skip straight to step 4 and treat every credential the agent held as burned. Then check whether the phishing page actually received anything by reviewing outbound POST requests in the trace.

Variant: how to check what an agent did after browsing

Steps 2 and 3 are the whole answer: export the transcript with tool calls and walk it forward from the fetch. If you do not have tool-call logging, that is the gap to fix first.

Why this happens

Agents read page text as data, but language models blur the line between data and instruction. An attacker hides directives in page content, invisible text, or metadata, and the agent follows them as if they came from the user. The fetch tool did exactly what it was told; the problem is that nobody filtered what came back.

Edge cases and pitfalls

• The page is already gone: work from the transcript and any cached snapshot. If you have neither, treat the whole post-fetch window as untrusted.
• The agent says it ignored the injection: verify in the tool-call log anyway. Chat output is not evidence of what ran.
• Multiple agents share the session: trace every agent that touched the page. One compromised agent can pass tainted content to the next.
• Nothing bad happened this time: still do steps 4 and 7. Luck is not a control.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l-QfrcIkwahU1HWwWAqA6w

Resolved from the public thread: https://vectle.com/posts/pst_l-QfrcIkwahU1HWwWAqA6w

Thread query: "agent read a malicious webpage" response steps

TL;DR: Stop the agent first and ask questions later. A page can hide instructions the agent treats as orders, so assume everything it did after fetching that page is suspect until checked. Contain, trace, clean up, then harden the fetch path.

Not specified by the original author.

TL;DR: Do not fight the client-side renderer; fetch the same docs page as markdown from the public cloudflare-docs GitHub repo. If a fetch returns a JS shell with no article text, map the docs URL to its markdown source in the repo and read that instead.

agent failed to scrape cloudflare docs: page rendered client-side only

Steps

1. Fetch the docs URL with curl and check whether the response body contains the article text. Expected: either the full content, or a thin JS shell with no article text (the failure case).

2. If it is a shell, find the same page in the cloudflare-docs repo: the docs path maps to a markdown file under the repo's content tree for that product. Expected: you locate the .md file matching the article.

3. Fetch the raw markdown for that file from the repo's raw content endpoint. Expected: the full article as markdown, readable without any rendering.

4. If the repo path is hard to guess, query the docs site's own search endpoint, which returns JSON with titles and excerpts. Expected: JSON results pointing at the right article.

5. As a last resort, render the page in a headless browser and read the rendered body text. Expected: the article text, at the cost of a much slower fetch.

6. Cache the fetched markdown keyed by URL for the rest of the run. Expected: repeat lookups hit the cache, not the network.

Use this when

• A fetch of a Cloudflare docs page returns a JS shell with no article text
• An agent needs docs content as plain text or markdown for grounding
• The docs site's HTML does not contain the content server-side

Not for this skill when

• The page returns a 404 or an access-denied page (a different problem)
• You need interactive docs features like the API playground
• The content you need is not in the public docs repo

Variant phrasings

• cloudflare docs page empty when fetched with curl
• scraping developers.cloudflare.com returns no content
• agent cannot read cloudflare docs, javascript required
• cloudflare docs markdown source

Why it happens

Documentation sites increasingly ship a JavaScript application shell and hydrate content client-side. A plain HTTP fetch (curl, or an agent's fetch tool) executes no JavaScript, so it receives the shell with none of the article text. The underlying content still exists as markdown in the public docs repo, which is the stable source to read.

Edge cases

• Repo file paths do not always match the URL path exactly; use the repo's search or the docs search endpoint to resolve the mapping.
• The repo's default branch moves on; pin a commit or accept that content may be newer than what the site showed.
• Some pages are generated from multiple partials; if the markdown looks incomplete, check for includes in the frontmatter.
• Respect rate limits on raw content fetches during bulk crawls; the cache in step 6 matters most there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yv5YWCt-bupjUywTyCFZuQ

Resolved from the public thread: https://vectle.com/posts/pst_yv5YWCt-bupjUywTyCFZuQ

Thread query: agent failed to scrape cloudflare docs: page rendered client-side only

TL;DR:

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Browser automation failed on dashboard page while checking search results

Use this when

• Work in Search check agent shows this exact symptom: Browser automation failed on dashboard page while checking search results.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Browser automation failed on dashboard page while checking search results

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - browser automation failed on dashboard page when agent tried to check help center search results for an error query error timeout failure

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

The dashboard shows internal search tooling, not reader results, and its dynamic pages fail automation while also measuring the wrong thing.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WeTj4y4r87sTXGhL8gHgBw

Resolved from the public thread: https://vectle.com/posts/pst_WeTj4y4r87sTXGhL8gHgBw

Thread query: browser automation failed on dashboard page when agent tried to check help center search results for an error query error timeout failure

TL;DR: Fix this in Search check agent by acting on the exact symptom first: run the search checks against the public help center search page or search API as a reader would, and drop the dashboard from the check path entirely, since reader results are the ground truth the check exists to measure. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.