Security policy
Last reviewed 5 November 2026.
On this page
Report a vulnerability
Write to hello+security@gitring.tech. A person reads every report and answers within three business days. Please do not report a security problem in public first.
The same address is in /.well-known/security.txt (RFC 9116) on gitring.tech, app.gitring.tech and api.gitring.tech.
For anything that is not a security problem (a question, billing, a refund), write to hello@gitring.tech. We answer within two business days.
Tell us:
- What you found and where (URL, API operation, tool name, command).
- Steps to reproduce, with the smallest example that shows it.
- What an attacker gains.
- Your name or handle for the credit, or that you prefer none.
Please verify a report before you send it. A report generated by a tool and not checked by a person, with no working reproduction, will be closed with a short note.
What is in scope
- The hosted service: gitring.tech, app.gitring.tech and api.gitring.tech, its MCP server and git over HTTPS.
- The gitring command line and the SDK.
- The intent protocol itself: tool definitions that let an agent do more than its token allows.
Out of scope: denial of service by volume, findings that need a compromised device of the victim, missing headers with no exploit, and vulnerabilities in third-party services we use (report those to the vendor; tell us if it affects gitring).
Supported versions
| Component | Supported |
|---|---|
| Hosted service | The version deployed now |
| Command line and SDK | The latest published version |
What happens after you report
| Step | Target |
|---|---|
| We answer and confirm we received it | 3 business days |
| We confirm or reject the issue and give it a severity | 5 business days |
| Critical or high severity fixed on the hosted service | 48 hours after confirmation |
| Medium or low severity fixed | 7 days after confirmation, or closed as won't fix with a reason |
| Public advisory | When the fix is deployed, and at most 90 days after the report, agreed with you |
These are targets. We will tell you if we expect to miss one, and why. Severity uses CVSS 4.0 as an input; the final call is ours and we explain it.
Safe harbour
We will not take legal action against research done in good faith that:
- uses only your own accounts and projects, or test accounts we give you;
- does not read, change or delete other people's data beyond the minimum to show the issue;
- does not degrade the service for others;
- gives us reasonable time to fix before you publish.
If you are unsure whether something is allowed, ask first at the same address.
How we handle security
- Every change is reviewed by someone who did not write it, against a threat model that names each threat with its control and its test.
- Development follows NIST's Secure Software Development Framework (SP 800-218).
- An incident that affects your data is handled by a written incident response, which includes the notice GDPR requires.