This repository is the ACTA documentation site at
docs.acta.build, plus the
@acta-team/docs-mcp MCP server that exposes those docs to AI assistants.
Two different surfaces, one policy. The MCP server is the more interesting one — it is code that runs on developers' machines.
| Component | Version | Supported |
|---|---|---|
Docs site (docs.acta.build) |
currently deployed | ✅ |
@acta-team/docs-mcp |
0.1.x | ✅ |
| Anything older | ❌ |
The site is hosted: we patch forward and redeploy. For the MCP server, only
the latest 0.1.x is supported.
In scope — docs site
- XSS or HTML injection in rendered documentation or search results
- Leaking a secret through the client bundle or build output
- Content injection, or anything letting a third party alter what readers see
- Documented examples that are insecure if copied as written. This is the one we most want to hear about: bad sample code in docs propagates into real integrations. Examples that put an API key in client-side code, skip verification, or disable a security check are in scope even though the site itself is static
- A dependency vulnerability reachable from the deployed bundle
In scope — @acta-team/docs-mcp
- Path traversal or arbitrary file read through the MCP tools
- Prompt injection through documentation content that redirects an assistant, exfiltrates a user's repository, or induces unrelated actions
- The server reaching any network destination other than the documented ACTA docs endpoints
- Command execution, or any capability beyond reading and searching docs
- A published tarball containing files not present in this repository
Out of scope
- Documentation being wrong, outdated or unclear with no security consequence — open a normal issue
- Vulnerabilities in the API, SDK, dApp or contracts, which have their own policies
- Vulnerabilities in MCP clients or the assistants themselves
- Missing security headers with no demonstrated impact
- Automated scanner output with no verified impact
Do not open a public issue for a security report.
Use GitHub's private reporting: Report a vulnerability
Or email acta.xyz@gmail.com with SECURITY in the subject.
Include which surface is affected (site or MCP server), the page or tool, how to reproduce, and what an attacker gains. For MCP issues, the client you used and a transcript help.
| Stage | Timeline |
|---|---|
| We acknowledge your report | Within 5 business days |
| We confirm or reject it, with reasoning | Within 15 business days |
| Fix for a confirmed high or critical | Target 14 days from confirmation |
| Fix for moderate or low | Target 90 days from confirmation |
MCP server issues are treated one severity level higher than the equivalent issue on the site, because that code runs on developer machines with access to their projects.
If we accept it: we fix and deploy or publish, and credit you however you prefer. If insecure example code was live long enough to have been copied, we say so publicly rather than quietly editing the page.
If we decline it: we explain why in writing.
We ask for 90 days or until the fix ships, whichever comes first. If we go quiet, disclose — we will not object.
Code here is MIT, documentation content is CC BY 4.0. Neither grants any right to ACTA trademarks. Security research on this repository is welcome under both.