Give the Agent an Identity Before You Give It Tools

Most agent tool reviews ask what the tool can do.

Ask who the agent is before you connect it.

Short answer

Before an AI agent gets MCP servers, API tokens, browser sessions, databases, shell tools, or write-capable workflow actions, write an agent identity record. It should name the actor, owner, represented principal, purpose, credential source, scopes, allowed tools, blocked tools, data boundary, action boundary, approval gates, log location, expiry, revocation path, and re-review trigger.

OAuth can prove a connection was authorized. MCP authorization can define how tokens are discovered and presented. A tool permission manifest can list what tools exist. None of those, by itself, proves the agent should act under that identity for that task.

The identity record answers the missing question: who is using this authority, for what purpose, and how do we prove it later?

The missing actor

An AI agent can look like a user, a service account, an app registration, a browser session, a local process, or a dedicated non-human identity.

Those are not equivalent.

A support triage agent using a read-only ticket token is one risk. A coding agent using a developer shell full of production environment variables is another. A browser agent using a logged-in daily profile is another. A multi-agent workflow where one agent passes a user's OAuth token to another agent is worse.

If the review only says "the agent can use the GitHub MCP server," it is too thin. The real question is which identity the MCP server uses downstream, what scopes that identity has, and whether the agent's task justifies them.

That is where a lot of agent risk hides.

What OWASP says about agent identity

The OWASP Top 10 for Agentic Applications 2026 puts this directly under ASI03: Identity and Privilege Abuse.

OWASP describes the risk as exploitation of dynamic trust and delegation in agents. The abuse can happen through delegation chains, role inheritance, control flows, agent context, cached credentials, and conversation history. OWASP also defines identity broadly here. It includes the agent's persona and any authentication material that represents it, including API keys, OAuth tokens, and delegated user sessions.

The line builders should care about is simple: without a distinct, governed identity of its own, an agent operates in an attribution gap that makes true least privilege impossible.

That attribution gap is the reason the identity record belongs before tool access.

If a workflow cannot say which principal the agent uses, what purpose the credential is bound to, when the token expires, which actions require re-authorization, and where the audit log lives, it should not get high-impact tools.

MCP authorization is not the whole review

The MCP authorization specification is useful plumbing. It says authorization is optional for MCP implementations. For HTTP transports, it maps MCP onto OAuth roles, protected resource metadata, authorization-server discovery, and scope guidance. The spec also says local STDIO transports should not follow that HTTP authorization flow and should retrieve credentials from the environment.

That split matters.

A remote MCP server might have OAuth metadata, scopes, and a consent flow. A local STDIO server might inherit credentials from the shell, config files, environment variables, or the developer machine. Both can be legitimate. Both can still give an agent too much authority.

So do not stop at "OAuth works" or "the MCP server connects."

Add the identity questions:

• What credential source does the agent use?
• Is the token bound to this task, this user, this resource, and this session?
• Which scopes are required for the current request?
• Which exposed tools are disabled because the task does not need them?
• Which actions need approval outside the model?
• Where do denials, approvals, tool arguments, and state changes appear in logs?

That is the difference between transport authorization and agent permission review.

Treat agent credentials like non-human identities

OWASP's Non-Human Identities Top 10 is not written only for AI agents, but the mapping is obvious once an agent holds secrets or acts through tokens.

The risks include secret leakage, overprivileged identities, long-lived secrets, environment isolation failure, identity reuse, improper offboarding, and human use of non-human identities. Those are ordinary automation problems. Agents make them easier to trigger through natural-language instructions, tool outputs, memory, and delegation.

A broad shared token is convenient. It is also how blast radius spreads.

If one agent can reuse the same credential across tasks, users, environments, or peer agents, a prompt injection or confused deputy path can turn into privileged action under a valid identity. The audit log may show a legitimate token. It may not show whether the user intended that action.

The safer default is narrower:

• dedicated agent identity where possible
• task-scoped credentials
• short lifetime
• minimum scopes
• no cross-environment reuse
• no memory retention of secrets
• visible owner
• fast revocation path
• logs that distinguish human action from agent action

This is basic non-human identity hygiene applied to agentic AI.

The agent identity record

Keep the record short enough that a team will maintain it. Make it specific enough that it can block a bad grant.

The record does not need to be fancy. A markdown file is enough for most teams.

The important part is that tool access becomes reviewable before the agent acts.

Where autonomy changes the answer

A read-only agent and a write-capable agent should not share one identity model.

The Cloud Security Alliance draft Agentic NIST AI RMF Profile makes this distinction. Agents that execute code, call external APIs, spawn sub-agents, modify databases, or chain multi-step plans create different governance needs than systems that only recommend or summarize.

That maps cleanly to identity review.

For a read-only summarizer, the identity record might allow a narrow read scope, no external send path, and ordinary logging.

For an agent that can deploy code, refund a customer, send an external email, update a CRM record, move money, or run shell commands, the identity record should require tighter controls:

• task-bound credential
• short expiry
• no inherited admin session
• per-action authorization
• pre-execution plan or diff
• human approval for high-impact action
• immutable tool-call logs
• revocation test before launch

The agent's autonomy tier should change its credential shape.

The prompt injection angle

Prompt injection is not only a model behavior problem. Once the agent has tools, it becomes an authorization problem.

OWASP LLM01 says prompt injection can lead to sensitive information disclosure, unauthorized function access, arbitrary commands in connected systems, and manipulated decisions. OWASP's agentic guidance extends that into goal hijacking, tool misuse, identity abuse, and delegated privilege.

That is why identity ambiguity matters.

If an injected webpage, email, ticket, document, tool result, or MCP descriptor can steer the agent while the agent holds a broad user token, the attacker does not need to break OAuth. They can steer the already-authorized actor.

The defense is not "tell the model not to do that."

Use the identity record to reduce blast radius:

• remove unused scopes
• separate identities by task
• block shared admin tokens
• isolate sessions and memory
• require approval for write, send, delete, deploy, purchase, and execute actions
• log the original user intent and the active agent identity

Prompt injection gets less interesting when the identity has nothing dangerous to borrow.

A quick test

Pick the most privileged agent in your stack.

Then answer these questions without opening another tab:

1. Which identity appears in downstream logs when it acts?
2. Which human or team owns that identity?
3. Which user, app, or service account does it represent?
4. Which tools are enabled only because they came bundled with a server?
5. Which scope would you remove first if you had to cut blast radius today?
6. Which high-impact actions require approval outside the model?
7. Where are denied actions logged?
8. When does the credential expire?
9. Who can revoke it during an incident?
10. What change forces a re-review?

If those answers are fuzzy, do not expand the agent's access yet.

Write the identity record first.

Evidence versus opinion

Evidence from the sources:

• OWASP Agentic Top 10 ASI03 identifies identity and privilege abuse as a core agentic risk involving delegation chains, role inheritance, cached credentials, OAuth tokens, delegated sessions, and attribution gaps.
• OWASP Agentic Top 10 ASI02 recommends least privilege for tools, action-level authentication, human confirmation for destructive actions, policy enforcement, short-lived credentials, and logs.
• The MCP authorization spec says authorization is optional, HTTP authorization uses OAuth-style roles and metadata, and STDIO transports retrieve credentials from the environment.
• OWASP Non-Human Identities Top 10 covers overprivilege, long-lived secrets, NHI reuse, secret leakage, environment isolation, offboarding, and auditability risks.
• CSA's draft Agentic NIST AI RMF Profile recommends autonomy tiering, tool-use risk modeling, delegation-chain monitoring, runtime metrics, and incident response for agent compromise.

My opinion:

The minimum safe unit is not "agent plus tool." It is agent identity plus task plus credential plus scope plus approval gate plus log. If the identity layer is unclear, the tool review is unfinished.

Free next step

Take one agent you already use and write its identity record before adding another tool. If it uses MCP, compare the record against the MCP authorization review and the MCP consent record. If it can ask another agent for help, run the confused deputy check too.

Sources:

• OWASP Top 10 for Agentic Applications 2026
• Model Context Protocol Authorization specification
• Cloud Security Alliance Agentic NIST AI RMF Profile v1
• OWASP Non-Human Identities Top 10
• OWASP LLM01: Prompt Injection