Lambda adds cloud access controls so scripts need not use personal keys

Scripts running on Lambda Cloud can now have their own accounts and limited permissions instead of borrowing a person’s full access. Lambda introduced identity and access management, or IAM, on November 4, 2026. The free release brings roles, groups and software identities into the console, giving administrators finer control over their GPU cloud.

Two checks before a resource can be used

Previously, Lambda Cloud offered two roles, Admin and Member, and each API key carried its owner’s full permissions. Lambda illustrates the problem with a nightly script that cleans up idle instances: using someone’s personal key gave that script the same access as the person, rather than access tailored to its job.

The new controls work alongside workspaces, which determine where resources live. To act on a resource, an identity needs both membership in its workspace and a role permitting the action. Workspace membership alone is not enough. Roles bundle specific permissions at either the account or workspace level.

The predefined roles include Account Admin, IAM Admin, Billing Admin, Workspace Owner, Workspace Member and Instance Reader. Service identities are accounts for software, such as scripts and pipelines, with their own keys and roles. Lambda also labels its own managed identities, which perform operations such as maintenance on customers’ behalf.

Groups can contain both people and service identities. Assigning a role to a group passes it to everyone in that group, and groups can also join workspaces. Lambda recommends organizing groups by team or job, so onboarding means adding someone to a group and offboarding means removing them in one place.

Moving scripts off personal keys

Administrators reach the controls through Account > Configuration > IAM, with tabs for users, service identities and groups. Only account admins and IAM admins can see or change IAM. For teams starting with existing automation, Lambda recommends a script-by-script move rather than leaving software attached to a person’s credentials.

1. Give one script its own identity. Choose automation currently using a personal API key, create a service identity and grant only the roles the script needs. Set an expiration date for the new API key.
2. Use the key-rotation controls. A service identity can hold two keys at once, allowing teams to rotate credentials. Administrators can revoke a key from the identity’s details page at any time.
3. Delete the old personal key after moving the script. Creating a service identity does not retire that credential. An old personal key stays live until someone deletes it.

The release preserves existing setups: Admin and Member map to Account Admin and Account Member, respectively, while current API keys remain unchanged. IAM itself carries no additional charge; customers continue paying for the computing resources they run.

Checking permissions inherited through groups

Lambda’s effective access view shows every role an identity holds in each workspace, including roles inherited through groups. The company cautions that group membership can quietly increase access, and recommends checking this combined view before trusting that an identity has only the permissions intended for it.

A user’s details page brings together their API keys, groups and roles, and provides the control for removing that person. Audit logs separately cover keys, identities, workspaces and resources. These records are captured automatically, giving administrators a history of activity alongside the view of current permissions.