OpenTerms Public Alpha: Machine-Readable Permissions for AI Agents

The web has rules, but most of those rules are written for humans. Terms of service, acceptable use policies, and developer agreements assume a reader who can interpret legal text, weigh ambiguity, and decide whether a particular action is allowed.

AI agents are increasingly being used in workflows where permission-sensitive decisions need to be made before the system acts. They may read pages, scrape data, call APIs, create accounts, post content, make purchases, or use web content in AI workflows. In larger systems, these checks can happen repeatedly and at machine speed.

OpenTerms is a public alpha registry of machine-readable permission records for AI agents. It translates a structured subset of permission information from terms of service into a format a developer or agent system can check before acting.

This is a narrow layer, not a complete governance system. It addresses one specific gap: the absence of a structured signal an agent can inspect before deciding whether to scrape, post, train, transact, or call an API.

What OpenTerms is

OpenTerms is a registry. Each entry describes one service and reports the apparent status of seven permission categories. The current alpha registry contains 511 schema-valid service entries.

Each entry follows a fixed schema. The seven canonical permission keys are:

  • read_content — viewing or browsing content on the service
  • scrape_data — automated or programmatic extraction of data
  • api_access — using the service's official API
  • create_account — signing up for an account
  • make_purchases — initiating financial transactions
  • post_content — uploading or publishing content
  • allow_training — third-party use of the service's content for AI model training

Each key carries one of four value types:

  • true means the behavior appears allowed.
  • false means the behavior appears denied.
  • null means unknown, not specified, or not confidently determined.
  • An object such as { \"allowed\": true, \"conditions\": \"...\" } means the behavior depends on stated conditions.

Null is not permission. It is the absence of a clear signal. Agents that interpret null as implicit permission are making the same inference error as agents that scrape any site whose terms do not explicitly prohibit scraping. The structured value reflects what the registry can defensibly say about the service's terms, not what the agent should do in the absence of information.

Why machine-readable permissions matter

A few practical examples.

An agent doing research for a user pulls product specifications from manufacturer websites. Some of those manufacturers prohibit automated scraping in their terms. Others say nothing about it. The agent has no way to tell the difference at runtime without reading every site's terms in full and interpreting them, which is neither fast nor reliable.

An agent posting on behalf of a user submits content to a forum. Some forums permit automated posting under stated conditions. Others prohibit it entirely. The agent has no structured signal to check before submitting.

A retrieval system uses documents from various sources to ground a model's responses. Some sources permit this use. Others explicitly prohibit it. Operational and legal risk for using prohibited sources falls on the organization deploying the system. The system has no efficient way to filter sources based on permission terms.

In all three cases, the actual permission information exists somewhere — in a terms-of-service document, a developer agreement, an acceptable use policy. But it is written for human readers, distributed across multiple documents, and frequently silent on the specific question the agent needs to answer.

OpenTerms provides one structured signal an agent can use as part of its decision logic. Whether that signal is reliable enough to be useful in practice is something the public alpha is intended to test.

What is live in the public alpha

The current registry contains 511 schema-valid service entries. Each entry includes the seven canonical permission keys and associated metadata.

Three public surfaces are available:

  1. Registry search and domain lookup
  2. A REST API for permission checks
  3. A public request form for refresh, correction, dispute, and claim requests

The REST API accepts a domain and action, then checks whether the domain publishes an openterms.json file with a structured permission record. Example:

curl "https://openterms.com/api/v1/check?domain=github.com&action=read_content"

Most domains have not yet adopted the OpenTerms standard, so the typical response during the alpha is noopentermsjson:

{
  "success": true,
  "domain": "github.com",
  "action": "read_content",
  "result": { "value": null, "confidence": null, "caveats": [] },
  "permission": "not_specified",
  "confidence": 0,
  "error": "no_openterms_json",
  "message": "No openterms.json found at github.com. Checked /.well-known/openterms.json and /openterms.json"
}

This is a correct, expected response — not an error. It means the domain has not published machine-readable permissions yet. Agents should treat this as an unresolved signal and fall back to other sources of information. As adoption grows, more domains will serve openterms.json at /.well-known/openterms.json, and the API will return structured permission values instead.

How developers can use it

The simplest pattern is a permission check before an action:

# Before scraping
curl https://openterms.com/api/v1/check?domain=example.com&action=scrape_data

# Before posting
curl https://openterms.com/api/v1/check?domain=example.com&action=post_content

# Before using content for training
curl https://openterms.com/api/v1/check?domain=example.com&action=allow_training

The agent's logic depends on the returned value.

If the value is true, the action appears permitted. The agent may proceed, subject to any stated conditions.

If the value is false, the action appears prohibited. The agent should not proceed.

If the value is null, the permission is unknown. The agent should treat this as a signal to seek other information rather than as implicit permission.

If the value is an object such as { \"allowed\": true, \"conditions\": \"requires API key\", \"requires_auth\": true }, the agent should evaluate the stated conditions. The boolean alone is not enough.

We do not recommend automating high-stakes decisions based on the registry alone. The registry is one input. For decisions with significant operational or legal consequences, review of the underlying terms remains necessary.

The public request workflow

Public users can submit four types of requests through the request form at https://openterms.com/registry/requests/new:

  • Refresh — ask for an entry to be regenerated against the service's current terms
  • Correction — report a specific value the requester believes is wrong
  • Dispute — raise a substantive disagreement with how an entry interprets the terms
  • Claim — indicate that the requester represents the service and wants to participate in the review of its entry

Submissions create pending requests. They do not directly modify the registry. Registry changes require review before publication. This design choice is deliberate. Automatically accepting public submissions would expose the registry to manipulation by parties with an interest in misrepresenting a service's permissions.

Internal AI-assisted workflows help process requests by generating proposed updates and surfacing potential discrepancies. These proposals are not published automatically. They enter the same review process as any other proposed change.

Limitations

The public alpha has known limitations that are worth stating directly.

Registry entries are interpretations of terms-of-service text, not verified facts. Each entry was generated from publicly available terms and reflects the system's best reading of those terms. Some entries may be incomplete, stale, or contested. Registry values should be treated as one input rather than as definitive judgments.

The allow_training field is the most difficult to extract reliably. Terms of service vary widely in how clearly they address third-party AI training, and many are silent. Verify this value against the source terms before relying on it for consequential decisions.

OpenTerms is not legal advice. The registry does not establish whether any agent action is legally permissible. The registry does not satisfy regulatory obligations by itself. Operators of agent systems should consult appropriate legal counsel about their specific use cases.

Public requests do not directly update the registry. Submissions create pending requests for review.

Some services maintain separate developer terms or API agreements that govern agent-relevant behavior. The current registry does not always capture these separate documents. The values reflect what the main terms of service state.

What comes next

The public alpha period focuses on three areas.

First, expanding registry coverage and improving the provenance of existing entries. The current set is biased toward consumer-facing services in English-speaking jurisdictions. Better coverage of vertical-specific services and non-English jurisdictions is a priority.

Second, improving the workflow for processing public requests, with the goal of shorter review cycles for clear-cut cases while preserving careful judgment for contested entries.

Third, refining the schema and permission semantics based on how developers actually use the registry. The seven-key model is a working hypothesis. Real usage will tell us whether the categories are the right ones and whether additional structure is needed.

Service operators who would like to participate directly in their own registry entry can submit a claim request through the request form.

How to engage

Try the registry. Look up a service you care about. If the entry is wrong or stale, submit a correction or refresh request. If the entry seems right, the data becomes more useful as you incorporate it into agent logic.

The schema is at openterms.com/schema/openterms.schema.json. The API documentation is at openterms.com/docs. The request form is at openterms.com/registry/requests/new.

Feedback on the alpha is welcome. A broadly adopted machine-readable permission layer for AI agents does not yet exist. OpenTerms is one attempt at building it. Whether it converges on something useful is a question the alpha period is designed to answer.

OpenTerms is in public alpha. Registry entries are structured interpretations, not verified facts. OpenTerms does not provide legal advice and does not satisfy regulatory obligations by itself. Legal review is required before relying on any registry entry for consequential decisions.