How we report, and how to report to us.

1. CVE assignment scope

If Cognivators is approved as a CVE Numbering Authority (CNA), it will assign CVE IDs for vulnerabilities in MCP servers, AI agent frameworks and related agent tooling that Cognivators discovers or coordinates, when the product is not in the scope of another CNA.

If another CNA has more specific scope over a product, that CNA has first refusal. Google, Rapid7 and GitHub (for repositories that use GitHub security advisories) are examples. We would assign ourselves only if that CNA says in writing that it will not assign. For an issue that is already public, we would also act if the CNA does not answer within 72 hours, and in that case we escalate through the CVE Program's Root as its rules require instead of assigning on our own.

2. Reporting a vulnerability to Cognivators

Send reports to security@cognivators.com. Include the product and version, what the bug is, steps to reproduce, and whether you have reported it anywhere else. You can encrypt with the PGP key below.

What to expect:

• Acknowledgement within 3 business days.
• Within 14 business days, a decision: we request or assign a CVE ID, refer you to the right CNA, or decline.
• If we assign a CVE ID to something you reported, you get the ID.

Who reads it

Cognivators is run by one person. If a report has gone unanswered past the times above, write to anas.syed@cognivators.com. If the founder is away, replies may be slower. For an urgent issue, contact the vendor's own security contact, or the CVE Program's CNA of Last Resort.

We do not pay for reports and do not run a bug bounty.

3. How we report vulnerabilities we find

• Privately first, to the vendor's published security contact, private advisory channel or security.txt address, with affected versions, reproduction steps, impact and a suggested fix.
• The default disclosure date is 90 days after the first report. We extend it when the vendor asks and is making visible progress on a fix.
• We try twice, through two different channels, before treating a vendor as unresponsive. If both attempts get no reply by the disclosure date, we publish an advisory and request or assign a CVE ID as described in section 1.
• We publish sooner if the issue is already public or being exploited.
• We do not publish exploit details for an unfixed issue while the vendor is working on it in good faith.
• We test only software we run ourselves or read in public source. We do not test systems we do not own or are not authorised to test.

4. CVE ID requests from third parties

Once we are a CNA, anyone can ask us for a CVE ID for an issue inside our scope, using the address in section 2. There are no terms or conditions on that request beyond this policy. We will ask whether you have already requested an ID from another CNA. If so, we coordinate with that CNA and may defer to it. If the product is in another CNA's scope, we refer you to it or notify it ourselves.

We assign one CVE ID per independently fixable vulnerability. If we are unsure whether two issues are separate, we assign one ID.

5. Other CNAs and duplicates

Before assigning, we check the CVE List, the vendor's advisories and GitHub's advisory database for an existing ID. If an affected vendor is not a CNA, we make a good-faith attempt to notify it before publishing. If an issue falls in more than one CNA's scope, we work it out with the other CNA. If we cannot, the Root we share decides.

6. CVE record content

Every record we publish names at least one affected product and version, states the weakness type (a CWE where one fits), carries a plain description, and links to at least one public reference that is not the CVE record itself. The record is never the first public disclosure. We publish the record within 72 hours of the issue becoming public. Credit goes in the credits field, not the description.

7. Corrections, updates, rejection, disputes

• Send corrections to security@cognivators.com. We update a published record when material information changes, such as a fix shipping, or when something in it is wrong.
• We reject a CVE ID if no vulnerability exists, the ID is a duplicate, or the ID was never used. Every rejection states a reason.
• If you disagree with an assignment, a determination or a record, write to us first. If we cannot resolve it, the CVE Program's policy and procedure for disputing a CVE Record applies, and the record carries the disputed tag with an explanation while that runs.

8. Credit

We credit reporters by name or handle in our advisory and in the CVE record credits, unless they ask not to be named.

9. Safe harbor

This covers only what Cognivators controls. We will not take legal action against anyone who, in good faith, reports a vulnerability in software Cognivators itself publishes (for example mcp-safeguard), does not access or alter data beyond what is needed to show the issue, and gives us reasonable time to fix it. We cannot grant safe harbor for testing any third party's systems. That is up to the owner of those systems, so read their policy before testing.

10. Advisories

Published advisories that credit the founder are indexed on the advisories page.

11. Changes

The version and date at the top change when this policy does. Earlier versions are available on request.