[camielvs]

Human Words

Welcome to the top of the stack for the Workspaces x Secrets feature.

The Agentic Tangent-side functionality of this stack is delivered in TangleML/tangent-shell#132.

How it works

This stack builds on top of the Team Impersonation system to allow users to create Workspace-level secrets and execute Pipeline Runs using them.

Workspaces are now associated 1:1 with a Team and through a static config on the backend that Team grants basic roles to users based on their Team membership. Users with Team permissions are then able to create, edit and manage secrets on the entire Workspace, and add them to their pipelines.

When a pipeline is submitted with a Workspace secret the initiating user must have team permissions. That Run will then be Attributed to the team and utilise its secrets. It is not possible to mix user-personal secrets and workspace secrets in one pipeline. Additionally, for runs that do not use secrets the user will have a choice of submitting as themselves or the team. It is also not possible to run a pipeline that uses Workspace secrets from outside of that Workspace.

Tangent agents have access to the same functionality, based on Team membership of the user who initiated the turn, via tangent-shell PRs.

Screenshots

Testing

1. Set up a Workspace with a team id you have permissions in
2. Create a project in the workspace
3. You should now see a new window for "Workspace Secrets"
4. Confirm you can add/edit/delete workspace secrets
5. Make a pipeline inside the Project
6. Confirm you can add the Workspace secrets to the pipeline and run it

AI Words

Description

Tangent agents submit runs two ways. The tool bridge into a pipeline or run tab acts as the project's team since #2943. The agent's own server-side tools didn't, so their runs went as the user. A run that used a team secret then failed at launch with "User … does not have secret …".

A Tangent session is shared, so the team can't be fixed when it starts: it would act for whoever types next, member or not. It's granted per message instead:

• getActingTeam: the page passes it to TangentProvider. Tangent reads it as each message is sent and attaches the team to the agent turns that message causes, including work Prime hands to sub-agents.
• A grant, not a default: on a granted turn, a team-scoped Tangle call (run submit, cancel, annotation writes, secrets list) acts as the team only when its tool asks (asTeam), and goes as the user otherwise. So agents can still list and use the user's own secrets. The tangent-shell server adds the team header itself and strips any copy an agent sends.
• What it grants: the team id while the signed-in user can act as the project's team, and nothing for any other resolution. It doesn't check that the session belongs to this project, because the opening prompt is sent before the session is attached and such a check would refuse it.
• Session memory: a project-level brief, the same for everyone in the session. It names the project's workspace and its team id, and calls the team the workspace, as the UI does. It says a turn may act as the workspace only when its sender is in it and grants it, and that even then each call opts in (asTeam). It says to check secrets and submit as the same identity, and to act as the workspace when the user asks or the run needs a secret only the workspace has. It also says never to send the header, where to see the turn's grant, and not to retry as the user unless asked. A project without a known team gets no brief.
• Session start: a session isn't started while the team is still being checked, so the opening prompt goes out with the team granted. The arrival waits for the team, and New session says to try again in a moment if it's clicked first.

The tangent-shell side is TangleML/tangent-shell#132, not yet merged. This PR pins @tangent/embed-react and @tangent/shared to its head, d229883, so getActingTeam exists and the team it grants is one each agent call opts into.

Related Issue and Pull requests

• Stacked on feat(runs): act as a run's team on its run page #2944.
• Needs feat: grant the Tangle team per message, not per session tangent-shell#132. Repin to its merge commit before this merges.
• TangleML/tangent-shell-shopify#15 adds tangle_secret_list, an asTeam option on it and on tangle_run_submit, and reports the turn's grant in tangle_root_config_show. The brief refers to all three.

Type of Change

• New feature

Line Breakdown

Category	Added	Removed
Production code	84	4
Tests	196	1
Config / CI / tooling	4	4
Generated / lockfiles	17	17
Total	301	26

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

None. There's no UI change beyond the "still being checked" notice.

Test Instructions

pnpm vitest run src/routes/v2/pages/Tangent

Against a local tangent-shell on feat/per-turn-team-impersonation (TangleML/tangent-shell#132), with the tangle 3.6.1 bundle from TangleML/tangent-shell-shopify#15, and a backend that honours the header:

1. As a member, in a team's project, start a new session and ask the agent to list secrets. It lists yours, and the team's when you ask for them. Ask it to submit a pipeline that uses a team secret: the run's "Created by" is the team's id, and the secret resolves.
2. Same session, a pipeline that uses only your own secret: it goes as you.
3. As someone not in the team, send a message in that same session asking for a run. It goes as you, and the agent doesn't act as the team.
4. In a project without a team, it behaves as on master.

Additional Comments

If the host's __TANGLE_TEAM_IMPERSONATION__.headerName is ever anything other than x-tangle-impersonate-team-id, the tangent-shell server's TANGLE_TEAM_HEADER must be set to match. tangle-ui no longer passes the header name to Tangent.

🤖 Generated with Claude Code

[github-actions]

🎩 Preview

A preview build has been created at: cvs/agent-session-team/04050bb

[camielvs]

🤖 This is an AI-generated code review comment.

Tangent still grants read-only workspaces per message

actingTeamId(...) returns the team id for any active resolution, including canWrite: false. That means a user with only read access to the workspace still grants the team id to every Tangent message. The session memory tells the agent it may call tools with asTeam, and tangent-shell will receive a team grant for a user who should not be able to create workspace-owned runs/use workspace secrets for writes.

Please only grant getActingTeam when resolution.status === "active" && resolution.team.canWrite. If read-only users should still inspect workspace-scoped data, keep that as a separate read-only code path rather than using the same acting-team grant.

[camielvs]

🤖 This is an AI-generated code review comment.

Whether a session gets the workspace brief depends on who started it.

The brief describes the project, not the person, and the PR calls it "the same for everyone in the session". But it's written once, from the resolution of whoever starts the session, and an error resolution writes no brief. So if the starter's identity check failed, the session never gets the brief, even when a member who types later is granted the team and their turns would need it. Base the brief on the team of the project's workspace (teamOfWorkspace), not on the starter's resolution.

[camielvs]

✅ Manually smoke tested by @camielvs.

[camielvs]

🤖 This is an AI-generated comment.

Closing: per-message team gating is out of scope. The workspace secrets UI ships through #2944, and tangent-shell is expected to handle agents' team submission, so this PR's per-message grant and its pin to TangleML/tangent-shell#132 aren't needed.

Nothing below this PR depends on it. #2927–#2944 don't use its code or the newer @tangent/embed-react, and they keep master's pin. The branch stays in case per-message gating comes back.