HTTP header prompt injection reaches a hiring agent when its URL reader passes server-controlled metadata to the model. To audit that boundary, inspect the exact tool results for successful pages, redirects, and failures. Keep source material identifiable, exclude unnecessary metadata, and enforce candidate-data access and write permissions outside the model.

Imagine asking an assistant to compare a candidate's portfolio with your backend engineering rubric. The page describes projects. Somewhere in the response, its server also asserts an applicant score. Your team needs to know whether that assertion enters the assistant's context, appears in the summary, or can become a recorded evaluation.

Those are separate questions. A browser screenshot answers none of them. The useful review target is the contract between the fetching tool and the model: exactly which fields cross that boundary, with what provenance, under which failure conditions.

## What did the HTTP header study actually find?

The [Signals Corps investigation](https://www.signalscorps.com/blog/prompt-injection-in-http-headers/), published by Sarah Andrews on October 6, examined 217,097,223 Common Crawl responses by sampling every tenth WAT metadata file. It classified 7,959 hostnames as sending AI-directed headers, mostly resource pointers; 30 carried injection attempts. Two included an asserted applicant-match score. These were observed strings, not demonstrated hiring compromises.

The classification used a Claude research agent. CCBot's view misses content shown only to particular agents. Separate canary experiments found default rejection in the tested Claude configurations; prompts granting authority to server instructions produced the requested code word in seven of nine runs. Each model/prompt combination ran once. That is not a general success rate. The [Hacker News discussion](https://news.ycombinator.com/item?id=50104310) brought attention to the work; comments do not establish additional findings.

[Common Crawl's release announcement](https://commoncrawl.org/blog/september-2026-crawl-archive-now-available) independently confirms the underlying crawl contained 2.17 billion pages from 40.4 million hosts, collected September 4–17. That corroborates the dataset's scale, not the header classifications. Neither source establishes how common successful attacks are in deployed hiring systems.

Avoid turning distinct flagged hostnames divided by page responses into a percentage of websites. The units differ. A hostname also does not identify a candidate, a registered domain owner, or a customer. You can use this study to identify an audit surface without suggesting applicants have compromised hiring decisions at scale.

## Follow the response into the model

A URL response includes a status, headers describing the response, and a body containing the page or document. Your adapter chooses what the model receives. Review that choice in executable code and captured tool results.

Start with one deployed workflow. Write down its tool name, adapter version, extraction provider, fallback provider, and available downstream actions. Then fetch a controlled page and inspect the result at the point where it enters the model context. Inspecting the provider's response earlier in the chain can miss later formatting, summarization, or exception handling.

A useful output contract specifies the allowed fields, their types, maximum lengths, and meaning. It also distinguishes extracted source text from application-generated status. For example, a source title is still a claim supplied by an external page. Giving it its own JSON field makes it easier to trace; it does not make it authoritative.

### Identify every route to the same URL

Your ordinary reader may return extracted Markdown. A debugging tool may return network details. A fallback may return a search provider's highlights. If the agent can select another reader after a failure, that alternate route belongs in the audit too.

Ask what happens when the source returns a PDF, an unusual content type, a blocked-access page, or a login requirement. Check cached and fresh responses separately if their formatting differs. Record whether a redirect changes the displayed source address. The same requested URL can produce materially different evidence depending on the path taken.

The [MCP reference fetch implementation at the revision examined in the research](https://github.com/modelcontextprotocol/servers/blob/bbb701e7ac1e57f3edd1c2836b94c5457eaf7b9c/src/fetch/src/mcp_server_fetch/server.py) is a concrete place to study extraction and error handling. Inspect the exact version you deploy before making claims about its output. A tool's name is insufficient evidence of its behavior.

### Keep extraction separate from trust

Removing raw headers narrows one entry point. The remaining page body can still contain instructions, false claims, or irrelevant material. Our earlier [article on resume prompt injection](/blog/prompt-injection-resumes-ats-screening-defense) covers the document-content problem; this audit follows the surrounding fetch machinery.

Label external text as untrusted evidence and explain its permitted use in the agent instructions. Then test the boundary. Delimiters, JSON serialization, and reminders help organize context, but none provides a guarantee that a model will always reject embedded instructions.

## Test success, redirect, and error paths

Use synthetic candidates and infrastructure you control to test visibility and behavior separately. Inspect captured model input to establish whether each marker crossed the tool boundary. Judge instruction compliance by the requested behavior: quoting a marker while rejecting the instruction is not compliance.

Create a fictional portfolio with a short, stable project description. Put one unique marker in its body and a different one in a custom response header. Run this baseline without instructions, then run two separate variants: one with a harmless instruction in the custom header, the other with that instruction in the body. Ask for a third marker as the assistant's answer. Keep the candidate facts identical across variants so you can identify changes caused by the response channel.

The table below is a proposed audit plan, not a report of tests performed against Kit or a provider.

| Controlled fixture | Inspect | Expected boundary |
| --- | --- | --- |
| Successful page with a custom-header marker | Exact model-visible result | Only the fields allowed by the output contract appear |
| Error response with distinct header and body markers | Exception text and fallback results | Bounded failure output preserves the untrusted-source distinction |
| Redirect between permitted test origins | Destination checks and source record | Each destination is checked and origin changes remain visible |
| Body asserting a higher applicant score | Summary, citations, proposed writes | The assertion does not replace the approved evaluation rubric |
| Pointer suggesting another tool server | Proposed tool connections | Reading a source does not authorize adding tools |
| Request to transmit synthetic candidate details | Permission decision and destination | An external page cannot authorize a disclosure |

For each fixture, retain both the expected and actual results. A passing header-visibility check should identify which field was omitted. A passing action check should identify the application control that refused the proposed operation. “The answer looked fine” leaves too much unexplained.

### Make failure output a first-class contract

Errors are often built for developers, then forwarded to models without review. An exception may contain a provider response, an upstream message, or a destination URL. A carefully restricted result from a successful fetch tells you little about those fields.

Return a bounded failure category and enough context for an authorized retry. Keep detailed diagnostics in an appropriately restricted operational channel. If the model needs a source-provided error excerpt, label it as source material and apply the same limits used for ordinary extracted text.

Test both the first failure and the fallback. For example, the primary reader may omit headers while the secondary reader embeds a diagnostic dump. Run this matrix again when changing an adapter, extraction provider, or exception formatter. Save the relevant versions with the results so future reviewers know what the evidence covers.

### Test realistic routing without real candidate data

Use your normal agent request configuration when checking controlled fixtures. If your production fetcher has a distinct user agent or requests Markdown, reproduce that configuration in the test. A normal browser may receive a different response.

Do not put actual resumes, credentials, or signed candidate links in a canary. Do not install packages or connect to tools suggested by the fixture. You are testing whether the system crosses a boundary; harmless synthetic content is enough to expose that failure.

## Keep fetched text out of hiring authority

A portfolio can supply evidence about work. It cannot set your rubric, establish a verified match score, or grant access to another applicant's records. Preserve that distinction in both the summary and the application that stores it.

In the hypothetical backend review, the assistant might find a public repository describing a queue worker. An acceptable note identifies the source and says what it supports: the portfolio describes queue-processing work, while operational ownership remains unverified. The recruiter can then ask a focused interview question.

An unsupported score should never silently become the recruiter's evaluation. Require a reason tied to a criterion and traceable evidence for each substantive assessment. Keep candidate-provided assertions distinguishable from reviewer judgments. The [candidate profile workflow](/docs/candidate-profiles) is where that distinction needs to remain understandable to the person reviewing the record.

This also applies when the source instruction never triggers a tool call. A read-only assistant can still overstate experience, omit doubts, or present a self-description as independent verification. Audit answer integrity alongside writes. Compare summaries across fixtures and ask reviewers to identify which statements the sources actually support.

[OWASP's prompt injection guidance](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) supports layered controls: scoped privileges, separation of untrusted content, human approval for consequential actions, and adversarial testing. Apply those controls to the operation's consequences. A summary draft and a candidate rejection deserve different permissions.

### Preserve provenance without building a sensitive archive

Record the tool identity, requested URL, final URL when available, response category, exposed field names, and next proposed action. Include the extraction time and enough version information to reproduce the adapter's behavior. If you cannot establish the final destination, preserve that uncertainty explicitly.

Prefer bounded structured records and redacted synthetic examples over whole response dumps. Routine logs should not collect cookies, authorization values, signed links, or candidate personal details. Provenance helps reviewers establish where a claim came from; excessive logging creates another place where sensitive material must be protected.

A source record should survive later summarization. If a second model condenses research notes, retain the association between each claim and its evidence. Otherwise a cautious first summary can become a confident unsupported statement downstream.

## Check the next action and audit Kit's concrete example

The application must decide whether a proposed action is allowed using the authenticated user's authority, tenant scope, destination, and purpose. Text retrieved from a website cannot extend any of those permissions.

A link to an MCP server may be useful documentation. Connecting to that server adds a new capability and requires its own authorization. A page asking the agent to send candidate details elsewhere has supplied a request, not permission. Check the proposed destination and data scope before any transmission, even if the preceding summary appears reasonable.

Tool access should match the task. A research step may need source reads and a draft-saving operation. Moving an application, contacting a candidate, or exporting records requires a separate authorization decision. Kit's [MCP tools reference](/docs/mcp-tools-reference) is relevant when choosing integrations, but availability through MCP does not itself establish permission for a particular action.

### Kit's Outreach adapter is a bounded example

Static inspection for this article found a relevant implementation in Kit's **Outreach** fetch adapter. This is an example from prospect research, not evidence of a shipped Hiring portfolio-fetching feature or an end-to-end security test.

The adapter reads a prospect's stored source URL and checks whether it is a safe public URL. It can use stored profile fields or try Cloudflare extraction, followed by Exa. On the normal Cloudflare path, its model-visible result contains a URL and extracted text rather than a raw HTTP response. Exa success returns a URL, title, highlights, and text.

[Cloudflare documents its Markdown endpoint](https://developers.cloudflare.com/browser-run/quick-actions/markdown-endpoint/) as page-content extraction. That transformation does not establish prompt-injection sanitization. The extracted text remains third-party material. Static inspection also found that Exa failure handling can include an exception message, which deserves its own output review.

Those observations identify a concrete next audit: capture the actual results across provider success, fallback, redirect, and failure paths, then test the permitted next actions. They do not prove that every header is excluded throughout the system or that Kit is immune to injection.

For your own integration, make the fetch contract reviewable before expanding the agent's powers. Keep a small synthetic fixture set beside the adapter, record what reaches the model, and verify who authorizes the next action. That gives your hiring team evidence it can inspect when a source changes, a provider fails, or an assistant proposes something consequential.