The agent gets only the permissions it needs, and every call it tries to make leaves a record.
You can scope an agent’s job precisely and still not know what it will do. A support agent drafting a suggested reply in your app might decide the reply is good enough to send. That’s a reasonable call, and nothing on the way out checks it.
The agent only needs one mailbox. Right now it’s using the same API key as the rest of your app, and that key gives it access to every mailbox your app has connected. That’s what it’s for.
So two things have to be settled before it goes near real customer mail. What the agent can reach, which you set when you issue its key. And whose name the log shows when it gets there, which a narrower key doesn’t fix.
When the agent tries something out of scope
Nylas IAM lets you issue a narrower key, one that works on a single mailbox and carries only the permissions that agent needs.
Say you’ve done that, and the key only reads. One day the agent works through a thread and concludes the right next step is to send the reply itself. A line in that thread may have told it to send, or its prompt may have been loose.
It tries. The call comes back 403, and the email never leaves. We check the request before it reaches Google or Microsoft, so nothing was sent on anyone’s behalf.
The refusal lands in Access Activity, in the same format as every call that went through:
The authorization check wrote that entry when it refused the call. The record doesn’t depend on your agent reporting its own behavior. If the agent is broken, or something has talked it into this, the entry still gets written.
Whose name is on the call
Look at that entry again. It names the identity the key belongs to, which is how you trace back to who or what made the call.
In our H2 2026 survey of 1,030 people who build and buy AI systems, 26% said their agents authenticate with an identity of their own. Most of the others run on service accounts, API credentials with no mailbox of their own, a shared inbox, or an employee’s own OAuth.
When the agent authenticates through an employee’s OAuth, your systems have no way to tell the two apart. Every entry carries that employee’s name, including the calls the employee never made.
Scoping a key doesn’t change that. It sets which account the key reaches, not who that account belongs to.
For some agents, a person’s account is the right place to stand. An agent drafting replies inside one person’s inbox is working on that person’s behalf, and that inbox is where the agent belongs.
That stops fitting when the agent isn’t standing in for anyone. Some agents do work that belongs to no particular person, and there was never a user to connect a mailbox for them.
Those need a name@company.com address of their own, one that sends and receives with no user account behind it. That’s what Agent Accounts are, and the customer then replies to the agent’s own address rather than to a person who left last year. The quickstart covers setting one up.
The calls it actually made are in Access Activity, which anyone reviewing the agent can filter and read without booking time with you.
Getting the agent a key of its own
In Nylas IAM you create a principal, which pairs the permissions a key can use with the one resource it can use them on.
A connected account is a grant, which is what you get back when a user connects their mailbox. An Agent Account gets a grant ID of its own, so a principal binds to one the same way it binds to a mailbox a user connected. You make your first principal in the Nylas dashboard, with an Organization binding and the IAM Admin role, and its key is what signs the call below.
That principal can read messages in one mailbox. It cannot reach anything else.
Then issue a credential from that principal, in the dashboard or through its credentials endpoint. That key is what the agent authenticates with, and you only see it once, so send it straight to your secret store. A disabled key stops authenticating and comes back 401.
This sits alongside your application keys rather than replacing them, so you can move one service at a time and reverse any of it. The launch post goes deeper on roles, key expiry, and migrating what you already run.
Before you call it handled
Sometimes the agent just gets it wrong. It misreads a thread, or infers a step nobody wanted. And because it reads mail from people outside your company, there’s prompt injection, where text in a message is written so the agent treats it as an instruction rather than as something to read. A scoped key doesn’t prevent bad input, but it does limit what the agent can reach when acting unexpectedly.
Nothing here changes what your agent decides to do. It changes what happens when the agent acts on it; a key scoped to only read emails can’t be used to send an email. Scoping governs what an agent can reach. The agent’s judgment within its access is still something a person should monitor.
Where to start
Give one agent a key of its own and watch what lands in Access Activity. You still won’t be able to predict what it tries. You’ll be able to show what it reached for.
IAM is included on every plan, so there’s no tier to move to first.
Sign up (or sign in if you already have an account) to create your first principal. The IAM documentation covers roles, bindings, and what Access Activity records.
58% of teams with customer-facing AI agents let them send as an employee at least some of the time. New Nylas survey data on agent identity, mistakes, and audit.
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Professional Services
