Vulnerability Disclosure Policy

We want Nib to be safe for the people who rely on it, and we welcome reports from security researchers. This policy explains how to report a vulnerability and what you can expect from us. It's linked from our security.txt.

How to reportCopy Anchor Link

Email security@nib.gg. If you'd like to encrypt your report, tell us and we'll set up an encrypted channel. Please don't open public issues, discussions or pull requests about a vulnerability.

Please include:

• what the vulnerability is and what an attacker could do with it;
• the product and version (desktop app, CLI, daemon, web app, cloud API, Hub) and your platform (the CLI's --version, or About in the app);
• steps to reproduce, with a proof of concept if you have one; and
• how you'd like to be credited, if at all.

You can write in English or Russian.

What we promiseCopy Anchor Link

• We'll acknowledge your report within 3 working days.
• We'll give you an initial assessment within 10 working days, and keep you updated at least every 14 days until it's resolved.
• We prioritise fixes by severity, and we start work on critical issues immediately.
• We'll tell you when it's fixed and agree a disclosure date with you. We'd normally expect public disclosure no later than 90 days after your report, or sooner once a fix is released.
• With your permission, we'll credit you in our release notes and on an acknowledgements page.

We don't currently run a paid bug bounty.

We fix security issues in the latest release of the desktop app, CLI, daemon and iOS app; the cloud is always current. Please update before you report.

ScopeCopy Anchor Link

In scope:

• the Nib desktop app (its webview, native shell, keychain access and updates), CLI and daemon (its API and WebSocket, authentication, the permission gate, the OS sandbox around agent commands, the browser tools), editor extensions, GitHub Action and SDKs, current release;
• the iOS app (remote control, approvals, device attestation), current App Store release;
• app.nib.gg, api.nib.gg, hub.nib.gg and nib.gg: accounts, sync, the relay to your devices, cloud sandboxes, the model gateway and billing;
• the update feed and downloads, updates.nib.gg;
• the hosted-artifacts domain, nibusercontent.com, where the issue lets one user's content affect another user or our systems; and
• the Hub's publishing, signing, transparency log, scanning, installation and revocation, and the capabilities an extension is granted.

Particularly interesting: escaping the sandbox or the permission system (protected approvals, plan mode, the auto-mode reviewer), getting the agent to act without approval through content it reads, reading another customer's data, sessions, devices or sandboxes, bypassing the invite gate or billing limits, and anything that exposes credentials (device tokens, gateway keys, provider keys).

Out of scope:

• third-party extensions on the Hub (report those to the publisher, and tell us at hub@nib.gg if one is malicious);
• model providers, Railway, Stripe, GitHub, Apple and other third-party services (report to them);
• denial-of-service or volumetric testing, spam, social engineering, and physical attacks;
• findings that need a compromised device, a jailbroken phone, or an attacker who already controls the user's account or workspace configuration, or that rely on a permission the person granted (running in Bypass mode, or approving a command, is such a permission);
• the model saying something wrong or unpleasant, unless it leads to a security impact; and
• missing best-practice headers, banner disclosure or rate limits without a demonstrated impact.

Rules for testingCopy Anchor Link

• Only test against accounts and data you own or have permission to use. Ask us for a test workspace if you need one.
• Don't access, change or delete other people's data. If you come across it by accident, stop, don't keep a copy, and tell us.
• Don't degrade the service for others. No automated scanning that generates heavy load.
• Don't use what you find for anything beyond showing the issue, and don't leave anything behind (such as backdoors).
• Give us reasonable time to fix the issue before you disclose it publicly.

Safe harbourCopy Anchor Link

If you make a good-faith effort to follow this policy:

• we consider your research authorised, and we won't start legal action or report you to law enforcement for it, including under the Computer Misuse Act 1990 or equivalent laws, or for breaching our terms in the course of research;
• we'll waive the parts of our Terms of Service and Acceptable Use Policy that would otherwise prohibit your testing, to the extent needed for research within this policy; and
• if a third party brings legal action against you for research that followed this policy, we'll make it known that your actions were authorised by us.

We can't authorise testing of systems we don't own. If you're unsure whether something is in scope, ask us first.