Security Disclosure Policy

We treat the following as in-scope security vulnerabilities:

• The AINL compiler, interpreter, or runtime — any issue that allows code execution, capability escalation, or sandbox escape
• Core language tooling and adapters — adapter privilege escalation, undeclared side effects, or bypass of the adapter allowlist
• Packaging or dependency integrity — compromised build artifacts, tampered releases, or supply-chain attacks
• Generated artifacts or execution surfaces produced by official AINL tooling
• Training, evaluation, or orchestration components that could introduce meaningful security risk
• ainativelang.com infrastructure — authentication bypass, XSS, CSRF, SQL injection, server-side request forgery, sensitive data exposure, broken access control
• Official release pipelines or distribution mechanisms

The following are generally out of scope unless they create a concrete, reproducible exploit path:

• Feature requests or usability issues
• Performance degradation without a security impact
• Pure correctness bugs with no security consequence
• Risks arising solely from unsafe deployment choices outside official project defaults
• Vulnerabilities in third-party infrastructure not maintained by AINL
• Theoretical issues without a reproducible scenario or clear impact
• Self-XSS or attacks that require physical access to an authenticated user’s device
• Spam, phishing, or social engineering attacks
• Denial-of-service attacks against the public website using automated tools

If you are unsure whether an issue is in scope, send us a brief summary and we will let you know before you invest time in a full report.

Please report suspected vulnerabilities privately using one of the following channels:

Do not open a public GitHub issue, post on forums, or share details on social media until we have had a reasonable opportunity to investigate and ship a fix. Coordinated disclosure protects users who have not yet updated.

The more detail you provide, the faster we can triage and fix the issue. Please include as much of the following as practical:

• Affected component — compiler, runtime, adapter, website, specific file, or release version
• Description of the vulnerability — what it is, why it is a security issue
• Reproduction steps — the minimal sequence of actions needed to trigger the issue
• Proof of concept — code, payload, screenshot, or recording (shared privately)
• Estimated severity — your assessment of impact and exploitability (CVSS score if available)
• Environment details — OS, AINL version, runtime version, container/cloud context
• Suggested mitigations or patches, if you have them
• Whether you intend to publish research about this finding, and your desired timeline

You do not need a complete, polished report to reach out. A brief heads-up with a summary is enough to start the conversation.

These are targets, not contractual guarantees. Our team operates in good faith and will do its best to meet these timelines:

We will keep you informed throughout the process. If we need more information or cannot reproduce the issue, we will say so promptly.

Once a report is accepted as a valid vulnerability, we follow this process:

We consider good-faith security research conducted in accordance with this policy to be authorized and will not initiate legal action against researchers who:

• Report vulnerabilities privately before public disclosure
• Do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the issue
• Do not degrade the availability of our services or affect other users
• Do not use the vulnerability for financial gain or to harm AINL, its users, or third parties
• Comply with applicable laws and act in good faith

This safe harbor applies to research conducted in accordance with this policy. We cannot provide legal protection for activities that fall outside these boundaries or that violate applicable law.

Security fixes are prioritized for:

• The latest stable release of AINL tooling and runtime
• The current development branch, where a fix is feasible

Older versions may receive fixes at maintainer discretion based on severity, active exploit status, user impact, and available bandwidth. We will be transparent about end-of-support timelines for older major versions.

We maintain a Hall of Thanks for researchers who disclose vulnerabilities responsibly. Unless you prefer to remain anonymous, we will credit you in the associated advisory with your name and handle.

We do not currently operate a paid bug bounty program. We offer public recognition and our genuine gratitude. If this changes, we will update this page.