Guide to Authentication for Agentic AI

Read the full blog from Aembit here: https://aembit.io/blog/a-catch-up-guide-to-authentication-for-agentic-ai/?source=nhimg

As agentic AI continues to evolve rapidly, developers are encountering new security challenges around authentication, authorization, and identity management. This guide, based on Aembit’s deep technical breakdown, walks through the architecture of agentic AI systems, how Model Context Protocol (MCP) fits in, and the complexities introduced by non-human identities (NHIs) in autonomous workflows.

High-Level Architecture of LLM Applications

At the core of most LLM-powered applications, like ChatGPT webapp, Claude desktop, or VS Code Copilot extension.

The standard components include:

• LLM (Large Language Model)
• Application interface (web or native app)
• LLM API (used to access the model as a service)

This simple structure has powered the majority of AI-driven tools over the past few years. It’s effective, easy to understand, and forms the foundation for more complex agentic AI systems being built today.

What Are AI Agents and How Do They Work?

The biggest evolution in LLM-based architecture isn’t the model itself — it’s the introduction of agents.

While traditional LLM apps like ChatGPT or Copilot are mostly passive (they take input, generate output), modern agentic AI systems are active and autonomous. These agents operate in loops, keep context of prior actions, and interact with external tools and services — all while continuously prompting the LLM to reach a goal.

Misconception: LLMs vs. Agents

Many assume LLMs perform actions themselves (like accessing APIs or files). In reality:

• LLMs are passive → text in, text out

• Agents handle the actions → interacting with APIs, databases, web services, etc.

In platforms like ChatGPT with browsing or plugin capabilities, the actual execution happens behind the scenes — often misunderstood as the LLM itself acting.

How Agents Execute Actions with LLMs

When an agent needs the LLM to trigger a service, it includes specific instructions in the prompt:

“If you want me to access Service X, respond in this format…”

When the LLM returns a properly structured reply, the agent interprets it as a command, executes the action, and loops the result back into the LLM for the next decision.

But this creates a challenge — every developer must re-implement integrations, handle authentication, configure SDKs, and teach the LLM how to structure commands. It’s repetitive, error-prone, and inconsistent.

Enter Model Context Protocol (MCP)

Model Context Protocol (MCP) standardizes how agents connect to external services.

• Instead of writing custom logic for each service (e.g., Salesforce), the agent connects to an MCP Server that already knows how to interact with that service.

• An MCP Client, embedded in the agent’s environment, handles:

  • Discovery

  • Authentication

  • Capability exposure

  • Communication with the LLM

The agent retrieves interface details (tools, parameters, etc.) from the MCP Server via the MCP Client, converts them into prompt-friendly format, and informs the LLM what it can now do.

Authentication Across Three Trust Boundaries

Each component in an agentic architecture must authenticate differently, depending on its role and connection. Here’s how it breaks down:

1- Application → LLM API

Authentication at this level is vendor-specific, and most providers support one or both of the following:

• OIDC / OAuth 2.0:
  Common for user-facing apps using social login flows (Google, Facebook, etc.)
  → Tokens are issued after OAuth-based authorization

• API Keys:
  Still widely used. Developers paste long-lived secrets into their apps or agents
  → Easy to implement, but introduces significant risk around secret management and exposure

2- MCP Server → Service

This trust boundary is technology-specific and highly varied:

• If the service is a database, it uses native DB auth

• If it’s an old Kerberized application, Kerberos is needed

• If it’s a legacy device like a Siemens S7 PLC from 1993, authentication becomes even harder

3- MCP Client → MCP Server

This is where things get especially interesting — and fragile.

• The MCP spec recommends using OAuth 2.1, which improves security by:

  • Deprecating insecure flows

  • Enforcing PKCE (Proof Key for Code Exchange)

  • Offering more predictable token handling

In practice:

• Most MCP clients and servers run locally, and communicate over stdio with no authentication at all, this makes integration easy but also risky — any local app can access the MCP server

• A smaller group use API keys or shared secrets, which also don’t comply with the MCP spec

• Only a tiny minority use OAuth 2.1 properly, as intended by the protocol

Authorization

1- Application → LLM API

Authorization at this layer is coarse-grained — either the application has access to the LLM or it doesn’t. There’s no fine-grained permission model (and likely won’t be soon).

2- MCP Server → Service

This interaction is technology-specific. Each target system (databases, legacy apps, cloud services) enforces its own authorization mechanisms.
There’s no single model — behavior varies widely.

3- MCP Client → MCP Server

Here we see fine-grained authorization — typically via OAuth access tokens issued by an authorization server. These tokens carry scopes defining what the client is allowed to do when calling the MCP server.

Authorization Complexities 

1- Delegation 

When a chain of calls occurs (e.g., app → MCP client → MCP server → service), ideally the MCP server should act on behalf of the original caller. This is a classic delegation problem — made more difficult when components use different technologies.

2- Dynamic Permissions

In traditional systems, permission needs are static — defined at design time, In agentic AI, access needs evolve at runtime as agents make decisions.

3- Blend of User and Agent Identity

Should agents act under the user’s identity or their own?

Scenario:
An agent queries an HR system to count employees. Missing fields lead it to take action — updating values based on outdated logic.
The result? A read-only request turned into a destructive update.

Key question:

• If the action was permitted under the user’s identity, who is accountable?

• If the agent used its own limited scope, the action might have been blocked.

The lack of a clear model for blended identity — combining user accountability with agent-specific guardrails — is one of the most urgent and unsolved problems in AI identity governance.

What’s Next?

At a glance, authorization in agentic AI might feel familiar to traditional full-stack apps — but the reality is different:

• Agents act independently, not just on user input

• Decisions are dynamic, not hardcoded

• Responsibilities are shared, but not clearly assigned

As agents become smarter and more integrated into enterprise systems, authentication and authorization will shape what’s possible — and what’s secure. Standards are still evolving, and best practices are just beginning to emerge.