Security fixes are generally provided for the latest version on the default branch.

If you are using an older release, please upgrade to the latest available version before reporting an issue unless the issue prevents upgrading.

Please do not report security vulnerabilities through public GitHub issues, GitHub Discussions, pull requests, or public chat channels.

Report suspected vulnerabilities privately using one of the following methods:

1. GitHub Private Vulnerability Reporting: https://github.com/OpenSourceAGI/dev-tools-starter-agent/security/advisories/new

2. Email: grokthiscontact@gmail.com

Please include as much of the following information as possible:

• A clear description of the vulnerability and its potential impact
• Affected versions, commit SHA, branch, or deployment environment
• Reproduction steps or a minimal proof of concept
• Expected behavior and observed behavior
• Relevant logs, stack traces, or screenshots, with secrets removed
• Suggested remediation, if you have one
• Your preferred contact method and whether you would like credit

After receiving a report, maintainers will aim to:

• Acknowledge receipt within 7 days
• Confirm whether the issue is reproducible and in scope
• Keep you informed about material progress
• Develop and test a fix or mitigation when appropriate
• Coordinate disclosure timing with the reporter
• Publish a security advisory when a fix is available, where appropriate

Response timelines are targets, not guarantees. Complexity, maintainer availability, and downstream dependency coordination can affect resolution time.

Examples of in-scope reports include:

• Exposed API keys, tokens, credentials, or other secrets
• Remote code execution or arbitrary command execution
• Prompt injection paths that cause unauthorized actions or data disclosure
• Server-side request forgery (SSRF), especially access to private networks or cloud metadata endpoints
• Authentication, authorization, session, or access-control bypasses
• Cross-site scripting (XSS), SQL injection, command injection, or path traversal
• Vulnerable dependency configurations with a demonstrated project impact
• Unauthorized access to user data, generated projects, or provider credentials
• Unsafe handling of user-supplied URLs, files, tool output, or web content
• Denial-of-service issues with a realistic and disproportionate impact

Unless there is a demonstrated security impact, the following are generally out of scope:

• Vulnerabilities only affecting unsupported or modified deployments
• Social engineering of maintainers or project users
• Missing best-practice headers without an exploitable impact
• Rate-limit concerns without a practical denial-of-service impact
• Vulnerabilities in third-party services that are not caused by this project
• Reports based solely on theoretical prompt-injection concerns without a reproducible unauthorized action, data exposure, or privilege-boundary bypass
• Automated scanner reports without a clear proof of impact
• Denial-of-service reports requiring unrealistic traffic volumes

Never include real secrets in a report, issue, pull request, log, or proof of concept. This includes:

• API keys and bearer tokens
• LLM-provider, package-registry, and database credentials
• OAuth client secrets and refresh tokens
• Private URLs, deployment credentials, or cloud access keys
• Personally identifiable information

If you accidentally expose a secret in a public GitHub issue, commit, pull request, or discussion:

1. Revoke or rotate the secret immediately.
2. Remove it from the active deployment environment.
3. Contact the affected provider if required.
4. Report the exposure privately using the method above.
5. Rewrite Git history if necessary, but do not assume history rewriting alone invalidates a leaked credential.

Please give maintainers a reasonable opportunity to investigate and address the issue before public disclosure. We will work with you to agree on a coordinated disclosure timeline.

We appreciate responsible disclosure and will credit reporters in a security advisory or release notes when they request it and doing so is appropriate.