# MCP Authentication: Gate Agent Access to Tools Safely

Who is the agent acting as when it calls this tool?

The tempting answer is to authenticate the MCP client once and treat every later tool call as already solved. That answer is not useless, but it is too vague to operate. MCP authentication verifies the identity behind an MCP client or user before a server grants access to restricted tools and resources. For agents, authentication must connect to authorization, scopes, approval, and audit logs because the caller may act through automated tool decisions.

```query
mcp authentication
```

![Generated hand-drawn illustration of an agent policy gate routing read, write, and external actions.](/assets/agent-harness-architecture-15-jobs/03-policy-gate.png)

## Direct answer

MCP authentication verifies the identity behind an MCP client or user before a server grants access to restricted tools and resources. For agents, authentication must connect to authorization, scopes, approval, and audit logs because the caller may act through automated tool decisions.

## When this matters

- An MCP server exposes private resources, write tools, customer data, or paid operations.
- A client can invoke tools on behalf of a user or workspace.
- You need a clear distinction between identity, consent, scope, and runtime approval.

## Failure modes to catch

- The server authenticates the client but cannot identify the end user or workspace.
- A broad token allows every tool instead of the minimum task scope.
- Auth succeeds once and is never tied to individual tool calls in the trace.
- Authorization is treated as a docs page instead of a runtime control.

## MCP auth review checklist

| Gate | Signal | Action |
|---|---|---|
| Identity | client, user, workspace, server | Record all four in the trace |
| Authorization server | metadata and OAuth flow | Use spec-compliant discovery |
| Scopes | tool and resource permissions | Grant only the task minimum |
| Runtime approval | risky action requested | Pause with evidence packet |
| Audit | token, tool, scope, decision | Log every restricted call |

```schema
mcp_auth_review:
  protected_resource_metadata: present
  authorization_servers: configured
  client_identity: recorded
  user_identity: recorded
  workspace_identity: recorded
  scopes:
    - tool.read
    - tool.write.requires_approval
  trace_required_for_restricted_tools: true
  token_storage: outside_model_context
  revoke_path: documented
```

## Running example

A research agent can read public docs through MCP without approval. The same agent needs user identity, workspace scope, and approval before it can open a private CRM record or send a customer message.

## Put it to work

Use the mcp auth review checklist above as the first version of your production gate. Replace the placeholders with your own agent names, tools, risk classes, thresholds, and approval rules. Then wire it into traces, monitoring, security review, evaluation, and human approval so it changes runtime behavior instead of sitting in a doc.

## Related control gates

- [AI Agent Control Gates: Stop Bad Agents Before They Act](/agent-control-gates/)
- [MCP Security: Review Checklist for Agent Tool Servers](/agent-control-gates/mcp-security/)
- [AI Agent Security: Threat Models for Tool-Using Agents](/agent-control-gates/ai-agent-security/)
- [Human Approval for AI Agents: When Agents Should Stop](/agent-control-gates/human-approval-ai-agent/)
- [Agent Tracing: A Practical Schema for Tool-Using AI](/agent-control-gates/agent-tracing/)

## Frequently Asked Questions

### What is MCP authentication?

MCP authentication verifies the identity of the client or user accessing an MCP server. In production agents, it should connect to scopes, authorization, approval, and audit logs for each restricted tool call.

### How is authentication different from authorization?

Authentication answers who is calling. Authorization answers what that caller may access or do. Agents need both because a valid caller can still request an unsafe tool action.

### Should tokens be visible to the model?

No. Tokens and secrets should be brokered outside model context. The trace can record that a scoped credential was used without exposing the secret itself.

## The Takeaway

MCP auth is not a login checkbox. It is the front door to an agent's tool boundary.

## Sources

- [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
- [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [OpenAI Agents guide](https://developers.openai.com/api/docs/guides/agents)