Nylas Lets Agents Hold a Key to One Mailbox Instead of the Whole App
Nylas IAM issues API keys bound to one grant, workspace or application, with roles, expiry and a 400-day audit log of allowed and denied requests.
Nylas now lets a team issue API keys that reach one connected mailbox instead of every account in an application, the company said in an Oct. 6 changelog entry. The feature is called Nylas IAM, and Nylas pitches it at services, workers and AI agents.
A key can be bound to one grant
Every IAM principal gets exactly one resource binding, according to the Nylas documentation, last updated Oct. 6. The choices are one grant (one connected mailbox or calendar), a workspace, an application or the whole organization. A principal combines that binding with roles and direct permissions. IAM API keys inherit all of it.
The documentation contrasts these with application API keys, which give application-wide access to every connected account in that application. Nylas recommends IAM keys for production workloads that don’t need that reach. Its example is a mailbox-processing worker bound to one grant.
Roles, expiry and rotation are built in
Nylas provides system roles that can’t be edited. Teams can also write custom roles or attach permissions directly to one principal. The resource binding stays the outer limit. A permission the binding doesn’t support shows as ignored in the Dashboard and grants nothing.
Keys carry an optional expiration in days, and the secret appears once at creation. Nylas describes zero-downtime rotation as creating a second key for the same principal, deploying it and then deleting the old one. A disabled or deleted key returns 401 Unauthorized. A request outside the key’s binding or permissions returns 403 Forbidden.
Every allowed and denied request is logged for 400 days
Nylas keeps two audit views for 400 days, the documentation says. Config Changes records edits to principals, credentials, roles, permissions and bindings. Access Activity records allowed and denied API, authentication and MCP requests made with IAM keys. Each event links to the underlying request logs.
Provider scopes still apply
IAM limits what a caller can do through Nylas, and nothing more, the documentation says. Provider OAuth scopes still decide what a connected Google or Microsoft account has authorized. IAM can’t widen them. A provider scope can’t override an IAM denial either.
Nylas also said IAM is configured only in the Dashboard. Management isn’t available through the public API or the Nylas CLI.
Key takeaways
- IAM keys are bound to one grant, workspace, application or organization.
- Roles, direct permissions, expiry and rotation are supported.
- Access Activity logs allowed and denied requests for 400 days.
- Setup is Dashboard-only, with no API or CLI.
The take
We think this is the right fix for an obvious risk: an agent holding an application-wide key can read every customer’s mail, even if it only needs one inbox. A narrow key limits the damage when a prompt is hijacked or a secret leaks. The worst case shrinks to one mailbox.
The audit log matters as much as the key. A denied request is often the first sign that an agent is doing something it shouldn’t. 400 days is long enough to look back over a quarter or more.
Teams on Nylas should list every worker and agent that uses an application key today. For each one, create a principal bound to the narrowest resource it needs, swap in the new key and watch Access Activity for denials. Plan on doing it by hand in the Dashboard for now.
