AI agent authentication, step by step

NextGen Identity Security desk · 2026-08-04

Editorial assessment · Desk research from public vendor material · Reviewed 2026-09-29

3 min read

Why agents need their own authentication

The quickest way to connect an agent to a system is to give it an API key or a person's session. Both are hard to control afterwards: the key usually outlives the task, and the session carries everything the person can do. OWASP's Non-Human Identities Top 10 lists long-lived secrets, over-privileged identities and human use of non-human identities among its ten risks. Agent authentication is the practice of avoiding all three.

Step 1: give the agent an identity of its own

An agent identity separates the agent from both the person who started it and the platform it runs on. Microsoft Entra Agent ID creates agent identities from blueprints and assigns each an owner and a sponsor. NewCore distinguishes agents acting on behalf of a person, delegated agents and autonomous agents. Okta treats the agent as a principal with delegation from the user.

Step 2: tie it to a person

Every agent should have a person or team who answers for it, and every action should record both. NewCore ties each action to the agent, the accountable human or team and the policy. Aembit's Blended Identity combines the agent's identity with the identity of the human operating it. Silverfort binds each agent it discovers to a human identity.

Step 3: use a token scoped to one resource

The MCP authorization specification describes the flow for tool calls over HTTP. The MCP server acts as an OAuth 2.1 resource server and publishes metadata pointing to its authorization server. The client obtains a token using PKCE and must include a resource parameter naming the specific MCP server. The server must check that the token was issued for it and must reject any other. Authorization servers should issue short-lived access tokens, and public clients must rotate refresh tokens.

The same idea applies outside MCP. Okta's Cross App Access lets one application act in another on a user's behalf. NewCore's Enterprise Managed Authorization issues scoped, time-bound tokens through an OAuth-based flow.

Step 4: keep the credential away from the agent

Even a short-lived token can be misused while it is valid. Several products avoid handing the downstream credential to the agent at all. NewCore's MCP gateway executes calls with credentials the agent never sees. Aembit mints and exchanges credentials at request time. Docker's MCP Enterprise Gateway reads credentials from the approved secret store when a tool runs, rather than placing them in client configuration.

Step 5: check each call, not just the sign-in

An authenticated agent can still attempt something it should not. Per-call authorization checks each operation against policy as it happens. NewCore evaluates calls at the operation level and can route them for human approval. Silverfort's gateway approves or blocks each tool call before it runs. Docker's gateway applies allow and deny rules by server, tool, transport and call.

What to avoid

• Passing a user's token through to another API. The MCP specification forbids token passthrough.
• Requesting every scope up front. The specification recommends starting minimal and asking for more when a privileged operation is attempted.
• Using sessions as authentication. MCP servers must verify every request.
• Static API keys in agent configuration files.