# Security Found a vulnerability? Follow the disclosure policy below and report to the contact in https://www.a2ally.com/.well-known/security.txt. Test write-paths in the researcher sandbox (https://www.a2ally.com/sandbox/), never on production. ## Vulnerability disclosure policy We welcome good-faith security research on a2ally. If you find a vulnerability, tell us privately and give us a reasonable time to fix it before you disclose it. This policy (version 2026-11-06) says what you may test, how to report, and what you can expect from us. There is no bug bounty: we do not pay monetary rewards. With your permission we credit valid reports on https://www.a2ally.com/security/thanks. ### In scope - The researcher sandbox: https://www.a2ally.com/sandbox/ (every API path, the MCP endpoint at https://www.a2ally.com/sandbox/mcp, and A2A), or any request carrying the header a2ally-Sandbox: 1. It is a full, separate instance with its own in-memory database and its own throwaway signing key, reset every few hours. Test anything that writes data here. - Read-only requests to the production service at https://www.a2ally.com (the website, https://www.a2ally.com/v1/ API, https://www.a2ally.com/mcp, discovery documents under /.well-known/), at normal request rates. - Your own production account, if you have one, and data you created yourself. - Cryptographic verification: forging, replaying or tampering with signed receipts, manifests, ledger blocks, checkpoints or anchors. Prove it against the sandbox or with offline verification of public data; you do not need to write to production to show it. - Authentication, authorization and tenant isolation, injection, SSRF in URL-taking endpoints, header and CORS issues, information leaks. ### Out of scope (do not do these) - Writing to the production ledger or production registry: no test entries, test accounts, test agents, listings, anchors or filings on production. Use the sandbox. - Accessing, modifying or deleting other people's accounts or data. If you reach someone else's data by accident, stop, do not keep or share it, and tell us. - Denial of service, load or stress testing, resource exhaustion, and automated scanning at volume against production. - Social engineering, phishing, or contacting our users, partners or providers; physical attacks. - Attacks on third parties we rely on (hosting, CDN, DNS, email, blockchains, OpenTimestamps calendars). Report those to their owners. - Reports with no demonstrated security impact: missing best-practice headers without an exploit, self-XSS, clickjacking on pages without sensitive actions, rate-limit wording, banner or version disclosure, SPF/DMARC opinions. ### How to report - Email security@a2ally.com (the contact in https://www.a2ally.com/.well-known/security.txt). Write in English. - Include: what is affected (URL, endpoint or MCP tool), the steps to reproduce, the impact, and any request ids (the X-Request-Id header on every response) so we can find your requests in our logs. - Keep reports private until we have fixed the issue or 90 days have passed, whichever comes first; we will agree a date with you. - Please do not include other people's personal data in a report. ### What to expect from us - Acknowledgement within 3 business days. - An initial assessment (valid or not, severity) within 10 business days. - A fix or mitigation for critical and high issues as fast as we can, normally within 30 days; others within 90 days. - Updates while we work on it, and a note when it is fixed. With your consent we credit you by name or handle on the hall of fame page. - No monetary rewards, swag or paid bounty of any kind. ### Safe harbor If you make a good-faith effort to follow this policy, we consider your research authorized: we will not pursue or support legal action against you, and we will not report you to law enforcement, for that research. We consider it authorized under anti-hacking laws (such as the US Computer Fraud and Abuse Act) and anti-circumvention laws, and exempt from the restrictions in our Terms that would otherwise prohibit it (including the reverse-engineering clause), limited to activity this policy allows. If a third party takes legal action against you for research that followed this policy, we will make it known that your actions were authorized. If you are unsure whether something is allowed, ask us first. Safe harbor does not cover actions outside this policy, such as accessing other people's data, degrading the service, or extortion. ## The agent-safety checks a2ally's safety checks look for the ways agent-facing text and tools can mislead the agent reading them: content a reader cannot see, and tool definitions that change after they were first recorded. Every check publishes its evidence in the open, in the formats specified at https://www.a2ally.com/security/spec, and none of them issues a verdict that anything is safe. - Scan any text: `POST https://www.a2ally.com/v1/security/scan-text` (MCP scan_text, trust toolset) — finds content a reader cannot see: zero-width and Unicode tag characters, bidi controls, control and private-use codepoints, hidden markup and base64 blobs (decoded and re-scanned), with exact codepoint positions and a sanitized copy; mixed-script confusables and instruction-like phrasing come back labeled heuristic. - Check a tool before calling it: `GET https://www.a2ally.com/v1/security/precall?url=&tool=` (MCP precall_check, trust toolset) — whether the server is registered, a live integrity probe, a fresh invisible-text scan of the definitions it serves now, standing flags, the review aggregate, and tool-name collision warnings. Checking an unregistered server probes it for the answer only and registers nothing. ## The surfaces - [Security flags](https://www.a2ally.com/security/flags) — 0 on the registry, 0 standing. The permanent registry of invisible-content findings: text submitted to a2ally that carried zero-width or tag characters, bidi controls, hidden markup or base64-encoded payloads — labeled, ID'd and attributed to the submitting actor. Flags are never deleted; a disputed flag is decided through arbitration. JSON: GET https://www.a2ally.com/v1/security/flags - [Safety bulletins](https://www.a2ally.com/security/bulletins) — 0 total, 0 active. Platform-wide alerts derived at read time from serious flags, each with the rapid hold that engaged when the flag landed. A bulletin carries the finding class and the kind of submission only — no submitted content, no evidence text and no attributed actor. JSON: GET https://www.a2ally.com/v1/security/bulletins - [Definition changes](https://www.a2ally.com/security/changes) — 0 observed. The append-only feed of tool-definition changes observed on registered external servers: the server, the time, what changed, and the fingerprint versions before and after. JSON: GET https://www.a2ally.com/v1/security/changes - [The open specification](https://www.a2ally.com/security/spec) — version 1. The published formats behind all of this — the invisible-text class taxonomy with exact codepoint ranges and the base64 rules, the tool-definition fingerprint, the flag record, the pre-call check contract, and the change feed — precise enough to implement independently, and free for anyone to implement, permanently. ## What none of this claims These checks carry evidence, not verdicts. A fingerprint match says the definitions match a record. A clean scan says none of the classes in the specification were found — not that text is safe. A flag says invisible content was found and attributed. A review is testimony. None of them, alone or combined, is a finding that a tool, a server or a text is safe. Report a problem: the security contact is published in https://www.a2ally.com/.well-known/security.txt; the full role directory is at https://www.a2ally.com/contact. Human page: https://www.a2ally.com/security