AI Agent Credentials: How to Scope Them, Step by Step (2026)

To scope AI agent credentials, give every agent its own identity, grant it only the actions its job needs, issue tokens that expire in minutes or hours, and put a human approval step in front of anything you can't undo. An agent should never log in with a person's username and password, and it should never hold a key that can do more than the task in front of it.

This matters now because agents have moved from reading data to taking actions: sending email, editing records, moving money, merging code. OWASP lists excessive agency as risk LLM06 in its 2025 Top 10 for LLM applications and names three causes: excessive functionality, excessive permissions and excessive autonomy. Credential scoping is the fix for the second one, and it limits the damage from the other two.

This guide walks through the build in order: inventory, identity, scopes, token lifetime, approval tiers, logging and revocation. It includes the specific controls GitHub, AWS, Stripe, MCP and Claude Code give you, a tier table you can copy, and a checklist for a smaller team.

What does credential scoping mean for an AI agent?

Credential scoping means the credential an agent holds decides what it can do, not the prompt. If the model is confused, manipulated by a prompt injection attack or simply wrong, the credential is the last line that holds.

OWASP's guidance says the same thing in its own words: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." A system prompt that says "never delete customer records" is a request. A key with no delete permission is a control.

Three properties make a credential well scoped:

• Owned by one agent. Every action in a log points to one agent, not to "the integration account".
• Narrow. The key covers the systems and actions on the agent's task list and nothing more.
• Short-lived. If it leaks, it stops working soon on its own.

If you want the conceptual background on agent identity as a category, our guide to AI agent identity and access management covers it. This post is the implementation side.

Step 1: Inventory what each agent touches

Write a one-page inventory per agent before you create a single key. For each system the agent reaches, list the narrowest action it needs, not the broadest one the API offers.

The right-hand column is what you get when someone grabs the fastest key to set up. The gap between the two columns is your attack surface. Write it down before the agent is connected to anything, because it is much harder to take access away later than to never grant it.

Step 2: Give each agent its own identity, never a shared human login

The worst pattern is an agent signing in as a person. It breaks three things at once. Your audit log can't separate the human's actions from the agent's. Revoking the agent means resetting the person's password. And the agent inherits everything that person can do, which is almost always far more than the task needs.

This is the line JPMorgan Chase drew in October 2026. A bank spokeswoman told CNBC in a story published October 13, 2026: "Because it is not safe, we do not permit third parties to access accounts by obtaining customers' banking credentials and logging in on their behalf." She added that the bank supports "secure, customer-authorized data sharing through open banking providers." The distinction is the whole point of this guide: shared login, no; a scoped, authorized connection, yes.

The fix is a non-human identity per agent. Depending on the platform that means:

• A dedicated service account or OAuth client registered for the agent.
• A GitHub App instead of a developer's personal access token.
• An IAM role the agent assumes, instead of an engineer's access keys.
• A restricted API key created for that agent alone.

One identity per agent, not per team. If your support agent and your billing agent share a key, a bug in one becomes a breach of both. Stripe's docs say it directly for their keys: create a separate restricted key for each service and give each key only the permissions that service needs.

If a platform only offers "log in as a user" as its integration method, treat every agent connection through it as high risk. Put it behind the confirm tier in Step 5, or keep the agent off it.

Step 3: Scope the credential on the platform you already use

Most of the platforms agents touch already have the controls. You just have to use them instead of the default key.

GitHub: use an App, not a personal token

A GitHub App installation token can be cut down at the moment you mint it. GitHub's docs say you can "use the repositories or repository_ids body parameters to specify individual repositories," and the permissions parameter narrows what the token can do. The token can't exceed what the App was granted, and "the installation access token will expire after 1 hour." For a code review agent, mint a token per run for the one repository under review, with read on contents and write on pull requests.

AWS: assume a role per task, with a session policy

AssumeRole returns temporary credentials. AWS documents that the session's permissions are "the intersection of the role's identity-based policy and the session policies," and that you "cannot use session policies to grant more permissions than those allowed by the identity-based policy of the role." That gives you two layers: a role that caps the agent, and a session policy per task that narrows it further. Session duration runs from 900 seconds up to the role's maximum (1 to 12 hours), with 3,600 seconds as the default. Set SourceIdentity or a clear RoleSessionName so CloudTrail shows which agent acted.

Stripe: restricted keys, one per agent

Stripe's own docs now say restricted API keys "are the recommended type of key for API keys you give to AI agents." Each resource is set to None, Read or Write, and everything defaults to None. A billing assistant that answers "what did this customer pay last month" needs Read on Customers and Invoices. It does not need Write on anything. Use the key's request logs to see which calls it actually makes, then remove what it never used.

MCP: audience-bound tokens, no passthrough

If your agents reach remote (HTTP) MCP servers, the authorization spec (version 2025-06-18) builds on OAuth 2.1. Clients must send a resource parameter so the token can be bound to one MCP server, and servers "MUST validate that access tokens were issued specifically for them." The spec also forbids token passthrough: an MCP server that calls an upstream API must use a separate token for it and "MUST NOT pass through the token it received from the MCP client." When you build or buy an MCP server, check those two rules first.

Claude Code: deny rules beat allow rules

For coding agents, the credential is partly the permission config. Claude Code's docs state: "Rules are evaluated in order: deny, then ask, then allow." A broad deny such as Bash(aws *) blocks every matching call even when a narrower allow rule also matches, and Read(./.env) blocks the file tools from reading your env file. The docs also note that these rules don't cover a script that opens files itself, so pair them with the sandbox when a restriction has to hold. A Claude Code security audit checks exactly this: which tools, paths and credentials your agents can really reach.

Step 4: Make tokens short-lived by default

A long-lived key is a standing liability. If an agent's key leaks through a log line, a crash dump or a tool output the model echoed back, a token that expires in an hour limits the window. A key that lives until someone remembers to rotate it doesn't.

The MCP spec puts it plainly: authorization servers "SHOULD issue short-lived access tokens to reduce the impact of leaked tokens." In practice:

• Mint per run, not per deployment. The agent's runtime fetches a fresh token when a task starts, from a broker that holds the long-lived secret. The agent process never sees the root credential.
• Match the lifetime to the task. A code review that takes ten minutes doesn't need a twelve-hour session. On AWS, pick the shortest DurationSeconds that covers the job.
• Keep the root secret out of the model's reach. Store it in a secrets manager the agent can't read directly, and deny file access to .env and key files in the agent's own tool config.
• Rotate the keys that can't expire. Some platforms, such as Stripe restricted keys, don't expire on their own. Put them on a rotation schedule and give each one a clear owner.

Step 5: Use approval tiers, not one on/off switch

Scoping decides what an agent can do. Tiers decide what it can do without asking. A single "approved" toggle is too blunt, because reading a ticket and issuing a refund carry very different risk.

OWASP's mitigation list includes this directly: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Two rules make the tiers hold up:

1. Enforce them in code. The confirm step lives in the tool layer or the downstream API, not in the prompt. The model can't skip a step it has no way to call around.
2. Blocked means absent. If an agent should never export your customer list, don't give it an export tool with a warning in the description. Remove the tool. Claude Code does the same thing with a bare deny rule: the tool is removed from the model's context entirely.

Step 6: Log every action somewhere the agent can't edit

An audit trail only works if the agent can't rewrite it. Send agent actions to a store the agent has no write or delete access to, separate from the systems it operates on.

Log at minimum:

• Timestamp and the agent's own identity (not a shared account)
• The task or run ID that triggered the action
• The tool called, the system touched and the arguments
• The outcome, and who approved it if it was a confirm-tier action

Platform logs help here if your identities are clean. AWS CloudTrail records the role session name and source identity. Stripe shows request logs per restricted key. GitHub attributes App actions to the App. None of that works if five agents share one key. OWASP also says logging won't prevent excessive agency but can limit the damage, which is the honest way to see it: logs are how you find out, scoping is how you limit what there is to find.

Step 7: Test revocation before you need it

A scoped credential is only as good as how fast you can kill it. Run a drill before an incident forces the first real attempt:

1. Disable one agent's credential.
2. Confirm that agent stops working within minutes, not hours.
3. Confirm no human account and no other agent broke.

If revoking one agent means rotating a secret that five other integrations share, you've found a scoping failure. Fix it while it's a drill. Short-lived tokens make this easier: you stop issuing new ones and the old ones expire on their own.

What credential scoping looks like for a smaller team

You don't need a bank's security staff to do this. A small team running a few agents can cover the core with this checklist:

• One identity per agent: a GitHub App, an IAM role, a restricted key, an OAuth client
• A written inventory per agent: systems, allowed actions, owner
• Tokens minted per run where the platform supports it
• A confirm step on money, deletes, access changes and merges
• Dangerous tools removed from the agent's tool list
• An append-only action log you actually review
• One revocation drill per agent

Most of the effort goes into one decision: writing down what each agent may and may not do before it's connected to anything. Our AI agent security best practices guide covers the wider security picture around this checklist.

When to bring in help

If you're running agents across several teams, with shared keys you can't easily untangle, or you need to show an auditor that every agent action is traceable, the work grows past a checklist. Our enterprise AI agents team designs the identity, approval and logging layer for agents at that scale, and our AI agent development team builds new agents with scoped credentials from the first commit instead of retrofitting them later.

If you only have one or two agents with read-only access, you probably don't need us. Work through the checklist above.

FAQ

What is credential scoping for AI agents?

Credential scoping means giving each AI agent its own identity and a credential that only allows the specific actions its task needs. The agent never logs in as a human and never holds a key broader than its job. The credential, not the prompt, decides what the agent can do.

Why shouldn't an AI agent use a human's login?

Because you lose traceability, revocation and least privilege at once. You can't tell the person's actions from the agent's, you can't cut off the agent without resetting the person's password, and the agent inherits everything that person can do. A JPMorgan Chase spokeswoman told CNBC on October 13, 2026 that the bank does not permit third parties to access accounts by obtaining customers' banking credentials and logging in on their behalf.

How short should an AI agent's tokens be?

As short as the task allows, usually minutes to an hour. GitHub App installation tokens expire after 1 hour, and AWS role sessions default to 1 hour with a 15-minute minimum. Mint a fresh token per run from a broker so the agent never holds a long-lived secret.

What are AI agent credential management best practices?

Use one identity per agent, scope each credential to the narrowest actions, issue short-lived tokens, require human approval for irreversible actions, log every action to a store the agent can't edit, and test revocation. These map to OWASP's mitigations for excessive agency (LLM06:2025).

Is a system prompt enough to restrict what an agent does?

No. A prompt is an instruction the model can misread or be tricked out of by injected content. OWASP advises enforcing authorization in downstream systems rather than relying on the LLM to decide whether an action is allowed. Put the limit in the credential and the tool layer.

How do I scope credentials for MCP servers?

For HTTP-based MCP servers, use the OAuth 2.1 flow from the MCP authorization spec and bind each token to one server with the resource parameter. The server must reject tokens issued for anyone else and must not pass the client's token through to upstream APIs. Use a separate, scoped token for each upstream system the server calls.

Do small businesses need this?

Yes, in a lighter form. One identity per agent, a written list of allowed actions, a confirm step on money and deletes, and a real log cover most of the risk at any size. What changes with scale is the number of agents and the audit burden, not the principles.

---

Sources: OWASP LLM06:2025 Excessive Agency, GitHub: installation access tokens, AWS STS AssumeRole, Stripe restricted API keys, MCP authorization spec 2025-06-18, Claude Code permissions, CNBC, October 13, 2026