#Least privilege for environments, secrets, MCP servers, and Linear

Use this page to answer "who can reach this credential?" for your own security team. It covers environments, secrets, and MCP servers held by your organization, and the Linear connection. The examples use an organization called engteam.

#Who can do what

These permissions come from your organization role and, for runs, your workspace role. See Roles for the full tables.

No role can read an environment value or a secret value back. Tessl seals each value when you save it, and no page, API route, or CLI command returns it.

#The access rule

A run is one execution of a loop, such as a schedule firing or a tessl launch skill command.

Anyone who can start a run in a project has access to the values of every environment bound to that project. Tessl gives the run its environment's values as variables, and the run's plugin and prompt can use them as they choose. Tessl redacts those values from the run's stored transcript, but redaction isn't guaranteed: a short value, or one the run encodes or transforms, can still appear. Give an environment only credentials you'd trust to everyone who can start a run in its projects.

In a project's workspace, a publisher, manager, or owner can start a run, and so can every organization admin, because an admin holds the owner role in every workspace. A workspace member or consumer can't.

What follows from the rule:

• One environment per trust level. Keep a production credential out of an environment that holds a sandbox credential. If two groups of people should reach different credentials, give each group its own environment.
• Bind to the fewest projects. Each binding gives a project's publishers, managers, and owners access to the environment's values. Bind only the projects whose runs need them, and unbind a project when it stops needing them. A new environment created in the web app is bound to no project, and a new project starts unbound. See Bind projects to an environment for the web app and tessl environment bind and tessl environment unbind.
• Review who can start runs. Before you bind an environment, check the publishers, managers, and owners of the project's workspace.

#Run permissions

Each environment also has four permissions that limit what Tessl lets its runs do. An organization admin sets them when they create or edit the environment.

• GitHub access: none, read, pull-requests, or write. The default is read, which checks out the repository and reads pull requests and issues, and also reads check runs, commit statuses, and Actions runs and logs when the Tessl App installation covers the repository and holds those permissions. Choose pull-requests for a run that pushes branches, opens pull requests, or comments on, edits, or merges them. It can also push to, create, and delete any branch or tag that branch protection leaves open, and create and manage releases, but it can't write issues, statuses, checks, Actions, or workflow files. Choose write only for a run that needs one of those as well. Choose none when the environment supplies its own GITHUB_TOKEN or GH_TOKEN: Tessl rejects an environment that holds one of those tokens at any other level, and an environment set to none that holds no token can't start a run.
• Linear access: none, read, or write. The default is none. read allows read queries only; write also allows changes such as creating issues and comments. Raise it only for a run that works with Linear issues. See Linear.
• Read other runs' logs: off or on. The default is off. When it's on, a live run can read the transcripts of other runs in the same workspace. Turn it on only for a run that reviews or reports on other runs, since transcripts can hold anything those runs printed.
• Tessl token role: consumer, member, or publisher. The default is consumer. This is the workspace role of the TESSL_TOKEN that Tessl gives each run. consumer can install plugins and view the workspace. member adds running reviews. publisher adds creating and running evals and publishing plugin versions. At every level, the token can't change projects, loops, or environments, and can't create API keys. Raise it only for a run that publishes plugins or runs evals.

#Secrets and plain values

An environment can hold a value in two ways.

• A plain value is typed into the environment itself. It belongs to that environment only.
• A secret is saved once in the organization's Secrets settings and referenced by name from any number of environments. Rotating the secret updates every environment that references it, from each environment's next run.

Both kinds are sealed when you save them, and neither is ever shown again. Every organization member can see variable names and secret names, and the Secrets page shows each member which projects receive each secret. Don't put a credential in a variable name or a secret name.

Use a secret when more than one environment needs the same credential, so you rotate it in one place and can see every project that receives it. Tessl refuses to delete a secret while an environment still references it.

#MCP servers

An organization admin registers and authorizes an MCP server in the organization's settings. A run can reach an organization MCP server only when the run's environment names that server. A run with no such environment can't reach it, even in a project of the same organization.

To limit who can use an MCP server, name it only in the environments that need it, and bind those environments only to the projects that need them.

Naming an MCP server in an organization environment isn't yet available in the web app or the CLI. The environment page shows the server names an environment already holds but doesn't let you change them. To name a server in an organization environment, contact support@tessl.io.

A server that Tessl moved from a workspace into the organization is the exception, and bindings don't limit it. Runs in its former workspace can still name it directly, with no environment, and members of that workspace can still call it through Tessl. The MCP servers page marks these servers as moved from a workspace.

#Linear

The Linear connection gives runs one Linear token, held by Tessl. A run uses that token only when its environment sets Linear access to read or write. Setting it to none withholds the Tessl token only: an environment set to none can still hold its own LINEAR_TOKEN, and a run with that environment calls Linear with whatever that token can reach. Tessl rejects an environment that holds LINEAR_TOKEN or LINEAR_API_URL at read or write. The Linear connection isn't offered on the EU region.

#What the token can read

This section describes public Linear teams.

• The token reads only the teams in the Tessl app's Team access setting in Linear: "All public teams", "All public teams and select other teams", or "Only select teams". For those teams it reads issues, comments, projects, documents, workflow states, and team labels. It returns no data from other teams.
• Whatever the team access, the token reads every user in the Linear workspace (name, email, and admin flag) and the workspace-level labels.
• The installing Linear admin's own team membership doesn't limit the token. A Linear admin can grant a team they aren't a member of.
• Linear keeps one install per Linear workspace. Connecting again reuses that install and its team access.
• A Linear admin can change the team access at any time, and the token's reads change at once.

#The two controls

1. Team access in Linear. Set it on the Tessl app in your Linear workspace settings. It decides which teams' data the token can read.
2. Which projects receive a Linear-enabled environment. Only runs whose environment sets Linear access to read or write can use the Tessl token.

Team routes in Tessl decide which Linear teams' issues start runs in which project, and a route can ignore a team so its issues start no runs. They don't limit what a run can read.

#Disconnecting

An organization admin can disconnect Linear in the organization's integration settings. Disconnecting removes the connection from your organization. When no other Tessl connection still uses the same Linear workspace, Tessl also revokes its grant at Linear and deletes the stored token. While another connection uses that Linear workspace, for example one held by another organization, the grant and its team access stay in place for that connection.

If the Tessl app still shows as installed in your Linear workspace settings after you disconnect, a Linear admin can uninstall it there.

#Checklist before you bind an environment

1. Who are the publishers, managers, and owners of the project's workspace? Each of them has access to every value in the environment.
2. Does the environment hold only the credentials this project's runs need, at one trust level?
3. Is GitHub access the lowest level the runs need?
4. Is Linear access none unless the runs work with Linear issues, and does the environment hold no Linear credential of its own that the runs don't need?
5. Is reading other runs' logs off unless the runs report on other runs?
6. Is the Tessl token role consumer unless the runs publish plugins or run evals?
7. Does the environment name only the MCP servers the runs need?
8. Is each shared credential a secret, so you can see every project that receives it?

#Related pages

• Environments: create an environment and supply its values
• Roles: organization and workspace roles and their permissions