Your AI Agent Needs Its Own Keys

The first thing most teams do when they connect an AI agent to their email is hand it someone's personal login. Usually the founder's. Sometimes the office manager's. The agent reads, drafts, maybe sends, and everyone moves on to the next problem.

This works until it doesn't. And when it stops working, it stops working in ways that are hard to unwind. We build AI agents that operate across client accounts at Airtight Design. Email, calendars, document storage, project management: the full stack of business tools that agents need to touch to be useful. Along the way, we've learned that the authorization model you choose for your agent is one of the most consequential early decisions you'll make. Get it right and your agent scales cleanly. Get it wrong and you'll be rearchitecting under pressure six months from now.

Two models, one fundamental question

The question is simple: whose identity does the agent use?

The on-behalf-of model gives the agent access through the end user's own credentials. When Sarah from marketing asks the agent to check her calendar, it authenticates as Sarah and sees exactly what Sarah would see. Different users get different access. The agent inherits the organization's existing permission structure. This is elegant when it works. The agent can't see anything the user can't already see, which makes the security story straightforward. But it creates real friction. Every user needs to authenticate separately. The agent's capabilities vary by who's talking to it. And if the agent needs to do something on its own (send a follow-up, check a deadline, process a queue), it has no identity to fall back on.

The dedicated credential model gives the agent its own account. A purpose-built identity with permissions scoped to exactly what the agent needs. No more, no less. The agent authenticates as itself regardless of who triggered the action.

This is what we use at Airtight, and it's what we recommend for most client deployments.

Why dedicated credentials win in practice

When we deploy an AI agent for a client, we don't connect it to Josh's Gmail or Shannon's Google Drive. We set up dedicated accounts, or at minimum, dedicated OAuth tokens scoped to specific services, so the agent operates with a clear, auditable identity.

Here's what that looks like in practice.

For a typical engagement, our agent might need access to email (reading and drafting, not sending), a shared calendar, project documents in Drive, and a project board in Jira. Each of these gets its own authentication token with the minimum scope required. The email token can read messages and create drafts but can't send. The calendar token can read events and check availability but can't delete. The Drive token has access to specific shared folders, not the entire organization's files.

This granularity matters because agents make mistakes. They hallucinate. They misinterpret instructions. They occasionally try to do things you didn't ask for. When that happens, the blast radius is defined by the credential scope, not by whatever human account the agent happened to borrow.

The human-in-the-loop layer

Dedicated credentials pair naturally with human approval gates. Our agents draft emails but don't send them. They propose calendar changes but don't confirm them. They create Jira tickets in a staging state, not directly on the board.

This isn't a limitation. It's a design choice. The agent handles the cognitive work of reading, synthesizing, and drafting. A human handles the judgment call of whether that draft actually goes out. The dedicated credential model makes this separation clean because the agent's permissions enforce it. The token literally cannot send the email. The approval gate isn't just a UI pattern; it's baked into the authorization layer.

With on-behalf-of credentials, you'd need to build that constraint in application logic. The agent has Sarah's full permissions but you've added code to intercept certain actions. That works until someone refactors the middleware or the agent finds a different API endpoint.

Multi-account, multi-client complexity

The real test comes when your agent works across multiple accounts or clients. We manage separate credential sets for different organizations: one set scoped to Airtight operations, another scoped to a client's environment, each with different permission boundaries and different approval workflows.

With dedicated credentials, this is a configuration problem. Each client gets an isolated credential set. The agent knows which set to use based on the context of the request. There's no risk of cross-contamination because the tokens are fundamentally separate.

With on-behalf-of credentials, multi-tenancy becomes an identity mapping problem. You need to know which user is asking, resolve their credentials for the right organization, handle the case where they have access to multiple orgs, and maintain all of those mappings as people join and leave. It's solvable, but it's a different category of complexity.

When on-behalf-of makes sense

Dedicated credentials aren't always the right call. If you're building a product where each user interacts with their own data through the agent (think a personal email assistant or a coding copilot), on-behalf-of is the natural fit. The agent is an extension of the individual user, and the permission boundary should match that relationship.

The decision point is whether the agent represents the organization or the individual. If the agent is doing things the organization wants done (processing a shared inbox, monitoring a project board, triaging support tickets), it should have its own identity. If it's augmenting a single person's workflow with their own data, it should use that person's identity.

Getting started

If you're deploying an agent today, here's the practical starting point:

1. Create a dedicated service account for the agent in every system it touches.
2. Scope each credential to the minimum required permissions. Read-only where possible. No delete access unless the use case demands it.
3. Build approval gates at the authorization layer, not just in application code. If the agent shouldn't send emails, don't give it send permission.
4. Separate credentials by client or business unit. Never share tokens across trust boundaries.
5. Log everything the agent does under its own identity. When something goes wrong (and it will), you want a clean audit trail.

The authorization model for AI agents isn't a security afterthought. It's a foundational architecture decision that shapes what your agent can do, how safely it can do it, and how gracefully it scales. Most teams figure this out the hard way after their first incident. You don't have to.

Airtight Design builds AI-powered delivery systems for web development agencies and their clients. If you're exploring how agents fit into your workflow, we'd like to talk.