Access and permissions

Cortex authorizes every operation within one Account and applies the permissions of the authenticated principal.

Account boundary

An Account is the customer-owned organizational and authorization boundary. A person can belong to more than one Account, but Cortex resources and operations do not cross Account boundaries.

The Account selected during OAuth determines which Cortex data the integration can access. Changing the active Account in one client does not silently change another client's stored grant.

For shared learning, connect each person's or agent's host to the intended Account and give it access to the relevant knowledge. A decision captured during one teammate's work can then guide another authorized agent. You do not need to copy it into each host, but connecting to the same Account alone does not grant every Module.

Principals

A normal OAuth connection acts as the signed-in Account member. An Account Agent is a distinct principal used only when an integration provisions and connects one explicitly. Separately provisioned Account Agents appear in Admin's Agents directory.

Do not describe a human OAuth grant as an Agent identity. The two principals have different provenance even when they participate in the same work.

Module access

Modules have explicit permissions within the Account. Account membership alone does not grant Module access. The Module owner has full authority over the Module; a Module admin can manage its permission policy. Grants can name individual principals or Account groups.

Module knowledge and Issues have separate roles. Give an agent both kinds of access when its task requires both:

Roles are additive. For example, a reviewer can receive Module viewer and Issue contributor. An agent that must complete assigned Issues needs the capabilities included in Issue editor.

Automatic knowledge maintenance also needs permission to edit the relevant Modules. A read-only agent can use existing knowledge and recommend changes, but it cannot save them. Your review preference does not grant access; host tool confirmations can still apply to an allowed operation.

A child Module can inherit its parent's policy. Change an inherited policy at the governing ancestor, or create an independent boundary before changing only the child's access. Module names do not determine this hierarchy.

If the policy enables Expanded Access, an Issue's current assignee receives Issue-editor capabilities on that Issue. Its reporter receives view and comment access. These relationships do not grant Module knowledge or access to unrelated Issues. Assignment alone is insufficient when Expanded Access is off.

Flash and dependencies

Permission to Flash a Module includes that Flash's complete dependency closure. The closure does not grant direct reading, editing or Issue access on those dependencies. A successful Flash therefore does not prove that the agent can create or update an Issue.

Verify the agent's permissions

Ask the agent to check access through its own authenticated session. Replace MODULE_NAME with the Module it needs:

socra cortex module access MODULE_NAME
socra cortex flash MODULE_NAME

The access response lists that principal's permissions. Check knowledge and Issue permissions separately. Account owners can repair policies, but their Account role does not implicitly give them ordinary Module access. Ownership transfer remains owner-only.

For policy and access operations, use the Cortex API reference or the CLI reference.

Cloud Projects

The first-party coding-agent integration uses OAuth clients owned by Socra's agent-plugins Cloud Project. The customer authorizes an Account and does not create a Cloud Project for this path.

Custom applications remain Project-owned integrations. Create or select the application’s Cloud Project, then follow the custom MCP guide when the application needs its own OAuth client, attribution, and service-consumption boundary.