Security Policy

We handle two kinds of security report:

• A problem in Agent Mart itself: the website, API, MCP server, CLI, badges or our infrastructure.
• A problem in a tool we list: an MCP server, skill, plugin, agent or any other listing.

We built Agent Mart to help people pick safe tools, so we take both seriously.

• Report form: https://agentmart.dev/submit?kind=report. Choose a listing if the report is about one.
• Email: [RAHIL: security contact mailbox, e.g. security@agentmart.dev]. [RAHIL: PGP key or other encrypted channel, if any.]
• security.txt: https://agentmart.dev/.well-known/security.txt [RAHIL: not published yet; Day 23 task 16.]

Please include:

• what is affected (URL, endpoint, CLI version, or listing)
• steps to reproduce
• the impact you expect
• how to reach you

For listed tools, a link to the exact version, file or tool description helps. Please do not put exploit code or secrets in public places, including GitHub issues.

Response target: a person replies within 24 hours. We tell you what we will do next and keep you updated at least every [LAWYER: 7] days until the report is closed.

If you make a good faith effort to follow this policy while researching Agent Mart, we will:

• consider your research authorized
• not pursue or support legal action against you for it, including under anti-hacking laws (such as the US Computer Fraud and Abuse Act or India's Information Technology Act, 2000) or for breaking our Terms of Service (/legal/terms) in a way the research required
• work with you to understand and fix the problem quickly
• credit you publicly if you want, once it is fixed

Good faith means you:

• test only against your own accounts and data, or with permission
• do not access, change, keep or share other people's data; if you reach any, stop and tell us
• do not degrade the service: no denial of service, load testing, spam or social engineering of our staff or users
• respect rate limits, and do not use automated scanners beyond them
• do not attack our providers (Supabase, Vercel, Cloudflare and others); they have their own programs
• give us reasonable time to fix the problem before you disclose it, and agree the date with us

We cannot authorize research on systems we do not own, including listed tools and our providers. If a third party takes legal action against you for research that followed this policy, we will make it known that your work was authorized by us.

[LAWYER: enforceability and wording of the safe harbor, especially under Indian law where computer-misuse offences may not be waivable by the system owner. Confirm we can promise not to "support" action by others.]

We do not run a paid bug bounty at this time. [RAHIL: confirm.]

Agent Mart scans listed tools and receives reports from the public. For a serious issue in a listed tool:

We confirm it first. Someone re-reads the evidence before a critical finding counts as confirmed.

We tell the maintainer privately. We use the first channel that exists, in this order:

• GitHub private vulnerability reporting
• the email in the project's SECURITY.md
• the publisher's security.txt
• a public maintainer contact from the package registry

We never use a public issue for this. Nothing is sent without approval from a person at Agent Mart.

The 21-day rule. We make no public mention of a confirmed critical issue for at least 21 days after we first contact the maintainer, or until it is fixed. The maintainer can ask for more time, and we will usually agree when they are working on a fix. [RAHIL: confirm the reading of "21 days or until fixed": if a fix ships on day 3, may we mention the issue then? Also confirm whether the security grade itself changes during the private period.]

Malicious tools are different. If a tool is malicious, for example it steals credentials or hides a backdoor, we take the listing down at once to protect users, and contact the maintainer or registry as well.

If you found it. Report it to the maintainer yourself, or ask us to. We will help reach the maintainer privately, and we credit you if you want.

Lower-severity alerts follow fixed delays:

• medium alerts, such as a tool's permissions changing between versions, become public 24 hours after they are raised
• high alerts become public after 21 days
• critical issues follow the private disclosure process above

• Grades, not exploit details. Listing pages show an automated security grade and the number of findings by severity. Alerts show a one-line summary once their delay has passed. We do not publish exploit code, payloads, secrets, file and line evidence, or step-by-step reproduction. [RAHIL: confirm what a listing page shows once a critical issue's disclosure period ends.]
• Removals: we keep a public log of removed listings, also available as a feed at /security/feed.xml.
• Fixed issues: once a fix is released, the grade updates on the next scan and the alert notes the fixed version.
• Problems in Agent Mart itself: if a vulnerability affected users' data, we tell affected users and authorities as the law requires (see the Privacy Policy), and publish a short note in our changelog.

Grades are automated assessments, not guarantees. A grade reflects public signals and automated scans at a point in time. It is not an audit, a certification or an endorsement. A good grade can miss a problem, and a poor grade can be a false positive. Maintainers can ask for a re-check through the correction form.

Money never changes organic rank or grades. No payment, sponsorship or partnership affects a security grade or how we disclose an issue.

For Agent Mart itself, these are usually out of scope unless you show real impact:

• missing security headers on pages without sensitive actions
• clickjacking on pages without state-changing actions
• reports from automated scanners with no proof of impact
• rate limits that can be exceeded with high-volume traffic (denial of service)
• issues that need a compromised device or browser
• self-XSS
• SPF, DKIM and DMARC settings on domains that do not send mail
• vulnerabilities in listed tools: report them under section 4 instead

1. [LAWYER] Update frequency we commit to for open reports (section 2).
2. [LAWYER] Enforceability and wording of the safe harbor under US and Indian law; whether we can promise not to support action by others (section 3).
3. [RAHIL] Security contact mailbox and any encrypted channel (section 2).
4. [RAHIL] Publish security.txt once approved (section 2).
5. [RAHIL] Confirm there is no paid bug bounty (section 3).
6. [RAHIL] Confirm the reading of "21 days or until fixed", and whether the grade changes during the private period (section 4).
7. [RAHIL] Confirm what a listing page shows once a critical issue's disclosure period ends (section 5).