Trust & Data Handling

AgentPermission is a narrow machine-readable policy check for web-ingestion pipelines. This page describes the current service boundary so you can decide where it belongs in your own controls.

What the check fetches

A check sends the target URL, intended action, policy mode, and agent user-agent to the API. The service uses the target URL to evaluate path rules, but it fetches only these policy documents from the target domain:

  • /robots.txt
  • /llms.txt
  • /.well-known/openterms.json

The permission check does not fetch or store the requested page body. Requests are limited to HTTP and HTTPS, reject private IP destinations, and re-check redirect targets against the same network boundary.

How the signals are interpreted

  • robots.txt controls crawler path access. It is not account authorization or a universal legal permission.
  • Content Signals affect a decision only when a supported value is explicitly present.
  • OpenTerms can supply explicit action-level values declared by the publisher.
  • llms.txt is primarily an AI-readable content map. A title, summary, or link does not grant permission; only an explicit recognized permission directive can affect the decision.

Missing and contradictory signals are handled conservatively according to the requested action and policy mode.

What the service stores

  • The requested URL, action, decision, confidence, risk, reasons, API-key reference, latency, and check timestamp.
  • Fetched policy-document evidence and hashes. Evidence fetched within the last 24 hours may be reused; cached records are replaced when the domain is refreshed.
  • A receipt ID, check ID, signature, and issue time, plus domain-level usage records for account metering.
  • API keys as one-way hashes plus a short display snippet. Cleartext keys are shown only when created.
Do not submit secret-bearing URLs. Full requested URLs are currently stored with check records. Remove access tokens, private query parameters, signed download credentials, and other secrets before calling the service.

AgentPermission does not currently publish a contractual deletion schedule on this site. Contact [email protected] before production use if your organization requires specific retention, deletion, residency, or contractual terms.

How receipts are signed

Receipts contain hashes of the requested URL and policy sources, together with the action, decision, account reference, and issue time. They are signed with HMAC-SHA256 using a key held by AgentPermission.

Validate a complete receipt through POST /v1/verify-receipt or the CLI verify-receipt command. Because the verification key stays with the service, validation is service-backed—not independently verifiable offline.

What a decision does not prove

  • It is not legal advice or a universal determination that an action is lawful.
  • It does not replace authentication, authorization, spending limits, customer policy, or human approval.
  • It does not guarantee that a publisher controls every right implicated by its machine-readable policy files.
  • A receipt records the inputs and decision at check time; it does not guarantee that the source policy remains unchanged.

The API still accepts post and transact for compatibility, but those results only reflect publisher-declared URL signals. They do not evaluate user identity, delegated authority, payloads, budgets, account permissions, or organizational approval policy.

Use AgentPermission as one evidence-producing checkpoint in a web-ingestion pipeline. See the API contract for the exact response fields.