An AI agent calls services all day. A payment API, a data feed, a booking endpoint someone pasted into its tools. Each call is a decision to trust a domain name.
Nobody checks who stands behind that domain. There is usually nothing to check.
A seal for a service
An API seal is the same seal we use for a file, pointed at a web service.
The operator proves control of the domain first. APIR issues a token; the operator serves it as plain text at /.well-known/apir-seal.txt on the domain; APIR fetches it once, over https, following no redirect. Anyone can type a domain name. Only whoever runs it can make it answer.
Then the operator declares what the service is, what it may do and how it handles data, over the exact files that describe it: the OpenAPI spec, the terms, the data policy. Fingerprinted in the browser, sealed on the chain, timestamped by an outside authority each night.
The check is one call
Before an agent or a platform calls a service, it asks:
GET apir.ai/api/seal/api?domain=api.example.com
Free, no key, no account. The answer is every sealed declaration for that domain, who made it, when, and when the domain answered the challenge.
What it proves, precisely
That whoever could make this domain answer, on that date, declared these words over these files.
Control is proven on the date it was given, not today. Domains change hands, and nothing re-checks them yet. The seal keeps saying who held the domain then, which is exactly what a record should do.
What it never proves: that the service works, that it is secure, or that any response it returns came from it. APIR does not test the service. We will not pretend to.
Where it stands
As of today the record of API seals is empty. The rails are built, the lookup answers, and the first seal will be the first entry. I would rather say that plainly than dress up an empty register.
If you run an API that agents call, seal it. If you run a platform that lets agents call APIs, ask the question before the call. It costs nothing to ask.