Picorca Data Security, Encryption, and Ownership Statement

This statement explains how Picorca stores, encrypts, and transfers project data; who owns project data and assets; and the security boundaries users should understand when using sharing, MCP, and third-party services.

In this statement, “project data” mainly includes images imported into Picorca, folders, tags, indexes, previews, project state, and related metadata. Data generated by online services such as website accounts, feedback, and software downloads is not local project data as defined here.

Last updated: September 1, 2026.

1. Core principles

Picorca’s data security features are designed around these principles:

Local first: Projects and assets are primarily stored in local workspaces on users’ devices.
Local storage: When users create, import, organize, or search assets, project data is managed by the local workspace on their device.
No transfer of rights: Using Picorca or its online services does not transfer users’ control over their project data, or any copyright and other intellectual property rights they lawfully hold in original assets, to Picorca.
Key protection: Project data is protected by a local key system. Accessing a shared project requires the relevant authorization information.
Minimal sharing: Project data is synchronized to authorized participants only after a user actively creates or shares a shared project.
Transparent boundaries: Network relays, online discovery, MCP, and third-party AI services each have different levels of access to data and must not be confused with local storage.

“Local first” does not mean a device never connects to a network or that network metadata never exists. Collaboration, online discovery, and user-configured third-party features require network access. Their boundaries are described below.

2. How local storage works

Both personal and shared projects begin in a local workspace. Picorca manages image files, folder structures, tags, and project indexes on the user’s device, and each participant’s device stores a complete copy of the project data available to that participant.

This means:

Personal project data remains on the current device when sharing is not enabled.
Users can export backups by project or folder and choose where those backups are stored.
Picorca does not retain a complete project copy that can be used for recovery, so users remain responsible for maintaining reliable backups.

3. Data rights and asset copyright

Importing, organizing, indexing, previewing, synchronizing, or otherwise using project data with Picorca does not transfer users’ control over that data, or any copyright and other intellectual property rights they lawfully hold in original assets, to Picorca.

Whether Picorca currently or subsequently provides accounts, online discovery, relays, or other online services, those services do not change the ownership of project data or assets. Picorca processes relevant data only to the extent needed to provide features the user actively selects and does not acquire ownership or intellectual property rights merely by providing a service.

If a project contains third-party assets, their copyright and other rights remain with the original rights holders. Users must ensure that they have the authorization needed to store, process, and share those assets. Sharing or synchronizing a project does not itself transfer copyright unless the relevant parties expressly agree otherwise. However, after data has been synchronized to another device, the sender no longer has continuing technical control over how the remote copy is used.

4. Encryption and keys

Picorca uses a key-based mechanism to protect local project data. Personal and shared projects follow the same encrypted-storage model: project data is protected locally by project keys, and only participants holding the relevant authorization information can read content within the shared scope.

A sharing invitation credential is not an ordinary public link. It may contain information needed to join a project and discover collaborating nodes, so it should be handled like a password or access key:

Send it only to intended collaborators through trusted channels.
Do not publish it on public web pages, in group chats, or in searchable documents.
If you suspect that a credential has leaked, stop distributing it and re-establish the sharing relationship using the options available in the current version.
If you leave a shared project and need to rejoin, use a new, valid invitation flow.

No single encryption mechanism can eliminate every risk. Project encryption is not a substitute for endpoint security if a device is compromised by malware, an operating-system account is breached, or another person can view the screen or exported files.

5. P2P transfer and synchronization

Shared projects preferentially connect authorized devices through a peer-to-peer (P2P) network. Participants’ devices send and receive project content directly.

When project content has been synchronized to another participant’s device, that participant holds a locally readable and usable copy. The original project owner or sender cannot use the original project or sharing relationship alone to impose continuing technical restrictions on the remote copy’s use, duplication, export, or redistribution. The recipient’s right to use a copy is governed by agreements between the parties, applicable law, and the recipient’s own environment. Share only with trusted participants, and confirm the sharing scope and asset permissions before synchronization.

When direct connections cannot be established because of complex NAT or other network conditions, Picorca can use a relay to forward encrypted traffic. A relay improves connectivity:

It is not a file-storage service and does not become a persistent repository for project assets.
It cannot decrypt the project content it forwards.
Its operator may still observe operational metadata such as connection times, peer identifiers, IP addresses, and traffic volume.
Teams that need greater control can deploy and configure their own relay according to Picorca’s documentation.

6. Online discovery and node information

Depending on the configuration, shared projects can use offline or online discovery methods. Online discovery services help participants find connectable project nodes; they do not store image assets.

When a public tracker or similar discovery service is used, node-addressing information or distributed-hash-related metadata may be visible to the provider or other network participants. Teams with stricter node-privacy requirements should assess this metadata exposure and prefer a controlled network or private service.

7. MCP and local AI tools

Picorca’s MCP service allows AI clients such as Codex to operate on the currently open project. Its current design binds the MCP service to the local loopback address and controls access with a generated Bearer Token.

When using MCP:

Treat the Bearer Token as a project-access credential and never paste it into a public location.
Refresh the token in Picorca immediately if you suspect it has leaked.
Enable read-only mode when only search or viewing is required, reducing permissions to import, move, or modify data.
Running MCP locally does not mean the connected AI client is entirely offline. How an AI client handles prompts, previews, and asset information depends on that client’s settings and its model provider’s privacy policy.

8. Third-party AI, translation, and external services

Picorca can connect to AI, translation, or other external services configured by the user. Text, images, or metadata needed to fulfill a request are sent according to the selected service’s API rules only when the user enables and invokes the corresponding feature.

Before using an external service, confirm:

The types and scope of data that will be sent.
Whether the provider retains requests, uses them for training, or transfers them to another region for processing.
The permissions, costs, and rotation process for API keys.
Whether the service is appropriate for customer data, unpublished work, or other sensitive content.

Picorca cannot replace the security and privacy commitments of third-party services.

9. Website accounts and project assets are different

The Picorca website may process information needed for registration and sign-in, licenses, avatars, feedback, traffic measurement, and transactional emails. These online services have a different data scope from local project assets managed by the desktop application.

“Project assets are stored on local devices” specifically refers to project files and related local data managed by the Picorca desktop application. It does not mean the website processes no online data while providing account and support services.

10. User security responsibilities

To reduce the risk of data exposure or unrecoverable loss, users should:

Protect operating-system accounts and disks with reliable access controls.
Export project backups regularly and store them in a separate, protected location.
Send sharing invitation credentials only to trusted members.
Rotate leaked or potentially leaked MCP Tokens and third-party API keys promptly.
Confirm the sharing scope, participant identity, and third-party service settings before sending sensitive assets.
Download Picorca from an official release page and verify the source.

11. Open-source verification and reporting issues

Parts of the project code, version history, and technical discussions can be reviewed in these repositories:

If you discover a security issue, do not disclose keys, invitation credentials, personal data, or directly exploitable sensitive details in a public issue. Contact the Picorca team first through the contact page.

12. Updates to this statement

Picorca remains under active development, and its storage formats, network discovery, permissions, and third-party integrations may change between versions. This page explains the current product design and data boundaries; it is not an absolute guarantee against every risk. We will update this statement when important changes occur.