Skip to content

Access and Trust in Carta

Every organization working with sensitive data faces the same tension: the people and systems that need to collaborate are often the same ones that should not have unrestricted access to each other's information. The more parties involved — partner institutions, external instruments, automated systems — the harder it is to manage that boundary without either locking everything down or opening everything up.

Carta is designed around the principle that this tension is solvable. Access control in Carta is not a layer added on top of the platform — it is the structure through which everything in Carta operates.

Authentication and Authorization Are Separate Concerns

When any caller interacts with Carta — a researcher in a browser, a Python script, an automated service — two distinct checks happen in sequence.

The first is authentication: confirming that the caller is who they claim to be. The Carta Gateway handles this. Every request to Carta passes through the Gateway before reaching any Carta service. The Gateway verifies identity and routes the request forward; it does not decide what the caller is allowed to do.

The second is authorization: determining what the authenticated caller is permitted to access, modify, or create. Carta Permissions handles this. After the Gateway confirms identity, Permissions evaluates each request against the relationships the caller holds within the platform.

These two concerns are intentionally separate. A valid identity does not automatically grant access to anything. Being added to a Carta deployment does not expose you to data you have not been given explicit access to. Every access decision is made the same way — by the same engine — regardless of how the request arrives.

A Graph of Relationships

Carta's authorization model is built on a graph. Every entity in the platform — users, groups, services, and data resources — is a node. Access is determined by the relationships between those nodes.

This model makes it possible to express nuanced access configurations naturally. A user added to a group inherits the relationships that group holds. A service granted access to a resource can interact with it as part of the workflow it belongs to. A user can link a record they hold to another record they cannot read — and confirm that link exists — without exposing the contents of the linked record.

The structured data capture use case illustrates this directly: a technician links a characterization result to a formulation record — confirming the connection for compliance purposes — without being able to see the formulation's contents. The link is a relationship in the graph. The contents are protected by a separate relationship the technician does not hold.

The Same Check, Every Time

Carta is described as an identity-aware platform. What this means in practice is that the same authorization evaluation applies regardless of how a request is made. A researcher clicking through Collections in a browser, a data scientist running a PyCarta script, and a Dispatcher running automatically after a form submission all go through the same permissions check.

There is no back channel. There is no mode of access that bypasses authorization.

This is what makes it safe to give programmatic and automated systems access to Carta. A PyCarta script running under a researcher's credentials can only do what that researcher is authorized to do. A Dispatcher configured to run after a form submission can only interact with resources its service identity has been explicitly granted. Automation does not expand the access surface — it inherits from it.

Across Organizational Boundaries

The authorization model extends to multi-institutional scenarios without requiring shared infrastructure between organizations. When a partner institution participates in a workflow, they do not receive credentials into the host organization's systems. They authenticate through their own identity provider — Carta supports SAML-based SSO federation, configured during onboarding, so partner users can log in with their existing institutional credentials rather than a separate Carta account. They receive access only to the specific artifacts they have been granted.

DEXR handles the delivery of those artifacts using end-to-end encryption. The actual files remain in the host organization's storage; the partner receives a temporary, permission-scoped reference to retrieve them directly. The partner never touches the host's data systems. What they can retrieve is exactly what they have been authorized to retrieve — nothing more.

The result is that cross-institutional collaboration does not require mutual trust in each other's infrastructure. It requires only a shared authorization decision: that this partner should have access to this artifact, for this purpose.