Bricoop Security & Vulnerability Disclosure

Security is an important part of the design and operation of Bricoop Desktop and Bricoop-controlled services.

This policy describes the current security approach of BRICOOP LIMITED (“Bricoop,” “we,” “us,” or “our”) and the scope, conditions, reporting process, and safe harbor for good-faith security research involving Bricoop-controlled software and services.

If you believe you have found a security vulnerability in Bricoop-controlled software or services, please contact:

security@bricoop.com

This policy is not a security certification, warranty, service-level agreement, or guarantee that Bricoop-controlled software or services will be free from vulnerabilities. It does not exclude binding commitments we have made or obligations, rights, and remedies that cannot lawfully be excluded.

1. Security at Bricoop

Bricoop Desktop is designed around a local-first architecture.

Core Bricoop Desktop state is primarily stored and processed on your device. In the ordinary Desktop AI request path, Bricoop Desktop routes requests from your device to eligible Providers within your enabled configuration. Related auxiliary processing may use another eligible Provider within that configuration and may continue after the main response. Bricoop-operated infrastructure is not the ordinary AI-request proxy; outbound proxies configured in Bricoop Desktop or inherited from your operating system or environment may participate in transport.

In this policy, “Providers” means AI providers and model services operated by independent third parties, you, or your organization, including supported local or self-hosted services. A model service processing a request solely on your device can keep its content local, while that service’s downloads, authentication, telemetry, or other connections may communicate externally. Other eligible Providers may still receive main or auxiliary requests under your enabled routing configuration.

Data may leave the device where needed for functionality you request or have enabled, including when:

• communicating with an AI Provider;
• authenticating with a Provider;
• checking for Bricoop Desktop software updates;
• retrieving Bricoop-maintained catalogs;
• contacting Bricoop support; or
• using other functionality that is disclosed to the user.

The Bricoop Privacy Policy describes the information involved, its recipients, and the relevant retention and user controls.

2. Local Data and Credential Security

Bricoop Desktop uses multiple layers of protection for applicable local data.

Current Bricoop Desktop implementations use technologies including:

• SQLCipher for applicable encrypted local databases;
• AES-256-GCM for applicable encrypted conversation artifacts; and
• operating-system credential facilities as part of protecting local cryptographic key material.

Security implementations may evolve. These measures apply to the relevant data and components; they are not a claim that all local files receive identical protection.

Provider API keys and OAuth credentials are generally stored in Bricoop Desktop’s encrypted local database. They are not necessarily stored as individually isolated entries in the operating system’s credential store.

These encryption measures protect the applicable databases and conversation artifacts. They do not mean that every local preference, exported file, or configuration written for another Application is encrypted by Bricoop Desktop.

When Bricoop Desktop configures a connected Application, it may place a local Bricoop Desktop access credential in that Application’s configuration. That credential can authorize requests through Bricoop Desktop and access to configured Provider resources; it is distinct from the underlying Provider API key or OAuth credential. Its security also depends on the security of your:

• operating system;
• local account;
• filesystem;
• backups; and
• connected Application.

3. Local Compatibility Service

Bricoop Desktop provides local compatibility interfaces that allow supported Applications to communicate with Bricoop Desktop.

The local compatibility service is designed for same-device loopback communication and:

• binds to loopback; and
• requires a Bricoop Desktop connection credential for its AI-compatible API routes. A basic local health endpoint is available without that credential.

The current loopback connection uses local HTTP rather than TLS. It is intended for communication between processes on the same device and should not be exposed as a general network service through port forwarding, tunneling, or similar means.

The credential requirement described here applies to the AI-compatible API routes. Loopback binding and possession of a credential do not guarantee the identity or trustworthiness of every local process, or protect against another process that can obtain that credential. Other local interfaces and management operations have their own security boundaries.

4. Provider Network Security

Bricoop-maintained official integration definitions specify permitted network destinations for Provider-related traffic. Custom Provider definitions are also subject to the destination-policy requirements enforced by Bricoop Desktop.

Depending on the applicable request path, Bricoop Desktop uses controls designed to validate Provider destinations before transmission, including controls relating to:

• declared destination policies, including permitted hosts and ports;
• final request URLs after template resolution;
• redirect destinations before a further request is sent; and
• HTTPS requirements, with limited exceptions for explicitly permitted local loopback destinations.

Where an effective Provider destination policy materially changes, Bricoop Desktop may require the user to review the updated destinations.

These controls are intended to help prevent Bricoop Desktop from sending Provider-related information to destinations outside the applicable authorized boundary.

They do not mean that Bricoop has certified the security, privacy, compliance, or trustworthiness of a Provider.

For an independently operated Provider, its security, retention, access-control, and privacy practices govern the information it receives, subject to applicable law. For a Provider operated by you or your organization, those protections depend on your deployment and controls. Neither case excludes obligations Bricoop has for its own processing or controlled components.

Destination checks govern the intended Provider endpoints. A configured outbound proxy may separately observe connection metadata; an intercepting proxy or an unencrypted connection may expose additional information. Provider destination authorization is not a security certification of the proxy. An external browser or independent Application may use network settings outside Bricoop Desktop’s Provider transport controls.

5. Third-Party and Custom Integrations

Bricoop Desktop may interoperate with independent Providers and applications, developer tools, extensions, command-line tools, agents, scripts, or other software supplied by you, your organization, or third parties (“Applications”). It may also use integrations or configurations created, imported, or modified by users or supplied by third parties (“Custom Integrations”).

Independent Providers and Applications are managed by their respective operators. A Custom Integration is a definition or configuration used by Bricoop Desktop; it is not necessarily a separately operated system.

Bricoop does not control all aspects of their:

• security architecture;
• credential handling;
• software updates;
• data retention;
• internal access controls;
• tool execution;
• account security; or
• incident response.

A Custom Integration may also materially change where information is transmitted and how a workflow behaves.

The fact that Bricoop Desktop can load, validate, or use an integration does not mean that Bricoop has audited, certified, endorsed, or approved its security or that of its operator. Users should review its source, permissions, destinations, and data handling before use. Bricoop’s own connection, configuration, routing, and compatibility components remain within Bricoop’s responsibilities under applicable law and binding commitments.

6. Diagnostics and Usage Information

Current public Bricoop Desktop builds keep persistent first-party diagnostic records and local usage information on your device without automatically uploading them to Bricoop.

Persistent first-party diagnostics use a separate, bounded, encrypted local store. Their content is limited by controls designed to exclude AI prompts, Provider responses, credentials, raw external payloads, full URLs, file paths, and network destinations. Persistence is enabled by default; retention, storage limits, and the available opt-out are described in the Bricoop Privacy Policy.

These controls do not mean that all terminal output, developer debugging information, or logs produced by independent Applications or dependencies have the same content or protections. Diagnostic material can still be security-relevant; review and redact it before voluntarily sharing it with support or others.

Local usage displays can include related auxiliary Provider calls where records and usage data are available. This does not make them a complete record of every operation or billable event, and it does not create a remote analytics feed.

If a future product or version introduces different diagnostic, crash-reporting, telemetry, or cloud processing, we will provide the relevant disclosures and satisfy any notice, choice, consent, or other conditions required by applicable law before that processing begins. This policy does not itself enable or authorize a new upload practice.

7. Official Software Releases

Official Bricoop Desktop production releases use security and authenticity mechanisms appropriate to their platform and distribution channel. The mechanisms and verification steps depend on the actual release artifact.

Depending on the platform and channel, these include:

• macOS application and installer signing, Hardened Runtime, and Apple notarization for official macOS Direct releases;
• Windows software and installer signing for official Windows Direct releases; and
• signed APT repository metadata and referenced DEB package hashes, and signed RPM repository metadata and RPM package signatures, for official Linux repositories.

Linux releases are distributed as DEB and RPM packages, with APT and RPM repositories at packages.bricoop.com. Official packages include the public signing key and repository configuration. The stable repository is enabled by default; the beta repository requires an explicit administrator choice. Repository configuration is managed under the package manager’s configuration-preservation rules.

The system package manager controls Linux package installation and upgrades under the administrator’s settings. Bricoop Desktop provides version checks and update information; it does not install Linux package updates, overwrite administrator-managed repository settings, or enable unattended upgrades. Users should establish trust in the signing key through an authorized distribution channel and retain repository and package verification.

Users should obtain Bricoop Desktop from Bricoop-authorized distribution channels and retain applicable operating-system and package-manager verification controls. A signature or notarization helps establish authenticity or integrity; it is not a guarantee that software is free from vulnerabilities. Updates should be obtained through the supported mechanism for the relevant channel.

8. Security Boundaries and Limitations

Security controls reduce risk but cannot eliminate it.

Bricoop Desktop’s local security controls are not designed to guarantee confidentiality against:

• a fully compromised operating system;
• an administrator or root-level attacker;
• malware running with sufficient privileges;
• compromise of the user’s local account; or
• another process with equivalent access to the user’s data.

Encryption at rest does not mean that information remains encrypted at every stage of use. Software must process relevant information in memory when performing requested operations. Local encryption also does not, by itself, provide equivalent end-to-end encryption or confidentiality across different Provider features and compatibility mechanisms.

Bricoop cannot guarantee the security of information in an independently controlled Provider, Application, or other system after the information is made available to it. These limitations do not exclude Bricoop’s obligations for its own security measures, processing, or controlled components under applicable law and binding commitments.

9. Reporting a Vulnerability

If you believe you have identified a vulnerability affecting Bricoop-controlled software or services, please report it privately to:

security@bricoop.com

A useful report may include:

• the affected Bricoop product, service, or domain;
• the affected version, platform, and relevant configuration, if known;
• a description of the vulnerability;
• minimal reproduction steps;
• the potential security impact;
• a proof of concept, where reasonably necessary; and
• any suggested mitigation.

Please avoid including unnecessary:

• personal information;
• third-party data;
• credentials;
• authentication tokens; or
• confidential information.

Use test data and redact sensitive information wherever practicable. If sensitive material is essential and cannot safely be redacted, contact us first to arrange an appropriate transfer method. Do not include live credentials or unredacted third-party information in an ordinary report unless an appropriately authorized and secure method has been agreed.

We will use reasonable efforts to acknowledge, assess, investigate, and respond to credible security reports. Findings may require clarification or additional evidence; submitting a report does not itself establish that a vulnerability exists or authorize further testing outside this policy.

We do not promise a fixed acknowledgment, remediation, or disclosure timeline.

10. Scope

This policy authorizes good-faith research only within the scope and conditions stated here and only to the extent BRICOOP LIMITED has legal authority to authorize the testing.

In-scope assets are the Bricoop-controlled portions of:

• official Bricoop Desktop releases;
• bricoop.com;
• updates.bricoop.com;
• releases.bricoop.com;
• downloads.bricoop.com;
• packages.bricoop.com;
• official integration components maintained by Bricoop; and
• other services that Bricoop expressly identifies as in scope and has authority to authorize for testing.

A vulnerability in Bricoop’s own integration logic remains in scope even where an independent Provider is involved.

Examples may include:

• Bricoop-controlled software sending credentials to an unintended destination;
• bypass of a Bricoop-controlled network-destination control;
• redirect-policy bypass;
• a vulnerability in a Bricoop-controlled OAuth implementation;
• incorrect credential handling;
• authorization flaws in Bricoop-controlled software; or
• Bricoop-controlled request-processing logic unintentionally disclosing sensitive information.

Test the Bricoop-controlled behavior using your own accounts, credentials, data, and a controlled test environment where practicable. A listed domain or integration does not extend authorization to an independent Provider, another customer’s tenant, or a hosting, CDN, or platform operator’s underlying infrastructure. If the boundary is unclear, contact security@bricoop.com before testing.

11. Out-of-Scope Systems

This policy does not authorize testing of independently controlled systems outside the scope described above, including:

• AI Providers;
• connected Applications;
• user-configured Providers;
• third-party websites;
• cloud or platform providers;
• third-party APIs; or
• infrastructure that Bricoop does not have authority to authorize for testing.

Bricoop’s support for a Provider or Application does not authorize testing its independent systems. This policy does not grant or revoke separate authority you have to test systems owned or controlled by you or your organization. Such testing requires the appropriate owner or operator authorization and compliance with applicable law; merely configuring a system in Bricoop Desktop does not bring it within this policy or its safe harbor. Any separate authorization from Bricoop must be express and is limited to testing Bricoop is legally able to authorize.

Follow applicable law and any separate authorization and security or vulnerability-disclosure policy governing the systems you test. A permission given by Bricoop does not override another party’s rights or testing conditions.

12. Rules for Good-Faith Security Research

Bricoop supports good-faith security research intended to identify, understand, responsibly disclose, or help remediate genuine security vulnerabilities.

To remain within this policy, you must:

• use your own or appropriately authorized devices, accounts, credentials, and test data wherever reasonably possible;
• limit access and exploitation to what is reasonably necessary to establish and report the vulnerability;
• stop further exploitation after obtaining sufficient evidence, and coordinate any additional testing with us;
• avoid disrupting Bricoop-operated services or other users;
• avoid modifying or deleting data belonging to another person;
• avoid establishing persistent access;
• avoid unnecessary lateral movement;
• avoid deploying malware;
• keep any necessary sensitive evidence secure and retain it only for as long as reasonably necessary for authorized reporting and coordination; and
• report the vulnerability privately and promptly to Bricoop.

If you unexpectedly encounter another person’s information or credentials, stop further access as soon as reasonably possible and notify us promptly. Do not disclose it publicly or to unrelated third parties. Preserve only the minimum evidence reasonably needed for the report, protect it, and coordinate its secure transfer or deletion with us.

Do not intentionally continue enumerating, downloading, modifying, or deleting another person’s information.

13. Activities Not Authorized by This Policy

This policy does not authorize:

• denial-of-service or distributed denial-of-service testing;
• intentional resource exhaustion;
• testing intended to degrade availability;
• destructive testing;
• large-scale extraction of user or production data;
• malware deployment;
• malicious persistence;
• phishing;
• pretexting;
• employee impersonation;
• credential harvesting;
• social engineering;
• physical intrusion;
• theft of devices;
• extortion;
• fraud;
• surveillance;
• unauthorized commercial exploitation of a vulnerability; or
• attacks against third-party systems.

If potentially disruptive testing is reasonably necessary, obtain our explicit written authorization before performing it. Any authorization must specify the permitted scope and methods, remains limited to what Bricoop is legally able to authorize, and does not supply permission from an independent owner or operator.

14. Safe Harbor

Bricoop authorizes good-faith security research on in-scope Bricoop-controlled assets when conducted in accordance with this policy. The applicable policy version is determined as described in the “Changes to This Policy” section.

If you:

• conduct research in good faith;
• remain within the scope of this policy; and
• comply with the rules above,

Bricoop will not initiate legal action against you solely for that research. Bricoop’s proprietary software restrictions in the applicable Bricoop Terms of Service or Bricoop Desktop End User License Agreement do not prohibit conduct expressly authorized under this policy. This protection does not extend to separate unauthorized conduct.

This Safe Harbor applies only to rights and claims that BRICOOP LIMITED itself has legal authority to waive.

It does not:

• bind third parties, public authorities, regulators, or prosecutors;
• waive the rights of Providers, Applications, users, platform operators, or other parties;
• authorize violations of applicable law or provide immunity from legal or regulatory action;
• prevent another party from acting under its own rights or policies; or
• protect theft, extortion, fraud, intentional harm, malicious persistence, unauthorized disclosure of user information, or other conduct outside good-faith research.

If you are uncertain whether a proposed activity falls within this policy, contact security@bricoop.com before proceeding.

15. Coordinated Disclosure

Please give Bricoop a reasonable opportunity to investigate and remediate or mitigate a reported vulnerability before publicly disclosing technical details that could materially increase risk to users or systems.

Coordinate disclosure timing and the content to be disclosed with us where reasonably practicable, taking account of severity, active exploitation, remediation progress, and the risk to users or systems. Public disclosure must not include third-party personal information, credentials, or other sensitive material that you are not authorized to disclose.

We do not require indefinite confidentiality. Appropriate disclosure timing depends on the circumstances and applicable law; the scope, research rules, and protections for sensitive information in this policy continue to apply.

Remediation may take forms other than a software patch, including:

• configuration changes;
• security mitigations;
• catalog changes;
• disabling affected functionality;
• integration removal;
• credential or secret rotation;
• infrastructure changes;
• documentation; or
• recommended workarounds.

16. Rewards and Recognition

Bricoop does not currently guarantee monetary rewards for vulnerability reports.

Submitting a vulnerability report does not create an entitlement to:

• payment;
• compensation;
• reimbursement;
• employment; or
• consulting work.

Any reward or other recognition is discretionary unless separate vulnerability-reward or bug-bounty terms expressly apply. A separate written reward commitment, if made, is governed by its own terms.

With the researcher’s permission, Bricoop may publicly acknowledge a helpful report. Public credit is optional and is separate from the handling of the report and any discretionary reward.

17. Privacy of Security Reports

Information submitted in a vulnerability report is handled for the relevant security purposes, including:

• investigate and reproduce the reported issue;
• communicate with the researcher;
• remediate or mitigate the vulnerability;
• prevent similar issues;
• maintain necessary security and incident records; and
• comply with applicable legal obligations.

We limit access to report information to what is reasonably necessary for those purposes. Where needed, relevant information may be shared with personnel, service providers, or affected component maintainers involved in assessment or remediation, subject to appropriate safeguards and applicable law. We do not treat submission as permission to publish the researcher’s identity or unnecessary sensitive information.

Security reports and associated incident records may be retained only for as long as reasonably necessary for the relevant security, legal, and operational purposes, subject to the Bricoop Privacy Policy and applicable law. That need may differ from routine product-support retention; it is not an unconditional right to retain personal information indefinitely.

For additional information about how Bricoop handles personal information, please see the Bricoop Privacy Policy.

18. Changes to This Policy

We may update this policy as Bricoop’s products, infrastructure, security practices, and vulnerability-disclosure processes evolve. We publish the current policy at a stable website address and identify its effective date. For material changes to research scope, conditions, or safe harbor, we will publish a change summary and provide any notice required by law. Where reasonably practicable, we will give advance notice of changes that materially narrow the research scope or safe-harbor protections.

Research authorization and safe harbor are assessed under the policy version applicable when the relevant activity was conducted, together with any separate written authorization that applied. Revisions apply prospectively from their stated effective date. Ongoing or new activities after that date are subject to the then-applicable scope and conditions; an earlier authorization does not authorize new activity indefinitely.

We will not use a later policy change to retroactively withdraw authorization or safe harbor for activities that complied with the policy and any applicable separate authorization when conducted. This does not protect conduct that was outside those conditions at the time or override applicable law or another party’s rights.

19. Contact

Security vulnerabilities and security-related concerns:

security@bricoop.com

General product support:

support@bricoop.com

Privacy matters:

privacy@bricoop.com

BRICOOP LIMITED

UNIT 05, 12/F THE CLOUD

NO. 111 TUNG CHAU ST

TAI KOK TSUI, HONG KONG

For vulnerability evidence or sensitive security details, use the reporting process described in the “Reporting a Vulnerability” section.