Skip to content

What data leaves my environment when I use Cortex, and who can access it?

Cortex is a Socra-hosted cloud service. Information leaves your environment when you or your agents create or update resources in Cortex.

What Cortex receives

Cortex stores the resources submitted to it:

  • Module content and version history
  • Module dependencies
  • Access-control grants
  • Issues and comments
  • Flash records, including the requested Module, included versions, caller, and usage metadata

Installing the Cortex CLI or connecting the Cortex MCP server does not cause Cortex to scan or upload your repository. Cortex receives requests sent through its interfaces and records service activity such as Flash usage.

An agent may inspect source code as part of its own task. That activity happens at the agent boundary, outside the Cortex service. Any information the agent sends to its model provider is governed by the agent's configuration and your agreement with that provider.

How Cortex isolates customer knowledge

Your Socra Account is the tenant boundary. Cortex derives the Account from the authenticated credential. A client cannot supply a different Account ID to reach another tenant.

Cortex scopes customer resources to that Account. Account boundaries apply to resource reads, writes, searches, and dependency traversal. A resource in another Account is not accessible through these requests.

This is logical tenant isolation enforced by our authorization and data-access layers. It is not a dedicated customer database or private deployment.

How you control access

Each Module is its own authorization boundary. You can grant access to individual people, application identities, or groups.

Module knowledge and Issues have separate roles. A person or group can hold more than one role.

  • Module viewer: Can read and Flash Module knowledge.
  • Module editor: Can also change Module content and dependencies.
  • Module admin: Can manage the Module's access policy and all its Issues. Ownership transfer remains owner-only.
  • Issue viewer: Can read Issues, comments, and authorized attachments.
  • Issue contributor: Can also create Issues and comment.
  • Issue editor: Can also edit Issues, but cannot delete Issues or comments.
  • Issue admin: Can manage Issues and comments, including deletion under their lifecycle rules. This role grants no Module knowledge.
  • Module owner: Has full authority on the Module. Only the owner can transfer its ownership.

A child Module can inherit its parent's access policy or use an independent policy. When Expanded Access is enabled, an Issue's assignee can read, comment on, and edit that Issue. If the Issue is unassigned, the Module's default assignee receives those permissions. The identity that created the Issue can read and comment on it. These grants provide no Module knowledge.

Account ownership alone does not grant routine access to Module content. Account owners can read and replace Module access policies.

Within Socra, customer content is available only to personnel who need it for support, service reliability, safety, or legal obligations.

What a Flash can disclose

When someone is authorized to Flash a Module, Cortex returns that Module and its complete dependency closure. Cortex authorizes the requested root Module once. It does not run another access check for every dependency in that Flash.

Adding a dependency is therefore a disclosure decision. For example, if Payments depends on Security, anyone authorized to Flash Payments receives Security's content too. Flashing Security does not include Payments merely because Payments depends on it. Dependencies are separate from the parent relationship used to organize Modules and inherit permissions.

Creating the dependency requires access to both Modules. Receiving Security within an authorized Flash of Payments does not grant permission to retrieve, list, or edit Security directly.

Storage and model processing

Our Privacy Policy explains how we store and process personal information.

Cortex does not call a model API when it stores, searches, versions, or flashes Modules. If an authorized agent retrieves Cortex knowledge, that content enters the agent's session and may be processed by the model provider configured for that agent.

We do not sell customer data or use customer content to train models.

Module knowledge is versioned. Archiving a Module removes it from active use but is not an erasure mechanism. Credentials, private keys, and review secrets should never be stored in Modules or Issues.