ai-safety.txt: Domain AI-safety declaration

Why it exists

An agent that visits a domain has no standard way to learn, before it acts, what the domain claims about the content it serves. Does the domain author or review that content, and does it publish none of it with intent to harm the agent? Does the operator harden that content against prompt injection, and does the site render the same content to an agent that a person sees? ai-safety.txtcarries the domain's answers in the same shape the web already uses for machine-readable site policy. It is a small, robots.txt-style file a domain publishes at /.well-known/ai-safety.txt, where the site states its AI-safety posture to consuming agents.

The file it publishes

The format is line-oriented Field: value pairs, readable by a person and trivial to parse. Comments begin with #. A domain publishes one file at a fixed, discoverable path.

/.well-known/ai-safety.txttext

# /.well-known/ai-safety.txt
AI-Safe: true
Injection-Protected: true
Consistent-Rendering: true
Contact: https://example.com/ai-safety
Attestation: https://example.com/.well-known/ai-safety-attestation.json
Last-Verified: 2026-07-06

The six fields

The record carries three boolean posture claims, two links, and a date. A consumer reads them together: the booleans say what the domain claims, and the links say how to check it.

AI-Safe: Boolean. The operator asserts the content the domain serves is authored or reviewed by the domain, is not user-generated, and is not published with intent to harm a consuming agent. The field asserts provenance and intent, not immunity: AI-Safe: true does not assert the content is harmless to process.
Injection-Protected: Boolean. The operator asserts the domain hardens its content against indirect prompt injection.
Consistent-Rendering: Boolean. The operator asserts an agent is served the same content a person sees, with no agent-specific cloaking.
Contact: URI. Where to report a safety issue or reach the operator about this declaration.
Attestation: URI. A link a consumer follows to verify the claims, rather than trusting the file on its own.
Last-Verified: ISO 8601 date. When the operator last checked the posture the file declares.

Self-asserted, and how a consumer verifies

The file is a declaration, not proof. Every boolean in it is the operator's own claim, so an agent should treat the file as a hint, not evidence. The check lives at the Attestation link: a consumer resolves it to confirm the posture against something the domain cannot simply assert about itself, and weighs the Last-Verified date when deciding how fresh that check is.

Caution

A claim is not a verification

A domain that sets AI-Safe: true has said so, nothing more. The value of the file is the discoverable, machine-readable shape and the Attestation pointer, not the boolean on its own. A consumer that acts on the boolean without following the attestation is trusting an unverified self-assertion.

Not the same as usage preferences

The IETF AIPREF working group is standardizing how a site expresses preferences about automated use of its content, for example whether pages may be used for training, surfaced through mechanisms in the robots.txt and ai.txt family. That is a usage and licensing signal about content.

ai-safety.txt is orthogonal. It declares a safety posture, whether the domain authored or reviewed the content it serves and publishes none of it with intent to harm an agent, and whether that content is hardened against injection, not whether it may be reused. A domain can publish both: an AIPREF-style usage policy and an ai-safety.txt posture, and they answer different questions.

Note

Status

ai-safety.txt is filed as draft-fane-ai-safety-txt-01 (filed 2026-07-23), an individual IETF Internet-Draft with intended status Informational. It defines the file location, the field set, and the self-asserted-then- verified model above.