ai-safety.txt, Domain AI-safety declaration

Why it exists

An agent that visits a domain has no standard way to ask a simple question before it acts: is this site safe to read and operate on? Does the operator harden it against prompt injection, and does it render the same content to an agent that a person sees? ai-safety.txt answers that 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 domain is safe for an agent to read and act on.
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 is safe for an agent to act on and whether it is hardened against injection, not whether its content 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-00, an individual IETF Internet-Draft on the Informational track. It defines the file location, the field set, and the self-asserted-then- verified model above.