Hi there, I'm not sure to understand the way users, teams and tokens management is handled within Pulumi at the "Teams" plan level : • Even if the plan is called "Teams", no access to teams in the organization • A "member" of the organization is actually not a member from an OIDC standpoint :

invalid_request: internal error creating personal token validation error user is not an organization member

and can basically do nothing in this plan since "Members can access stacks based on organization settings." but this is not available on this plan • Wanting to give a member the administrator access to resolve this problem, while not ideal and definitely not a good security practice, is actually not possible because "This organization can only have one administrator. By making [member] the administrator, you will no longer be able to manage this organization's subscription or permissions." So, what's the point of having an organization, members and paying for this plan if there is actually no real benefits doing so ? Additional question : From what I understand, the pulumi OIDC with "Teams" plan is actually wide open and does not provide some granular control over what we grant to, say, a github CI workflow since we need an admin token, right ? So this is not possible to "protect" who has access to what and restrict access to production esc envs, secrets or deployments, that's an all or nothing type of policy, which is really not great from a security standpoint.

Hey @faint-motherboard-95438 - All good questions. One subtle but important clarification - there are three editions: • Individual - For individuals • Team - For a single team • Enterprise - For an organization with multiple teams Notably, the Team edition is not "Teams", it is designed for a single team to collaborate. The features to support managing multiple teams within an organization is available in the Enterprise edition, which supports all the features I believe you are looking for here. The error message you mention for OIDC Issuers on Team is a little surprising to me - I'll look into whats going on there.

👋 I am looking into that error message. That seems to be coming from a validation to assure the user belongs to the organization. How are you performing the token exchange? Manually or using the GitHub Action? could you share the parameters set (including the organization and the user names)?

Hey @white-balloon-205 Thanks for your response. That's indeed subtle about Team. While I understand the different tiers from a product and pricing perspective, it seems the Team tier lacks some basic granular control over what individual team members can do. I don't think adding basic permissions would deter conversions from Individual/Team to Enterprise, as organizations require much more from the Enterprise tier, while basic permissions are critical for managing multiple users in the Team tier, especially from a security standpoint. Adding some basic permissions to access stacks/environments would make it a more compelling option for small teams compared to Individual and Enterprise tiers. Right now I feel there's little incentive to pay for it when we can achieve the same with a shared free Individual account. The main attraction was the addition of a security and permission layer (mainly for CI), but since that's not possible with this tier, we would have to choose between jumping to Enterprise or sticking with Individual. Not sure that's how you intended it.

Glad it is sorted out, I will look into improving the validation errors to make it easier to troubleshoot