agent read a malicious webpage" response steps

"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