The Model Context Protocol lets AI agents reach enterprise tools, and MCP authentication controls which agents can connect. The protocol has specified OAuth 2.1 for that job, but MCP server deployments have moved much faster than adoption of that specification. The result is a widening gap between what the standard requires and what production environments actually enforce.
That gap matters because agents operate at machine speed with real credentials. Unauthenticated servers expose tools directly to the internet, and stolen or over-scoped OAuth tokens from trusted AI integrations can reach customer data across hundreds of organizations at once. Identity alone doesn’t stop these outcomes: once a token is issued, the questions shift to which tools the agent may call, what instructions ride inside the content it reads, and who answers for the result.
This article covers how to close that gap. It walks through the OAuth 2.1 controls the specification requires, the delegation and scoping patterns that make agent grants attributable and narrow, and the runtime governance needed after token issuance. It also outlines the audit evidence security and compliance teams can bring to a board or regulator.
Key takeaways
- For HTTP-based MCP servers that implement authorization, MCP uses an OAuth 2.1-based flow with standards-based discovery, token validation, and protections against forwarding client tokens to upstream services.
- Production security depends on closing deployment and identity gaps with authenticated servers, narrow grants, short-lived credentials, owned inventories, and attribution to both agents and people.
- Delegated authorization gives agents task-specific access while preserving the human chain of responsibility through actor claims and per-action controls.
- Runtime governance must extend beyond identity checks by approving tools, blocking unauthorized calls, and inspecting content for prompt injection and other unsafe instructions.
What is MCP authentication?
MCP authentication establishes the identity involved in a connection between an MCP client and server. In agentic systems, the MCP client may operate as part of an AI application or agent that uses tools exposed by the server. Authorization determines which protected resources or capabilities that connection may access. Authorization is the second half: the server decides which tools and data that authenticated client may use.
The protocol has treated both as OAuth 2.1 problems since the March 2025 release. The July 2026 release notes align the flow more closely with enterprise OAuth 2.0 and OpenID Connect practice. The specification makes MCP servers OAuth 2.1 resource servers. It also defines a standards-based discovery and consent sequence that a client follows before calling a tool. The current tutorial covers each stage in a six-step authorization flow.
Servers are required to perform audience claim validation. They reject tokens issued for another service. Servers also MUST NOT pass through the token they received from a client to upstream APIs. The specification names this an anti-pattern because it creates a confused deputy.
Where MCP authentication needs production controls
Two implementation gaps can leave production MCP deployments exposed even when the specification’s authorization controls are implemented. The first is servers that skip authentication entirely, along with tokens that get forwarded past their intended audience; the second is agents that operate without clear ownership or attribution.
Documented scans have found unauthenticated MCP servers at scale, and both gaps remain enterprise responsibilities beyond the controls a model provider or identity vendor typically secures.
Unauthenticated servers and forwarded tokens
Widely used MCP tooling has shipped without authentication between client and proxy components, leaving critical connections exposed by default despite heavy adoption. Popular infrastructure projects have also exposed unauthenticated MCP endpoints that granted full administrative control over managed systems, and such flaws have been actively exploited in the wild.
From August 8 to 18, 2025, attackers used stolen OAuth refresh tokens from the Salesloft Drift integration to query Salesforce instances at more than 700 organizations. A trusted AI integration’s tokens granted broad access across customer environments. The queries ran at machine speed, which makes narrow scopes and attributable tokens especially important.
Assigning ownership to agents with inherited privilege
Many enterprises lack a complete inventory of the agents running in their environment or the tools and credentials those agents can access. As agent adoption expands, that visibility gap becomes a governance and security problem.
The average large enterprise is on track to run tens of thousands of agents in the coming years, a dramatic jump from the handful most organizations manage today. Agents arrive with credentials and scopes, yet most organizations lack documented policies for creating or removing AI identities. At that scale, teams need delegated, narrowly scoped tokens that identify both the agent and the human behind it.
Knowing Which AI Tools Are in Use Is Just the Start
WitnessAI goes beyond app discovery. Observe classifies the intent behind every AI interaction across employees and agents, so you can build smarter policies based on real risk, not guesswork.
Explore ObserveWhat OAuth for AI agents changes
Applying OAuth to agentic systems often requires extending familiar human authorization patterns with explicit delegation, narrower scopes, shorter-lived credentials, and contextual authorization around agent actions. Three shifts define what changes in practice:
- Delegation can name both the agent and the human: where token-exchange and actor-claim patterns are implemented, downstream systems can preserve the identity of the acting agent and the human on whose behalf it operates.
- Scopes should narrow and credentials should be short-lived: For agentic access, security teams can reduce exposure through narrowly scoped, short-lived credentials, refresh-token protections, and task- or time-bounded permissions appropriate to the action.
- Runtime governance controls what the agent does next: Server authentication is the mature half; authorization is shifting to contextual governance at each call, since identity checks alone don’t stop prompt injection or confused-deputy behavior.
Together, these patterns can move agent authorization beyond a one-time grant toward more continuous, context-aware decisions, with attribution to the agent—and, where delegation is preserved, the human responsible for initiating the activity.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlClosing the gap between MCP authentication and runtime control
When an agent acts, your enterprise controls need to enforce policy, inspect the content of the action, and cover the agents that skipped review in the first place.
WitnessAI is a unified AI security and governance platform and the confidence layer for enterprise AI, helping Global 2000 organizations monitor AI activity and enforce policy across their human and digital workforce.For supported MCP traffic traversing WitnessAI, network-level controls can apply consistent organization-wide tool policy across supported agent surfaces.
Three capabilities close the gap between authentication and runtime control: discovering the servers and agents that bypass review, enforcing approved-tool lists before calls execute, and inspecting the content flowing in both directions.
1. Discovery of the servers and agents that skipped review
Shadow AI now includes MCP servers, and they behave differently from shadow SaaS. A CSA research note describes MCP credential persistence as a qualitatively different risk from passive applications. Agents can initiate external connections through MCP and retain the credentials involved.
Our Observe module identifies agentic sessions by the tool advertisements in traffic payloads. We discover agentic activity across Claude Desktop and VS Code with AI extensions. We also discover local agents on developer machines. Those local agents include ones built on LangChain, LlamaIndex, CrewAI and custom code. The module supports discovery and monitoring of thousands of AI applications across those surfaces.
WitnessAI provides MCP server and tool visibility and allows security teams to maintain an organization-wide list of permitted MCP servers and tools. Agentic activity can be incorporated into the same policy and audit framework used across the broader AI environment.
2. Approved-tool lists enforced before the call executes
Authentication says an agent may connect; the approved-tool list says which tools it may call. With Agentic Control, security teams maintain an organization-wide approved-tool list of MCP servers and tools. For supported agent traffic traversing WitnessAI, the organization-wide approved-tool list can be enforced at the network across supported IDE, chat, and agent surfaces, including organization-level restrictions.
When that enforcement path is in place, calls to disallowed MCP servers or tools can be stopped before execution and recorded in the audit trail. Agentic Control maintains a full audit trail of agent and tool-call activity, with agent actions connected to a human identity.
3. Content inspection in both directions
The token in the header doesn’t reveal the instructions in the payload. Indirect prompt injection arrives inside the documents, tickets and tool results an authenticated agent reads. AI runtime guardrails complement the identity provider’s controls by inspecting that content.
For custom enterprise agents integrated with WitnessAI’s runtime APIs, Protect evaluates inputs before the agent processes them and evaluates responses before they reach users or trigger downstream actions. Malicious prompt detection has been validated in production deployments. WitnessAI provides consistent protection across more than 100 LLMs.
Intent-based machine learning engines use conversational context to classify content. This classification drives our Control module’s enforcement decision: allow, warn, block or route to an approved internal model.
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore ProtectWhat enterprises can prove to regulators and boards
For agent governance, audit trails are more useful when they preserve both the acting agent and, where applicable, the human responsible for initiating or authorizing the activity, along with the resources and tools involved. They must also record what the agent touched. A shared service account struggles to provide that evidence because its audit trail names the credential rather than the person or purpose behind the call.
Our platform produces that attribution as a by-product of enforcement. Policy decisions and blocked tool calls appear in unified audit trails across human and agent activity routed through the platform. For supported agent activity where human identity is available to the platform, WitnessAI correlates agent actions and blocked tool calls to the triggering employee, providing a unified audit trail for investigation and accountability. We are SOC 2 Type II certified.
The Legal and Compliance members of an AI Steering Committee ask a sharper version. Data pulled from hundreds of customer environments, as in the Salesloft Drift case, becomes a legal and brand problem as well as a security one.
WitnessAI has been validated in production at a top 5 global telecom provider. InComm Payments reports that the company wanted to maintain security and compliance while encouraging its teams to use modern approaches with GenAI applications.
The company chose WitnessAI to support that goal across its diverse portfolio. Its compliance, data-loss prevention, and privacy teams now have total visibility and confidence in AI security, which reduces risk while maximizing productivity. WitnessAI secures AI for more than 450,000 employees globally and monitors millions of interactions daily. That visibility gives compliance and risk teams evidence they can use in reviews.
Governing the agent workforce at enterprise scale
MCP authentication done well reduces exposure to known CVEs, but governing the agent workforce takes more than identity. You’ll need runtime controls, ownership of the inventory, and attribution back to the people responsible.
As agent-based attack surfaces grow, enterprises must account for risks that are specific to autonomous actions, including tool abuse, excessive agency, indirect prompt injection, and data exfiltration through tool calls. Implementing MCP authorization controls correctly can reduce exposure associated with unauthenticated remote endpoints and inappropriate token forwarding, but it does not address risks such as excessive tool permissions or injected instructions in retrieved content. AI risk management must also address tool scope and injected instructions inside content, and it must establish accountability for the result.
We give your AI Steering Committee one unified control framework for the human and digital workforce. Stronger evidence helps risk reviews proceed efficiently and helps agent projects move from pilot to production. A documented AI agent governance program gives the board clear evidence of how agent activity is managed. To see how Agentic Control and runtime guardrails apply to your MCP deployments, schedule a demo with our team.