Data handling and proof boundaries

Use Boundary Guard with clear limits.

Boundary Guard is a pay-per-call API for pre-action checks, source-linked public-data packaging, and receipt evidence. It is not a legal, compliance, financial, medical, or revenue-guarantee service.

Read agent-readable trust JSON Contact support Open buyer quickstart

Data Handling

  • Send only the text, public facts, URLs, domains, known fields, schema, receipt package, or workflow steps needed for the chosen endpoint.
  • Do not send secrets, private keys, passwords, private CRM exports, regulated personal data, medical data, financial account data, or confidential customer records.
  • Lead Brief Lite and Data Enrich Lite use caller-supplied or public-looking input only; they do not claim Apollo, Exa, Firecrawl, Serper, CRM, inbox, or private database lookup.
  • PII Redact and Contact Extract can detect supplied contact details, but callers remain responsible for lawful collection, retention, outreach, and downstream use.
  • Responses include hashes, receipt ids, findings, proof boundaries, and human summaries so agents can preserve audit evidence without exposing raw secrets.

Acceptable Use

Allowed uses

Allowed: pre-action safety checks, JSON/schema repair, PII cleanup, public lead/source brief packaging, workflow audit, receipt verification, and x402 payment-scope checks.

Not allowed

  • Not allowed: using the service to launder private data, bypass consent, create spam lists, impersonate people, automate abusive outreach, or treat receipts as legal certification.
  • Do not route irreversible legal, medical, financial, hiring, credit, insurance, law-enforcement, or high-stakes decisions through Boundary Guard without human review and domain-specific controls.

Payment and Support

Payment notes

  • x402 calls are low-priced, exact pay-per-call API requests on Base mainnet USDC.
  • Preview paths on Vercel exist so buyers can inspect response shape before paying.
  • Internal seed payments are indexing and operational proof only; they are not customer revenue, adoption, ranking, or endorsement.
  • For payment disputes, failed paid responses, or refund requests, contact support with the endpoint, approximate timestamp, non-secret transaction hash if available, and receipt id.

Support path

Email larry@agentmail.to.

Include:

  • endpoint path
  • approximate timestamp
  • receipt id
  • non-secret transaction hash or x402 payment reference when available
  • short description of expected vs actual behavior

Do not send

  • private keys
  • passwords
  • bearer tokens
  • full customer records
  • unredacted regulated personal data

Retention, Availability, and Abuse

Retention and logging

  • Do not send secrets or private records; callers should redact before submitting high-risk payloads.
  • The service returns receipt ids and hashes so operators can keep audit evidence without preserving raw sensitive payloads in public artifacts.
  • Public operator artifacts intentionally publish counters, route health, hashes, receipt ids, and proof boundaries, not private keys, bearer tokens, raw customer payloads, or unredacted regulated personal data.
  • If a support review requires examples, send the smallest redacted payload that reproduces the issue plus endpoint, timestamp, receipt id, and non-secret transaction reference.

SLA and availability

  • No production SLA, uptime guarantee, legal compliance certification, or incident-response guarantee is claimed on the public x402 surface.
  • Use /healthz, /ops-status.json, /market-health.json, and paid-route health artifacts to inspect current operational evidence before depending on the service.
  • High-stakes legal, medical, financial, hiring, credit, insurance, or law-enforcement workflows require human review and domain-specific controls outside Boundary Guard.

Abuse policy

  • Do not use Boundary Guard to generate spam, bypass consent, infer private data, automate abusive outreach, or launder sensitive records into an agent workflow.
  • Do not treat a Boundary Receipt as proof that caller-supplied facts are true; it proves what Boundary Guard checked and returned for the submitted request.
  • Boundary Guard may block, retry, redact, or refuse unsafe patterns, secret-like values, excessive payment scope, or policy-sensitive handoffs.

Proof Boundaries

  • Boundary Guard receipts prove what Boundary Guard checked and returned for a submitted request; they do not prove the truth of upstream caller-supplied facts.
  • x402 payment responses prove settlement when present; Boundary Guard receipts are separate evidence for request handling, policy verdicts, hashes, and recommended next steps.
  • Agentic/CDP indexing, internal seed payments, and live deploy health are operational proof only until non-seed buyer usage is observed.
  • No customer revenue, customer adoption, marketplace ranking, partner endorsement, legal compliance certification, or production SLA is claimed here.

Agent Routing Rules

  • Read /agent-router.json first when choosing an endpoint for a buyer job.
  • Use /buyer-quickstart for a human-safe public link and preview-first paid path.
  • Use /market-health.json for current blockers, revenue boundary, and operator readiness.
  • Hold public claims if they would imply revenue, adoption, endorsement, enriched Agentic metadata, or private upstream data that is not proven.

Updated 2026-06-06. This page is a plain-language operating boundary, not a legal compliance certification.