Security policy

How to report a vulnerability, what we promise in return, and what is in scope.

Reporting a vulnerability

Email [email protected] with the subject Security Vulnerability - AOTrust. Please include: what you found, how to reproduce it, and what you think the impact is. A machine-readable copy of this policy is at /.well-known/security.txt.

What we commit to

• Acknowledgement within 3 business days, assessment within 10.
• We tell you honestly whether we can fix it and when. No bounty programme exists; we say so rather than imply one.
• We do not pursue researchers acting in good faith. We ask for coordinated disclosure: 90 days, or earlier once a fix ships.

In scope

• api.aotrust.link - receipt issuance, verification, the MCP endpoint, rate limits and payment handling.
• verify.aotrust.link, shield.aotrust.link, docs and the static hosts.
• The receipt format (PDR), the anchor contract notary-node.near, and the notary public key.
• aotrust-protocol, aot-ev1 (PyPI) and the client libraries.

Out of scope

• Findings that need physical access to the operator's machine or a compromised wallet.
• Social engineering of the operator; spam; volumetric DoS.
• «Missing security headers» on static pages with no user data, and automated-scanner output without a reproduction.

Keys and continuity

The notary signing key lives in RAM for the process lifetime and never touches disk; the seed is supplied at start-up. If a key is ever rotated, receipts carry the issuer and the new public key is published at /v1/notary/pubkey and JWKS, and the rotation is recorded in the transparency log. What happens if the service disappears is described in the exit kit.