Real tools call for
clear boundaries.

Understand the boundaries

The computer hosting your team stores the workspace and configured credentials. Agents work in Linux environments and can use enabled tools. Review what files, directories, accounts, and network services you make available.

Projects provide shared context and company-shared storage. Project membership alone is not a security boundary. Use separate access controls where you need separation, rather than relying on a sentence in a prompt.

Choose access deliberately

• Keep model and service credentials in the appropriate account settings.
• Grant only the service permissions needed for the task.
• Avoid placing secrets in chat, shared notes, source files, or exports.
• Review the destination and scope before approving consequential actions.
• Inspect outputs and tool results when the work touches important data.

Model requests and relevant task context go to the provider you select. Enabled tools can contact external services. Their security and privacy policies are part of the connection you choose.

Report a suspected issue privately

Treat an unexpected access bypass, exposure of a key, or access to data outside the intended workspace as a security concern. Do not post secrets or exploit details in a public issue or discussion.

If you are an invited tester, contact the project through the private channel used for your build or repository access. A public security-reporting address is still being prepared; this page does not offer a staffed response service or a guaranteed response time.

What to include

• The affected build and operating system.
• The access you expected and what occurred instead.
• Minimal reproduction steps, with secrets removed.
• The scope you observed, without accessing additional private data.
• Any immediate mitigation you already applied.

If a credential may have been exposed, revoke or rotate it with its provider and review the relevant account activity. Preserve only the evidence needed to explain the issue.