Give your AI agents their own keys

The first agent you gave real access to probably got your access. You were the owner, the tool asked to connect, and the fastest path was the account you were already signed into. It worked. Drafts went out, rows updated, the branch got pushed. Nothing about the moment felt like a decision.

The bill for that shortcut arrives later, and it arrives in a specific form: you want to know what the agent did, or stop it doing one thing while it keeps doing another, or switch it off at 11pm without locking yourself out of your own email. All three are impossible when the agent is wearing your credential. This guide is for solo operators and small teams running agents on accounts they administer themselves. If you have an identity provider, a security team and a joiner-mover-leaver process, you have the machinery already and need a policy that plugs into it, not this.

A shared login is a shared blast radius

An agent running as you breaks three things at once, and they are the three things you will want back.

The first is attribution. Google’s guidance for service accounts, written for the same problem one layer down the stack, tells you to “Create dedicated service accounts for each application, and avoid using default service accounts” [5]. The stated reasons are not paperwork. Audit logs record the service account that made a change but not the application behind it, so “If multiple applications share a service account, you might not be able to trace activity back to the correct application” [5]. Access requirements then diverge, and you find you must grant the shared account “access to an increasing number of resources, which in turn increases the overall risk” [5]. And when one workload is retired, “it might not be clear whether the service account can be decommissioned as well or whether it’s still needed” [5]. Swap “application” for “agent” and the sentences still hold.

The second is containment. Permissions live on the account, so an agent on your account has your permissions by construction. You cannot grant read access to one folder while keeping write access to everything, because there is only one grant and it is yours.

The third is revocation, and it is the one that stings. Rotating a shared password signs out every place it is used, including you, on your phone, in the middle of something else. So you postpone it. Note also what a copied credential means. Google’s guidance is blunt that using a service account key “doesn’t require any previous form of authentication”, that “anyone who possesses a service account key can use it”, and that once a key is in play “there is no reliable way to tell who used the key” [5]. A key you pasted into a tool is a key that tool holds, and a key anyone who can read that tool’s configuration holds too.

Scope the credential to the job, not to you

The fix is not a product. It is using the scoping that the tools already ship, which is usually one screen you have never opened.

In the Claude Console, an API key carries a scope. It is either bound to a single workspace, as {"type": "workspace", "workspace_id": "wrkspc_..."}, or carries no workspace binding at all, as {"type": "organization"} [2]. Organization members carry roles that are just as blunt: user can use the playground, claude_code_user adds Claude Code, developer adds managing API keys, billing covers billing details, and admin does all of it plus managing users [2]. Claude Code adds a narrower seat again: when you invite someone through the Console you can assign the Claude Code role, where “users can only create Claude Code API keys”, rather than the Developer role, where “users can create any kind of API key” [4].

Notion works the same way at the document level. Connections built with its API “follow a similar permission system to the sharing permissions for Notion users”, and a member adds a connection to one individual page from that page’s ••• menu [7]. So the agent that maintains your content calendar gets connected to the content calendar, not to the workspace that also holds your contracts.

The general rule has been written down. OWASP’s 2025 list of LLM risks names excessive agency as “the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM”, and traces it to excessive functionality, excessive permissions and excessive autonomy [6]. Its first two mitigations are the ones to copy: “Limit the permissions that LLM extensions are granted to other systems to the minimum necessary”, and “Avoid the use of open-ended extensions where possible (e.g., run a shell command, fetch a URL, etc.)” [6].

The protocol already assumes narrow tokens

If you want to know where this is heading, read what the connector plumbing has settled on. The Model Context Protocol, the standard that defines how AI clients reach external servers, builds its authorization on OAuth 2.1 in the 2026-07-28 revision of the spec [1]. Authorization is optional in MCP, but an implementation using an HTTP-based transport “SHOULD conform to this specification”, so this is the shape a hosted connector is expected to take [1].

Three requirements matter to you as a buyer rather than a builder. Tokens are bound to one destination: clients must send an RFC 8707 resource parameter that identifies “the MCP server that the client intends to use the token with”, servers must validate that tokens were issued for them, and “MCP servers MUST NOT accept or transit any other tokens” [1]. Scopes are meant to start small: a server should tell the client which scopes an operation needs in its WWW-Authenticate header, “following the principle of least privilege and preventing clients from requesting excessive permissions”, and clients should request only what the current operation needs, asking again later through a step-up flow when they hit an insufficient_scope error [1]. And a server run locally over stdio is outside all of this: those implementations “SHOULD NOT follow this specification, and instead retrieve credentials from the environment” [1].

Read as a purchasing signal, that gives you a test. A connector that asks for one narrow permission now and comes back for more when it genuinely needs them is built the way the spec intends. A connector that asks for full account access on the first screen has skipped the work, and you are the one carrying the risk of that decision. For anything running locally from a config file, the environment is the permission boundary, so whatever you put in that file is exactly what the server gets.

Constrain the actions, not only the credential

A scoped credential answers what the agent can reach. It says nothing about what the agent may do in the next thirty seconds. That is a separate control, and in coding agents it is the more useful one.

Claude Code exposes it as permission modes. default, labelled Manual, “Prompts for permission on first use of each tool”. acceptEdits automatically accepts file edits and common filesystem commands for paths in the working directory. plan reads files and runs read-only shell commands to explore but does not edit your source files. auto “Auto-approves tool calls with background safety checks that verify actions align with your request”. dontAsk inverts the default and “Auto-denies tools unless pre-approved”. bypassPermissions skips permission prompts, and carries a warning to “Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage” [3].

Underneath the modes are rules, and the evaluation order is worth memorizing because it is the opposite of what people assume: “Rules are evaluated in order: deny, then ask, then allow”, and rule specificity does not change that order [3]. A broad deny such as Bash(aws *) blocks every matching call, including calls that also match a narrower allow rule, “so a deny rule can’t carry allowlist exceptions” [3]. Denying a bare tool name “removes the tool from Claude’s context entirely”, while a scoped pattern such as Bash(rm *) “leaves the tool available and blocks matching calls when Claude attempts them” [3].

Two rules earn their place in any repository where an agent runs. A Read deny rule on a path, such as Read(./.env) or Read(./secrets/**), blocks the file tools from reading it, and “also blocks the Edit and Write tools on the same path, including creating a new file there” [3]. And the docs’ own advice for network access is to “use deny rules to block curl, wget, and similar commands, then use the WebFetch tool with WebFetch(domain:github.com) permission for allowed domains”, which gives the agent an allowlist instead of the open internet [3]. Behind all of this sits OWASP’s plainest instruction, which no configuration file replaces: “Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken” [6].

Where the credential actually sits

You cannot revoke what you cannot find, so learn where each agent’s credential is stored before you need to go get it.

Claude Code is unusually explicit about this. On macOS it keeps credentials in the encrypted Keychain, falling back to ~/.claude/.credentials.json with file mode 0600 when the Keychain rejects the write. On Linux that file is the primary store. On Windows it is %USERPROFILE%\.claude\.credentials.json, inheriting the access controls of your user profile directory [4]. If you need a rotating credential rather than a stored one, the apiKeyHelper setting runs a shell script that returns an API key, re-run after five minutes by default [4]. For automation with no browser, claude setup-token generates a one-year OAuth token for the CLAUDE_CODE_OAUTH_TOKEN variable, and that token is deliberately limited: “It can only make model requests” [4].

The uncomfortable implication is worth sitting with. A coding agent with filesystem access and a shell can read every .env file in every project folder it can reach. You did not connect that agent to your payment processor, your database or your email sender, and it makes no difference. Whatever credentials those files hold are credentials the agent can pick up, because a secret in a readable file is a secret you have already handed over. That is the real argument for the deny rules above, and for keeping working directories tight.

Test the off switch on a quiet afternoon

An off switch you have never pulled is a hope. Find each one now, while nothing is wrong, and time yourself.

For anything holding Google data, the control is in your account rather than in the tool. Google’s linked apps page separates three kinds of link, and for an app with access to your Google Account you select it, choose See details, review the access, then “select Remove access” and confirm, after which “the app can’t access your Google Account” [8]. Notion revokes per page: hover over the connection’s name and press Disconnect, and on Enterprise plans workspace owners can go further and “Disconnect members from a connection” [7]. Anthropic keys are managed through the Admin API alongside members, invites, workspaces and service accounts, and keys can be listed, renamed and deactivated there, so a key can be killed without touching the humans [2].

Run the drill once. Open a note, list every tool that can take an action rather than only answer, and next to each write the exact place you would go to cut it off. Then actually cut off one you no longer use, and watch what breaks. The number that comes out of this is the one worth knowing: how long a full shutdown would take you if you had to do it today, under pressure, from your phone.

What still goes wrong

Plenty of tools will not let you do this. A second account costs another seat, the integration offers one password and no key, or the vendor’s idea of scoping is a single checkbox marked “full access”. When you hit that wall, the honest move is to write the tool down as a known exception with a note on what it can reach, not to pretend the scoping exists. Exceptions you have listed are manageable. Exceptions you have forgotten are how a dormant integration is still holding a live token two years later.

Scoping is also not safety. A correctly scoped agent can still be confidently wrong at speed inside its scope, which is precisely OWASP’s point about excessive autonomy sitting alongside excessive permissions [6]. Narrow access limits how far a mistake travels; it does not stop the mistake. That is why the human approval step for high-impact actions [6] is not a beginner’s training wheel you remove once the agent seems reliable. It is the control that stays.

And revocation is not retroactive. Pulling a token stops future access and does nothing about what was already read, copied or sent. If an agent had access to customer data and you are not sure what it did with it, revoking is the first step of the response and not the whole of it. Assume that anything an agent could reach, it may have reached, and let that assumption shape what you grant in the first place.