Skip to main content
You create a workspace, create a team, invite an internal user, and they log in and try to make a virtual key. They get:
Nothing is broken. Team members start with almost no key permissions, and the grant has to be made deliberately

​
Why it happens

A team carries a team_member_permissions list naming the key-management routes its members may call. Members always get a baseline of /key/info and /key/health, and nothing else unless you add it A team created without that list ends up with [], which means explicitly nothing, so members fall back to the baseline. /key/generate is not in it
The error message is accurate. It just does not say where to go, which is why people usually meet this problem twice before finding the setting

​
Granting it

Open the team, go to the Member Permissions tab, and tick the routes members should have. It sits on the team’s own page, beside Members and Settings
Grant /key/list alongside /key/generate. Without it a member creates a key and then cannot see it, which looks broken in a different way

​
Choosing a grant

The full list of available routes comes back from /team/permissions_list, and includes spend and activity routes as well as key routes

​
What isolation you get

The grant is per team, but ownership is enforced per user underneath it. With the “own keys, full lifecycle” grant above and two members in one team:
Granting the team does not let members reach each other’s keys. Listing is scoped to the caller, and creation, deletion and modification all check ownership. Proxy admins bypass those checks, which is what lets an admin clean up after anyone

​
One caveat worth knowing

/key/info grants read access to any member of the key’s team, so a member holding another member’s raw key string can read that key’s metadata This is not a discovery path. The lookup is by the key value itself, and no listing call will surface another member’s keys, as the table above shows. Anyone holding someone else’s secret can already use it to make billed calls, which is worse than reading its budget and model list. Treat it as one more reason not to share key strings, rather than as a way for members to inspect each other

​
Defaults for new teams

Granting one team changes only that team. A team created afterwards starts at the baseline again
That is deliberate. Making key creation the default for every future team means each new team can mint keys unless somebody remembers to narrow it. Decide it per team, or set your own default consciously

​
Troubleshooting

Confirm it saved by reading /team/permissions_list back. Check you granted the team they are actually creating the key under, and that they picked that team in the Key Ownership dialog
/key/list was not granted. Add it
That is team membership, not key permissions. Check they are listed under the team’s Members tab
Proxy admins bypass the ownership check and can delete any key, with no grant required