Who can see and change LLM trace data in Langfuse, and how to decide
When several teams send traces to one self-hosted Langfuse, the security or platform lead has to decide who may view, export and delete that data. Langfuse role-based access control assigns Owner, Admin, Member, Viewer or None roles at organization and project level. Users receive an organization-level role by default, and a project-level role gives finer control over a single project. Before any team is onboarded, the lead should list each project, the people who need it, and whether its prompts or outputs are sensitive enough to justify a narrower group. That list is the input to every role decision that follows. Without it, access tends to follow whoever created the first project, which is a weak basis for a control.
A default organization role may be enough for one team with one project. It stops being enough when several projects share an instance, when prompts or model outputs contain sensitive content, or when auditors or internal policy expect segregation of duties. Segregation of duties means the person who configures a project is a different person from the one who exports its data. Project-level roles are the mechanism for that separation, and in a self-hosted deployment they require an Enterprise license key. Confirm this against the Langfuse license key documentation for your version, and ask Langfuse for the license terms and cost before you commit to a design that depends on project-level roles.
The role matrix decides who can take the sensitive actions. According to the Langfuse RBAC documentation, creating or deleting project API keys requires Admin, exporting data requires Member, deleting traces requires Admin, and deleting a project requires Owner. Member can view metrics and create scores but cannot change configuration, and Viewer can only view. Two consequences follow. First, any Member can export the data of every trace in the projects that role covers, so the export path needs the same review as the role grant itself. Second, API keys belong to a project and are not tied to an individual user, so a key can outlive the person who created it. Confirm how your team rotates and deletes keys before you publish the access model.
To decide, answer three questions for each project: who may view traces, who may export them, and who may delete them. Then map each answer to the lowest role that allows it, and use None for people who need one project and should not see the wider organization. Test the design in a non-production instance by signing in as a user at each role and attempting an export, a trace deletion and a key creation. Record the results. The same evidence supports a review against common criterion CC6.3 of the 2017 Trust Services Criteria, which asks the organization to grant, change and remove access based on roles, responsibilities or system design, with least privilege and segregation of duties in mind. DeployOpen can prepare the configuration and evidence, but an independent auditor decides whether the controls meet that criterion.
Which Langfuse role fits each person, and what each role can do
This table compares the five Langfuse roles by the person each one usually suits, the permissions the Langfuse RBAC documentation describes and the situations where each role fits. Read it from the top down and grant the least role that covers each person's work. The final row lists the minimum roles for exports, trace deletion, project API key changes and project deletion, which often decide who needs more than Member access.
| Role | Typical person | Permissions described in the docs | When the role fits |
|---|---|---|---|
| Owner | Accountable lead for the whole organization or project | All permissions, including deleting a project | Only the few people who must hold full control, including project deletion |
| Admin | Platform engineer or project lead who configures Langfuse | Edits project settings and grants access, creates and deletes project API keys, deletes traces | People who set up projects, manage access and handle keys and trace deletion |
| Member | Developer or ML engineer who reviews traces and scores | Views metrics, creates scores without configuration, exports data | Day-to-day users who analyze LLM behavior but do not change settings |
| Viewer | Stakeholder who reads results without changing anything | View only | Reviewers, auditors or managers who need read access to traces and metrics |
| None | Single-project user working in one project only | No default organization access | Users who work in one project and should not see others by default |
| Minimum role for sensitive actions | Anyone who needs these specific actions | Export data: Member. Delete traces: Admin. Create or delete project API keys: Admin. Delete a project: Owner. | Check these minimums before granting access for exports, deletions or key management |
Langfuse role-based access control: organization roles versus project roles
The first design decision in self-hosted Langfuse is how much access a person gets across the whole organization and how much they get inside each project. Langfuse role-based access control is built on four objects: users, organizations, projects and roles. A user receives an organization-level role by default, and that role applies across the organization unless a more specific assignment changes it. Project-level roles give finer control, so one person can hold a different role in each project. On a self-hosted instance, project-level roles require the Enterprise Edition license key. If your design depends on per-project separation, confirm the license position with your Langfuse contact and check the license key documentation before you finalize the model.
Langfuse defines five roles. Owner holds all permissions. Admin can edit project settings and grant access. Member can view metrics and create scores but cannot change configuration. Viewer can only view. None provides no default organization access and fits a user who works in one project only. For that person, the practical model is a single project-level role in the one project they use, with nothing else exposed at the organization level. Before you rely on this pattern, test in a non-production project how a None organization role combines with a project role in your version, because the combined behavior determines what the user can see.
A user who needs different roles across several projects cannot be handled by the organization role alone. The organization role sets the baseline, and each project then needs its own assignment where the person's responsibilities differ. For example, an illustrative analyst might be Member in a reporting project and Viewer in a production project. Confirm how the organization role interacts with project roles in your version, including whether it acts as a floor, a fallback or an additional grant. Also note that API keys belong to a project rather than a user. Creating or deleting project API keys needs Admin, exporting data needs Member, deleting traces needs Admin and deleting a project needs Owner, so each of these actions should map to a named role.
Write the role matrix before anyone is invited. List each group of users, their organization role, their role in each project and the actions they need, such as viewing traces, exporting data, managing API keys, deleting traces or deleting a project. Check every grant against the least privilege and segregation of duties principles described in the access control criterion CC6.3 of the AICPA 2017 Trust Services Criteria, which expects access to be granted, changed and removed based on roles and responsibilities. Keep the matrix under version control so that each change has a date and an owner. It also becomes the baseline for periodic access reviews. DeployOpen can help prepare these controls and evidence, but independent auditors issue any SOC 2 report.
Once the matrix is agreed, test it before rollout. Create a test user for each role in a non-production project, then confirm that each user can perform the listed actions and cannot perform the others, including key management, exports and deletions. Record the results alongside the matrix. Ask your implementation partner or internal team to confirm any behavior that the documentation leaves open for your Langfuse version. Repeat the test after each major upgrade, because role behavior and related features can change between releases, and treat any unexpected access as a defect to fix before production users are invited.
How to set up Langfuse role-based access control in a self-hosted instance
This sequence takes a self-hosted Langfuse instance from confirmed licensed features to tested access, one step at a time. It produces an organization and project structure, an approved role matrix, assigned roles, scoped project API keys and test results showing that each role does what the design says.
Confirm the Enterprise license key covers the design
The platform owner and the security or governance lead check the features the design depends on before any build work starts. On a self-hosted instance, project-level roles need an Enterprise license key, and the same check should cover any other gated feature the design needs, such as audit logs, data retention policies or SCIM provisioning. Confirm each item against the license key documentation and your agreement with Langfuse, then record which features are licensed. Done when the feature list is signed off and filed with the design record.
Deploy or confirm the Langfuse instance
The platform team deploys Langfuse Web and Langfuse Worker with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, or confirms an existing instance. Docker Compose on a single VM suits testing only because it has no high availability, so production deployments usually use Kubernetes with Helm or Terraform. Enter the license key in the instance settings, sign in as the first administrator and confirm that both application containers are healthy. Keep the version and deployment method in the record. Done when sign-in works and the instance shows the license state you expect.
Create the organization and projects
An administrator creates the organization and one project for each system or team that will send traces, following the naming in the design. Separate projects where data sensitivity, retention needs or ownership differ, because roles and retention settings apply per project. Check that the project list matches the design and that no project was created under a test name. Done when every planned project exists once and is recorded with its accountable owner.
Define the role matrix with named owners
The security or governance lead drafts a matrix with one row per person or group and one column per organization and project. Use the Langfuse roles Owner, Admin, Member, Viewer and None, and record the minimum role for exports (Member), trace deletion (Admin) and project deletion (Owner). Name an accountable owner for each project who approves changes to access, and apply least privilege so that people who configure projects are not the same people who delete data. The matrix also supports the logical access evidence for CC6.3 if SOC 2 is in scope. Done when the matrix is approved and stored with your access control records.
Assign organization and project roles
The administrator assigns each user an organization role, then adds project-level roles where a user needs more or less access than the default. Use None for users who should only reach a single project, and confirm that the default role for new sign-ins matches the matrix. If users are provisioned through your identity provider, confirm that the provisioning path is licensed and produces the roles in the matrix. Record the user list with roles and compare it against the matrix line by line. Done when every entry matches and no user is left without an assigned role.
Create project API keys under an Admin
An Admin creates the project API keys, because creating or deleting project API keys requires the Admin role. Keys are scoped to the project, so name each key for the application or service that uses it and record the accountable owner. Copy the secret into your secrets manager at creation time and keep it out of tickets and chat threads. Check that the key list for each project matches the matrix and that keys no longer in use are queued for removal by an Admin. Done when each application has its own key and every key has a recorded owner.
Test each role with a test account
Create one test account per role in a non-production project, then sign in as each account and attempt the actions in the matrix. Confirm that Member can export data, that Admin can delete traces, that only Owner can delete a project, and that Viewer and None cannot change configuration. Record each attempt with the role, the action, the expected result and the actual result. Done when every row passes. Any failure returns to the role assignments in the previous step before production users receive access.
Designing projects, project API keys and export rights for least privilege
Plan project API keys before you create the first project, because in Langfuse a key belongs to a project and not to a person. Whoever creates a key is not the owner of the integration that uses it. If an engineer leaves the team, the keys their project depends on stay where they are, so the project boundary is the unit you must design around. Before rollout, list each application or data source that will send traces, decide which Langfuse project it writes to, and record who is responsible for that project's keys. Confirm in your version of the documentation how the key list shows who created each key, since that information is what your access reviews will rely on.
Langfuse's documented role minimums give you a way to split duties across people. Creating or deleting project API keys requires Admin. Exporting data requires Member. Deleting traces requires Admin, and deleting a project requires Owner. A practical design keeps the group that deploys integrations and manages keys separate from the group that exports data for analysis, and keeps trace deletion with a small set of Admins who have an approved request process. Member is the lowest role that can export, so anyone who needs exports should hold at least Member on the relevant project, while Viewer users who only read dashboards should not be able to pull raw data. Check these mappings against the RBAC page for your release before you write them into an access matrix.
Projects are the main lever for limiting blast radius. One project per application, or one project per data sensitivity class, usually produces a simpler role model than one large shared project with many exceptions. For example, an illustrative setup might separate a customer-facing assistant that handles personal data from an internal evaluation pipeline that uses synthetic prompts. Each project then has its own keys, its own Admin group and its own export rights, and a mistake in one does not expose the other. The cost is more projects to administer and more keys to track, so document the naming convention and the owner of every project from the start.
Key rotation needs a plan that treats the key as a dependency of a running service. Creating a new key, deploying it to the application or collector, confirming that new traces arrive, and only then removing the old key is the order that avoids silent data loss. Before you delete a key, identify every place it is configured, including CI pipelines, OpenTelemetry collector configurations, SDK environment variables and any scheduled jobs. Removing a key stops ingestion from every integration that still uses it, and the traces those integrations would have sent during the gap are not recovered by re-adding the key. Confirm in your version how a removed key is reported to clients and whether the key list keeps any record of deleted keys, because your change tickets and audit evidence will depend on that behavior.
Security controls that Langfuse roles support in self-hosted operation
Langfuse roles set what each person can do inside the application. They do not secure PostgreSQL, ClickHouse, Redis or blob storage, which need their own infrastructure controls. The six points below are the role decisions to make, record and review in a self-hosted instance.
Least-privilege role assignment
Give each user the lowest role that fits their work. Member can view metrics and create scores but cannot change configuration, and Viewer is view only. Set organization-level roles as the default and add project-level roles only where a team needs a different level. Project-level roles need an Enterprise license key when self-hosted, so confirm that before you design around them. Review assignments whenever a team's scope changes.
Separate administration from export and deletion
Exporting data needs Member, deleting traces needs Admin, and deleting a project needs Owner. Decide which people may administer project settings and which may export or delete data. Keep people who grant access out of export and deletion work unless their role requires both. Where one person holds both sets of rights, record the reason and review it on a fixed schedule. This supports the segregation of duties expected under logical access criterion CC6.3 of the AICPA 2017 Trust Services Criteria.
Controlled creation of project API keys
Langfuse API keys belong to a project, so a key is not tied to the person who created it. Creating or deleting project API keys needs Admin. Limit that role to a small group, assign a named owner for each application's key, and record which service each key serves. Ask your team how keys are rotated and revoked when a service changes hands, and test that procedure before go-live.
Review of the Owner role
Owner holds all permissions, including deleting a project, so the list of Owners should stay short. Name a small number of Owners, such as a platform lead and a named backup, and confirm that each one still needs the role. Check that no service account or shared login holds it by accident. Record each review with the date, reviewer and outcome so the result can serve as access review evidence.
Identity provider alignment for joiners and leavers
Langfuse supports SSO through several identity providers and can disable password sign-in or enforce SSO for given email domains. Align these settings with your joiner and leaver process so that disabling a directory account also ends access to Langfuse. Test one offboarding case end to end, including project memberships and any keys the person created. Confirm with your identity team whether SCIM provisioning is in scope, since the org management API with SCIM needs an Enterprise license key.
Logging of role changes
If your Enterprise license covers audit logs, review which events they capture, including role grants and changes, and who can read and export the log. Confirm how long entries are kept before you rely on them as evidence. Without that feature, record each role change through your own change process, such as an approved ticket that names the user, the old role, the new role and the approver.
How Langfuse role design supports SOC 2 CC6.3 evidence
Criterion CC6.3 in the AICPA 2017 Trust Services Criteria asks the organization to grant, change and remove access to data, software, functions and other protected information assets based on roles, responsibilities or system design. Least privilege and segregation of duties must be considered in that process. In a self-hosted Langfuse deployment, the role design is where this criterion first becomes visible, because it decides who can read traces, change project settings, grant access, export data and delete records. Auditors will expect a design you can explain on one page and records showing that people followed it.
Start with a role matrix that maps each job function to a Langfuse role for each project. The roles are Owner (all permissions), Admin (edit project settings and grant access), Member (view metrics and create scores without configuration), Viewer (view only) and None (no default organization access, suited to single-project users). Record where a project-level role overrides the organization-level default. Project-level roles need an Enterprise license key on a self-hosted instance, so confirm licensing before the matrix depends on them. Also decide who owns project API keys, since those keys belong to the project rather than to a user, and creating or deleting them requires the Admin role.
The matrix should state the minimum role for each sensitive action. According to Langfuse's RBAC documentation, exporting data needs Member, deleting traces needs Admin and deleting a project needs Owner. Keep the number of Owners and Admins small and document why each one holds that role. Segregation of duties needs care too: the person who approves an access request should not be the only person who grants it. Illustrative example: a platform engineer who operates the deployment should not also hold Owner on a production project and approve their own elevation. Write such conflicts into the matrix as explicit exceptions with a named approver.
Four record types serve as evidence for CC6.3: approved access requests that show who authorized each grant and when, periodic reviews of role assignments signed off by a reviewer, removal records when people leave or change roles, and version history for the matrix itself. Removal is the weakest point if it is manual. Langfuse supports SSO and can enforce SSO for given email domains, which helps remove password sign-in paths, but SCIM provisioning through the org management API requires an Enterprise license key. Confirm with your identity provider how a leaver's sign-in is disabled and how that event is recorded.
DeployOpen plans and configures these roles, documents the matrix and helps assemble the evidence, but it does not issue audit reports or attestations. Independent auditors decide whether controls meet a criterion. The SOC 2 examination uses the 2017 Trust Services Criteria with the revised points of focus published in 2022. Points of focus help design and evaluate controls, but they are not separate requirements, and not every point of focus has to be addressed. A Type 2 report tests operating effectiveness over a period, so reviews and removal records must exist throughout that period, not only at the start.
Limits to confirm before you finalize the role model
Several parts of the role model depend on your license, your identity setup and the Langfuse version you run. Confirm each item below in the Langfuse documentation and in a test instance before you assign roles to real users. The answers decide which roles you can enforce, so record them alongside your design.
Enterprise license key for project roles
Project-level roles are an Enterprise feature for self-hosted Langfuse, so a design that separates access by project depends on the license key. Confirm whether the plan you are considering includes the key, and who issues and renews it. Ask your Langfuse contact which other features in your design, such as protected prompt labels or audit logs, depend on the same key. Check the license key documentation before you commit to a project structure.
SSO group mapping to roles
Identity provider groups or SSO sign-in can drive organization and project role assignment, but the mapping behavior depends on the Langfuse version and on how your provider passes group claims. Confirm which claims Langfuse reads, whether roles update at each sign-in or only when an account is created, and what happens when a user leaves a group. Test with one user per group and record the resulting organization and project roles for each.
Documented permissions against the running version
The RBAC documentation describes the Owner, Admin, Member, Viewer and None roles and the permissions tied to each. Confirm that the documented table matches the version you run, since a change in permissions would alter who can export data or delete traces. Compare the minimum roles for project API key management, exports, trace deletion and project deletion against your instance, using a test account for each role. Keep the results with your change records.
Role changes during major upgrades
Updates within a major version apply database migrations at startup, but major upgrades follow dedicated migration guides that can change the data model and infrastructure. Confirm whether your target version changes how roles, organizations or projects are stored or read, and whether role assignments need re-checking afterward. The v3 to v4 guide also sets ClickHouse, PostgreSQL and Redis minimums that affect where you can test. Repeat your role tests on a staging copy before production.
Effect of removing an Owner
Owner is the only role with full permissions, including project deletion, so removing an Owner from a project changes who can administer it. Confirm whether Langfuse blocks the removal of the last Owner, what happens to existing project API keys, and whether an Admin can restore the Owner role. Write the answer into your runbook and name at least one Owner with a documented recovery path. Test the removal in a non-production project first.
Whether SCIM provisioning is needed
SCIM provisioning is listed as an Enterprise feature in the org management API, so it is a separate decision from SSO sign-in. Decide whether your team needs automated user creation and removal, or whether SSO sign-in and manual invitations are enough for the users and projects you plan to run. If you need SCIM, confirm the supported endpoints, attributes and license requirements. Test deprovisioning of a user who still holds project roles.
What buyers ask about Langfuse roles, cost, effort and in-house work
Does the open-source version of Langfuse include role-based access control?
Partly. The MIT-licensed open source version includes the core features and APIs, and users receive an organization-level role by default. Project-level roles, which let one user hold Admin on one project and Viewer on another, need an Enterprise license key when you self-host. Langfuse's self-hosted pricing page lists a free open source plan and a custom-priced Self-Hosted Enterprise plan, but it does not quote a price, so ask Langfuse for current terms. Before you design the model, confirm in your version exactly which roles work without a key.
What makes a Langfuse roles project take more effort?
The main drivers are the number of projects, identity provider integration, audit expectations and the sensitivity of prompts. Each project needs an owner, role assignments and project API keys, so every added project multiplies the design and review work. SSO through an Auth.js provider such as Okta, Entra ID or Keycloak adds mapping from directory groups to Langfuse roles and testing of sign-in and enforcement by email domain. If auditors will sample access evidence, you need a written role matrix and a record of who held which role and when. Prompts that contain customer data also raise the bar for who may view traces and export data.
What does the client need to provide before roles work starts?
You need named role owners, identity administrators, and a list of teams and data classes. Role owners decide who receives Owner, Admin, Member, Viewer or None on each project and sign off on the matrix. Identity administrators control the SSO provider, group membership and the group-to-role mapping. The list of teams and data classes shows which projects hold production prompts or personal data, which sets project boundaries and the minimum role for exports and deletions. Confirm early who in your organization owns each of these items, because they gate the design work.
Can a small in-house team set up Langfuse roles using the documentation alone?
A small team can often configure a single project with a few users from the documentation, which covers the roles, the minimum role for each action and the project API key behavior. Effort rises when you add several projects, SSO group mapping and evidence collection for an audit. The work that usually takes the most time is design: deciding who owns what, testing the group mapping and writing the records an auditor will request. Your team also needs to decide whether to buy the Enterprise license key before it designs project-level roles. Decide early whether a partner should cover design, testing, or both.
How long does a Langfuse roles implementation take?
Duration depends on scope, including the number of projects, the identity provider, the number of role groups, and whether the work includes testing and audit evidence. Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. That written plan sets the timeline and shows which items are in the plan and which are left to your team. Ask any provider to name each dependency, including the license key purchase and the identity administrator's availability, and to state when each one is needed.
What does a Langfuse roles engagement cost, and what drives the quote?
The quote follows from the written scope, and DeployOpen does not publish a price list. The cost covers design of the organization and project model, configuration in your environment, SSO integration with your identity team, testing of role boundaries, and documentation or evidence. One-time costs include design, configuration and testing. Recurring costs include the Enterprise license if you choose it, which Langfuse prices on a custom basis, the infrastructure you operate, and any support retainer. Ask for a quote that separates one-time and recurring items and names the tasks your own team will carry out.
Which Langfuse roles do exports and deletions require?
Check the minimum role for each action before you grant access. Exporting data needs Member, deleting traces needs Admin, creating or deleting project API keys needs Admin, and deleting a project needs Owner. Project API keys belong to the project, so a key stays with the project when a team member changes roles. Anyone who holds Admin on a project can create keys for it, so review that role assignment as carefully as the key itself.
How DeployOpen scopes, delivers and supports Langfuse access control
DeployOpen plans the organization, project and role model for your self-hosted Langfuse before anyone is invited, then builds and documents it inside your infrastructure. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- The written scope lists each organization, project and role assignment to be configured in your Langfuse instance.
- It records which roles need the Enterprise license key, such as project-level RBAC, so licensing is settled before build.
- Minimum roles for exports, trace deletion and project deletion are agreed with your access owners.
How we build
- Organization and project structure is configured with Owner, Admin, Member, Viewer and None roles mapped to your access matrix.
- Project-level overrides are set only where a user needs a different role on one project than their organization default.
- Access tests confirm each role can see and perform only the actions the agreed design allows.
How we hand over
- Handover includes a role matrix, a record of project API key ownership and the configuration steps needed to reproduce the setup.
- Runbooks explain how to add a user, change a project role, rotate a project API key and remove access.
- Evidence of access grants and removals is documented in a form your compliance team can use in an assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Role changes, new projects and access reviews can run under a retainer or as a fixed-scope change.
- Upgrades that change the Langfuse version are scoped separately, so role configuration is retested after each one.
