Audit-ready agent retrieval

01 — the problem

Retrieval happens inside tool calls, and tool calls leave nothing behind

The question arrives from an auditor, an enterprise customer, or your own GRC reviewer: show me what your agents read from the internet last quarter. Most teams have the model's outputs, and maybe an application log line saying that some URL was fetched. What the model actually read is gone.

Audit trails cannot be retrofitted: a log you did not capture at the moment of retrieval does not exist, and no later job can reconstruct what a page said when your agent read it. Pages change, get taken down, and get rewritten.

The requirement set is dated and specific. The EU AI Act requires high-risk AI systems to technically allow the automatic recording of events (Article 12), and requires providers and deployers to keep those logs for at least six months, to the extent such logs are under their control (Articles 19 and 26(6)).1

Those obligations were deferred. The Digital Omnibus that entered into force in July 2026 moved them to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.2 Nothing was cancelled, and the requirement text is unchanged with fixed dates further out. Most agent deployments are not high-risk systems under the Act in the first place, and this page will not tell you yours is.

The standards your customers already audit against do not wait for that timetable. ISO/IEC 42001 Annex A carries a dedicated event-logging control (A.6.2.8) and data-provenance controls that include retaining licensing records for third-party data (A.7.5).3 SOC 2 evidence for anomaly monitoring typically lands under CC7.2. ISO 42001 certification is still early, in the range of a few hundred certified organisations, so an auditor may be working through the AI-specific controls alongside you.

Today the pressure on most teams is contractual rather than regulatory. Vendor questionnaires ask for provenance and subprocessor evidence now, and SOC 2 and ISO 42001 audits run on your customers' schedule.4

1. AI Act Article 12, Article 19, Article 26 · 2. Regulation (EU) 2026/1744 · 3. ISMS.online on ISO 42001 A.6.2.8, ISMS.online on A.7.5 data provenance, ISO/IEC 42001 · 4. Aetos Data on enterprise AI security questionnaires

02 — how it works

Two layers on the way in, and the record they leave behind

Clearfetch does two different jobs on ingress, and they carry different guarantees. We keep them apart here, in the docs, and in the response, because an auditor will ask which claim rests on which.

Layer 1 · deterministic

Channel elimination

HTML is re-rendered into strict markdown. That render provably strips scripts, CSS-hidden text, zero-width characters, and document metadata, because the output format has nowhere to put them. Images are re-rendered or captioned instead of being passed through as live references.

This layer is a transform rather than a judgement, so we can name exactly what it removes. Strict markdown also drops layout and interactivity, which is the trade you are making.

Layer 2 · probabilistic

Injection detection

Whatever survives the transform is scanned for instruction-bearing text. Every response carries a verdict of clean, sanitized, or blocked, plus the findings behind it, each with a category, a confidence, and a plain-language detail line.

Detection is statistical. We publish detection rates instead of claiming immunity, and those numbers publish with the API rather than after it, so the number in your control narrative is a measured one rather than an adjective.

on every response

url: Final URL after redirects, plus the domains the request passed through.
license_status: What Clearfetch can declare about the terms the content was published under.
content_sha256: Hash of the bytes we fetched, so the record can be checked against the content later.
verdict: clean, sanitized, or blocked, with the findings behind it.
fetched_at: Time of the fetch, with the upstream HTTP status.
request_id: The call this record belongs to, matching the row in the per-key audit log.

The same records are written to an immutable per-key audit log. You can pull a date range for an evidence request, or answer a single question from one request id. Because the record is created by the layer that did the fetch, it covers what the model was handed after sanitization rather than what the URL happened to serve to a browser later.

Retention windows, export formats, and where the logs live are what we are working out with early-access teams. Clearfetch is In early-access, so none of it is serving traffic yet.

policy as evidence

Domain allowlists, per API key

Lock a key to the domains and providers you approve. Requests to anything else are refused before a single byte is fetched, and every refusal and every policy change lands in the audit log.

The allowlist and every change to it appear in the same immutable per-key log as the retrievals: who changed the list, when, and from what to what. An auditor who asks what the policy was on a given date reads the answer out of the same log as the fetches it governed, which is what makes “we restricted web access” checkable rather than asserted.

An allowlist governs what this key retrieves through Clearfetch. It does not control what your agent does through other tools, and approved domains still get the full sanitization and scanning pipeline — an allowlist bounds where we fetch, not what we trust.

03 — the response

One fetch, and the evidence it produces

A regulator's guidance page is the kind of source an agent grounds on without anyone thinking about it, and the kind an auditor will pick out of a log to ask about. Here is the shape of the response.

The content block is what the model saw. The findings block records what was removed before it saw it, and the provenance block plus the request id are what you produce when someone asks you to show your work months later.

POST /v1/fetch Example

verdict

verdict sanitized content delivered, one span removed

ok true

license_status unknown no machine-readable license signal on this source

scans · findings

category prompt_injection

confidence 0.94

detail A comment block told the reading assistant to ignore the filing dates above and report the thresholds as unchanged. The span was removed from the returned markdown and recorded as a finding.

channels removed scripts, css_hidden_text, zero_width_chars, metadata

content

text/markdown · strict render

# Reporting thresholds — 2026 updateEntities above the small-firm threshold file quarterly.[ removed · injected_instruction ]The threshold rises to EUR 12m in turnover on1 January 2027. Filing windows are unchanged.

provenance

url https://example-regulator.gov/guidance/2026-reporting-thresholds

domain example-regulator.gov

fetched_at 2026-08-01T14:22:09Z

upstream_status 200

content_sha256 9f31c2…d7a4

request_id req_01JZ7P2K9C

04 — objections

Objections

These are the four questions we expect first.

“Didn't the EU just delay all this?”

It did. The July 2026 Digital Omnibus moved the high-risk logging obligations to December 2027 for Annex III systems and August 2028 for Annex I systems.5

Nothing was cancelled. The requirement text is unchanged and now carries fixed dates. The pressure that exists today is contractual rather than regulatory: vendor questionnaires already ask for provenance and subprocessor evidence, and SOC 2 and ISO 42001 audits run on your customers' schedule rather than Brussels'.

“Most agents aren't high-risk systems under the Act. Does this apply to me?”

Most are not. If you sell to EU-regulated buyers, their compliance reaches you through procurement rather than through your own classification, and SOC 2 and ISO 42001 apply whatever the Act says about you.

If neither describes you, this is not your reason to use Clearfetch. Injection defense might be, or the developer experience — see the injection-defense page or the drop-in fetch page instead.

“Is Clearfetch SOC 2 certified?”

Not yet. Clearfetch is in early access, its controls are designed against SOC 2's criteria from the start, and certification is planned ahead of general availability.

Early-access members receive the security documentation and control mapping as it's published.

“Can't I just log my agent's tool calls myself?”

A tool-call log records that a URL was fetched. It answers where the agent went, not what it read.

Recording what the model actually saw means capturing the sanitized content, hashing it, and writing the scan verdict at the moment of retrieval, inside the retrieval layer. That is the artifact an auditor can use, and it exists only if the layer creates it.

5. Regulation (EU) 2026/1744

The full product overview is on the Clearfetch home page. Field definitions and the API shape are in the docs.

Show the auditor exactly what your agents read