Docs  /  Abuse Policy

Abuse Policy

ObligationSign's free tier is governed by adaptive abuse controls. Honest usage is unaffected. This page explains the posture at the architectural level so reviewers, customers, and legitimate users understand what a rate-limited response actually means — and what it does not mean.

What we protect against

Cryptographic governance infrastructure is a high-value target for the same reason it is a useful product: a credential that signs governance leaves on someone else's quota is worth taking. Industry framing of this risk has been articulated most clearly by Patrick and John Collison in the context of payments-platform token theft — sophisticated actors farm free-tier identities, automate token burn against legitimate APIs, and exfiltrate the resulting capacity at scale.

We treat the same three abuse vectors as in-scope:

How we approach it

AGTS provides pre-execution governance rather than post-hoc fraud detection. The same primitive that anchors AI actions cryptographically also enables real-time policy decisions about whether an action proceeds. Free-tier abuse control is one application of that primitive; supply-chain integrity, runtime trust verification, and tenant accountability are others.

Concretely, this means: a governance request is evaluated before the protected action is admitted to the canonical log, not flagged after the fact. Where post-hoc systems look at completed transactions and try to identify which ones were fraud, AGTS evaluates the eligibility of the request itself and returns a determination. The same machinery that produces the Merkle-anchored evidence trail produces the abuse-control decision.

We do not publish specific thresholds, key names, cooldown durations, or detector mechanics on this page. That is deliberate: telling legitimate users that protections exist is useful; telling adversaries exactly where the wall is, is not.

Identity recovery

AGTS provides cryptographic non-repudiation of tenant actions; recovery from loss of the underlying email identity requires the identity provider's recovery flow (Google account recovery, IdP-specific flow). Substrate-level recovery of canonical identity isn't structurally possible without weakening the non-repudiation property the substrate exists to provide. Substrate-issued credentials (API keys, signing tokens) are fully rotatable; only loss of the upstream identity-provider account itself is out of scope. See the canonical statement of the CF Access identity-recovery limitation (docs/CF_ACCESS_IDENTITY_RECOVERY_LIMITATION.md) for the full rationale.

What you should know as a legitimate user

Honest usage is unaffected. If you ever hit an abuse-control response during legitimate work, contact support@obligationsign.com with the trace ID from the response — false positives are reviewed and reversed quickly, and reversed decisions do not require you to re-register or re-pay.

← Pricing Start free trial → Read the specification →