ZCode Vulnerability Handling and Reward Principles

1. These rules apply to the latest stable releases downloaded from official ZCode channels, including:
   • the official ZCode desktop client;
   • the CLI, IDE plugins and official extensions.
2. Official download site: zcode.z.ai.
3. A vulnerability must be reproducible on the latest stable release publicly available at the time of submission. Issues that only affect old, beta, development or unofficially modified builds are generally not accepted.
4. Generic vulnerabilities in third-party operating systems, browsers, IDEs, open-source components or cloud services are out of scope. If such an issue actually affects the security of ZCode users through ZCode's integration, configuration or business logic, you may submit it for assessment.

ZCode uses the following criteria to recognise and verify product vulnerabilities:

1. The issue falls within ZCode's product security responsibility. It originates from ZCode's code, configuration, architecture, authentication, permission design, tool calls, sandbox isolation, update mechanism, or components and integrations that ZCode ships or maintains. For issues triggered by dependencies or model behaviour, the deciding factors are whether ZCode has a flawed security control and what the actual impact is.
2. It has a demonstrable security impact. It breaks a security boundary such as identity, authorisation, permission confirmation, execution isolation or data access, or disrupts service availability. Types include, but are not limited to: unauthorised code or command execution, sandbox escape, privilege escalation, bypassing workspace trust or action confirmation, unauthorised tool or MCP calls, leakage of sensitive code or keys, cross-account or cross-tenant access, tampering with update and supply-chain mechanisms, and denial of service with real impact.
3. It can be verified under clear conditions. It reproduces on the latest official release, a still-supported release or an official online service, using the default configuration or a normal configuration that ZCode supports. The report should state the version, model, configuration, attack preconditions and the user interaction required. Where model randomness or race conditions are involved, include the number of attempts, the number of successes and records of the successful runs; the issue does not need to trigger every time to be accepted.
4. The report includes enough material to verify it. Include complete reproduction steps, the attack entry point and attacker-controlled content, expected and actual behaviour, the security boundary that was broken, the impact, and any samples, logs or screen recordings needed. For prompt injection, include the prompts, external content and tool-call records. Reports with insufficient material go through supplementary verification rather than being dismissed outright.
5. Boundaries for AI agent issues. Prompt injection, context poisoning and poisoned tool output can be attack entry points. When they lead to real security impact such as unauthorised tool calls, data access or exfiltration, or code execution, they are assessed as product vulnerabilities. Issues that only change the model's role or produce wrong answers, policy-violating text or ordinary hallucinations, without such impact, are handled as model safety or output quality issues. Normal operations the user explicitly authorised, and demonstrations that a security control fails only after you turn that control off yourself, are not bypasses of that control.

ZCode uses the following criteria to recognise and verify privacy vulnerabilities:

1. Unauthorised or out-of-scope data collection. Reading, collecting or uploading user code, files, conversations, keys, account information, activity records or similar data without the required authorisation, after the user has refused it, or beyond its explicit scope.
2. Unauthorised data use and sharing. Using user data for model training, product improvement, behavioural analysis or other purposes outside the authorised scope, or transmitting or sharing it with unauthorised third parties, model services, plugins or MCP services.
3. Leakage and unintended exfiltration of sensitive data. Code, credentials, conversations or other sensitive data reaching unintended recipients because of flaws in logs, telemetry, error reports, debug output, tool calls or official integrations. Leakage triggered through prompt injection, context poisoning or poisoned tool output is assessed as well.
4. Failed access control and isolation. Flaws in authentication, permission checks, account or tenant isolation, caching or storage permissions that let unauthorised users, processes or services access other users' data.
5. Failed privacy settings or consent controls. Processing that continues after the user turns off data collection, withdraws consent or leaves a data improvement programme, or controls such as local-only processing, no-upload or restricted sharing that do not work as described. Triggering a data collection mechanism that was declared removed is also in scope.
6. Failed retention and deletion. Data kept beyond the stated period or scope, or data that can still be accessed, restored into production systems or used after the promised deletion time. Whether historical data was handled properly is verified independently and is not excluded just because the latest version stopped collecting it.
7. The report includes enough material to verify it. State the affected version or service, configuration, consent and privacy setting states, reproduction steps, data types, data flows and actual impact, with the necessary evidence. You may use test accounts and simulated sensitive data to prove the risk; you do not need to obtain or disclose anyone else's real data. Where model randomness is involved, state the number of attempts, the number of successes and the trigger conditions. For historical data, verification can combine release history with evidence of current retention, access or use.
8. Boundaries for AI agent issues. Hallucinations, policy-violating output, or a model claiming it has "read" or "uploaded" something without evidence of actual data processing are not privacy vulnerabilities on their own. Normal processing that stays within the stated purpose, scope and valid consent, and matches the actual privacy settings and data-handling commitments, is not a privacy vulnerability. "The privacy policy already describes it" or "it is an existing feature" does not by itself rule out a specific case of unauthorised processing or a failed privacy control.

ZCode has AI agent, tool-calling and code-execution capabilities, so the following are rated by their actual impact:

• prompt injection that leads to cross-user data access, key leakage or unauthorised tool calls;
• executing system commands by bypassing the sandbox;
• tricking ZCode into accessing external systems, uploading data or modifying files without the user's knowledge.

Plain prompt bypasses, inaccurate model answers or content safety issues are not counted as security vulnerabilities when there is no real impact on data, permissions or systems.

1. Duplicates: only the first valid report of a vulnerability is rewarded; later reports are treated as duplicates.
2. Issues sharing one root cause across several pages, APIs or versions are generally merged into one vulnerability.
3. Issues that are already public, already found internally by ZCode or already being fixed may be downgraded, merged or not rewarded.
4. Issues that only affect old versions and are already fixed in the latest version are not rewarded again.
5. Issues that can only be exploited when the attacker already has system administrator rights, physical access to the device or malware installed are generally not rated High.
6. Vulnerabilities in third-party components are not accepted unless they can be shown to have a real impact on ZCode.

1. Use only accounts, projects, code and test data that you created yourself.
2. Do not run denial-of-service attacks, internal network scans, bulk data retrieval, access to real users' data, SMS flooding or any other test that affects service stability.
3. If you accidentally obtain real data during testing, stop accessing it immediately and say so in your report. Do not keep, share or continue to use it.
4. Do not disclose vulnerability details, publish exploit code or pass vulnerability information to third parties without ZCode's written authorisation.
5. A report must include at least:
   • a title;
   • the ZCode version, build number and operating system;
   • the download source;
   • detailed reproduction steps;
   • requests, responses, logs or a PoC;
   • the actual scope of impact;
   • suggested fixes.

1. ZCode normally acknowledges a report within 1 business day.
2. Ordinary vulnerabilities get an initial conclusion within 5 business days. If the issue is not resolved by then, we reply on the fifth business day to say the assessment is ongoing; for complex vulnerabilities we share progress as it happens.
3. Critical and High vulnerabilities are handled first. Fix timelines depend on risk, scope of impact and difficulty.
4. Once a vulnerability is confirmed and rated, the reward is normally paid within 10 business days.
5. High-quality reports, effective PoCs, help with reproduction and retesting, and new attack chains may receive an additional reward.

If you disagree about whether a vulnerability is valid, its severity, whether it is a duplicate or the reward amount, you can request a review on the report page. ZCode makes the final assessment based on the reproduction results, actual impact and time of the report.