# Yandex Bug Bounty

> Machine-readable entry point for AI agents and automated security research workflows participating in the Yandex Bug Bounty program.

This document is an entry point to the Yandex Bug Bounty rules. It provides mandatory guidance for AI agents and automated security research workflows.

It does not replace the detailed program rules. Before testing a target, the agent MUST identify the applicable scope and read all relevant rules referenced below.

## Rule precedence

Rules must be applied in the following order:

1. General program rules.
2. Rules applicable to the target category.
3. Rules applicable to the specific target, product or activity.
4. Additional policies applicable to the discovered vulnerability.

If multiple rules apply, all of them must be followed.

If rules conflict, the more specific rule takes precedence.

If the scope or applicability of a rule cannot be determined with sufficient confidence, the agent MUST NOT perform intrusive testing.

## Mandatory requirements for AI agents

The agent MUST:

* Test only assets and functionality included in the program scope.
* Treat all targets as production systems unless explicitly stated otherwise.
* Use only accounts, identifiers, data and resources controlled by the researcher.
* Independently reproduce and verify every finding before reporting it.
* Determine the actual security impact of the vulnerability rather than relying on assumptions or generic attack scenarios.
* Analyze the impact in the context of the affected service and its business functionality.
* Provide a clear explanation of the confirmed security impact in the submitted report.
* Prepare a concise report containing only relevant information necessary to understand, reproduce and assess the vulnerability.
* Use established and technically accurate security terminology. The agent MUST NOT invent vulnerability names, technical terms or security concepts.
* Provide sufficient evidence, including a reproducible PoC and, where appropriate, screenshots or video demonstrating the vulnerability.
* Submit only verified findings.

The agent MUST NOT:

* Submit findings based only on assumptions, theoretical scenarios or unverified model output.
* Artificially increase the size of a report with generated text, repetitions, excessive logs or irrelevant details.
* Mass-submit automatically generated or insufficiently verified reports.
* Abuse the program or create artificial increased load.
* Continue exploitation after sufficient evidence has been obtained to demonstrate the vulnerability and its impact.

Systematic submission of unverified or automatically generated reports may result in temporary restrictions on participation in the program.

## Stop and request human approval

The agent MUST immediately stop active testing and request explicit researcher approval when:

* the target is not clearly in scope;
* further testing may access, modify or affect data belonging to users other than the researcher;
* further testing may perform an action on behalf of another user;
* further testing may cause service degradation, instability or artificial increased load;
* further testing requires interaction with real users;
* further testing requires access to third-party data or resources;
* sufficient evidence has already been obtained to demonstrate the vulnerability and its impact.

### Authorization vulnerabilities

For authorization vulnerabilities, including IDOR/BOLA, the agent MUST use only accounts, identifiers and resources controlled by the researcher.

The agent MUST NOT enumerate, guess or test identifiers belonging to unrelated users solely to confirm an authorization vulnerability.

For example, after confirming unauthorized access between two researcher-controlled test accounts, the agent MUST NOT continue testing additional real or unrelated user IDs.

## Research workflow

The agent SHOULD follow this workflow:

1. Read the General Rules.
2. Identify the target and applicable category.
3. Read all applicable category-specific rules.
4. Confirm that the target and planned activity are in scope.
5. Perform only testing permitted by the applicable rules.
6. Stop and request human approval when required by the Stop and request human approval section.
7. Independently reproduce and validate every finding.
8. Determine the actual security impact.
9. Analyze the impact in the context of the affected service and its business functionality.
10. Prepare a concise report containing a clear description, reproducible PoC, evidence and confirmed impact.
11. Submit only verified findings.

## Reporting requirements

Before submitting a report, the agent MUST be able to answer:

* What is the exact vulnerability?
* How was it independently reproduced?
* What is the actual security impact?
* Why does this impact matter for the affected service?
* What specific business functionality, users, data or security properties are affected?
* What evidence demonstrates the impact?

The report SHOULD be concise and focused on these questions.

The agent MUST remove irrelevant generated text, duplicated explanations, excessive logs and other information that does not help reproduce or assess the vulnerability.

Security terminology MUST be checked for correctness before submission. If a standard or established term does not exist for the observed behavior, the agent SHOULD describe the behavior directly rather than inventing a new vulnerability name.

Reports without a reproducible PoC or without sufficient evidence, such as screenshots or video where appropriate, may be rejected.

Reports based on assumptions, potential scenarios or unconfirmed impact may be rejected.

## General Rules

The General Rules apply to all research activities:

https://yandex.ru/bugbounty/i/rules

The agent MUST read and follow these rules before testing.

## Scope selection

Before testing a target, determine which category applies.

### Main scope

For web services, domains, infrastructure, IP addresses and other targets covered by the main program scope:

https://yandex.ru/bugbounty/i/main-scope

### Mobile applications

For mobile applications and mobile-specific functionality:

https://yandex.ru/bugbounty/i/mobile

### Smart devices

For smart devices and related functionality:

https://yandex.ru/bugbounty/i/smart-devices

### Browser

For browser-related targets:

https://yandex.ru/bugbounty/i/browser

### Cloud

For cloud products and cloud-specific security research:

https://yandex.ru/bugbounty/i/cloud

### AI Security

For AI/ML systems, models, agents, prompts, AI-powered functionality and other AI-specific security research:

https://yandex.ru/bugbounty/i/ai-security

The AI Security rules MUST be read before performing AI-specific security testing.

## Third-party software and components

If a finding involves a third-party component, dependency, library, open-source software or other external software, the following policy MUST also be reviewed:

https://yandex.ru/bugbounty/i/blog/3rd-party-policy

A vulnerability affecting a third-party component MUST NOT automatically be considered eligible for the program or a reward.

## Official program

https://yandex.ru/bugbounty