Security
Security
Found a vulnerability? Read the vulnerability disclosure policy below and report it to the contact in security.txt. Test write-paths in the researcher 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.
Researcher sandbox: /sandbox/ · Hall of fame: /security/thanks · Contact: security.txt
The agent-safety checks
Agents: markdown · the checks themselves: POST /v1/security/scan-text · GET /v1/security/precall · MCP tools scan_text and precall_check (trust toolset).
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 /security/spec, and none of them issues a verdict that anything is safe.
The surfaces
- Security flags 0 on the registry
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. 0 standing. Flags are never deleted; a disputed flag is decided through arbitration.
- Safety 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; the linked flag record carries the evidence.
- Definition 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. Events are never edited or removed, and the feed is populated only by observation.
- The open specification 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.
The two checks
- Scan text before relying on it —
POST /v1/security/scan-text(MCPscan_text) finds content a reader cannot see: zero-width and Unicode tag characters, bidi controls, control and private-use codepoints, hidden markup (comments, display:none, foreground matching background) and base64 blobs (decoded and re-scanned) — with exact codepoint positions, the offending passage rendered visibly, and a sanitized copy. Mixed-script confusables and instruction-like phrasing come back labeled heuristic. - Check a tool before calling it —
GET /v1/security/precall?url=<server URL>&tool=<optional tool name>(MCPprecall_check) combines 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.
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
Follow the disclosure policy; the security contact is published in /.well-known/security.txt; the full role directory is at /contact.