What’s changed and what hasn’t in Auth and Identity for agentic apps

Recently I reviewed this article, and agent auth was mentioned:

We’re seeing hints of what this could look like. The latest MCP spec, for example, includes an authorization framework based on OAuth 2.1, signaling a possibility to move toward giving AI agents scoped, revocable tokens instead of raw secrets. We can imagine a scenario where an AI agent doesn’t get your actual AWS keys, but instead obtains a short-lived credential or a capability token that lets it perform a narrowly defined action.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

A lot of friends and people not in the security or CIAM field get the impression that this is something new but it’s definitely not. OAuth is a standard token-based authorization protocol that involves tokens with scoped permissions (access tokens). These are time-sensitive and scope-limited, which ensures security and proper access control to resources and services. In the global SaaS market (pre-AI), most professional identity solutions are already built on this.

When you connect your Google account to a third-party app like Notion or Zoom, it uses OAuth to request only the necessary permissions, such as access to your calendar or contacts, without ever exposing your Google password. You can revoke that access at any time from your Google account settings. This delegated access pattern is exactly what OAuth is designed for and it’s the same foundation being extended to agentic applications today.

What does not change in the agentic world#

Auth is not new, still based on OAuth 2.1#

There are two major protocols emerging: MCP and A2A.

• MCP focuses on the interaction between LLMs and your app’s tools and context.
• A2A focuses on enabling inter-agent task exchange.

But when it comes to authentication and authorization, both still rely on well-established industry standards like OAuth.

MCP authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients.

The A2A Client is responsible for obtaining the necessary credential materials (e.g., OAuth 2.0 tokens, API keys, JWTs) through processes external to the A2A protocol itself. This could involve OAuth flows (authorization code, client credentials), secure key distribution, etc.

As Google puts it:

Instead of inventing new, proprietary standards for security and operations, A2A aims to integrate seamlessly with existing enterprise infrastructure and widely adopted best practices.

Does an agent need a unique identity?#

A lot of hype and FOMO content pushes the idea that, as agents become more common, we need a system for managing agent identities.

The answer is: yes and no.

Yes, because we are introducing a new layer between humans and machines. There are real needs to:

• Manage and identify agents
• Assign unique IDs
• Track logs
• Audit actions (to know whether a task was performed by a human or an agent)

However, in most technical cases, there is no need to create a formal concept of “Agent Identity.”

Agent ≠ User, ≠ Service Account.

Behind every agent, there’s still a user and the user identity is usually enough.

Today, most agents:

• Act based on user authorization (e.g., OAuth tokens)
• Execute logic or make an API call
• Perform short-lived, one-off tasks (with no need for tracking)

In that sense, the agent is just a function-as-a-tool and doesn’t need a globally unique ID.

For example:

• A GPT agent calling your Calendar API only needs the access you granted.
• A LangChain agent doesn’t need an identity as long as it can call the right tools, it works.

Even before AI, we had the concept of machine-to-machine (M2M) auth.

M2M means automated data exchange between services, with no human in the loop.

In this context, authentication often uses a client app or service account.

If you really want your agent to have an identity (for audit, etc.), you can use the app ID and that’s enough.

You still need to define your product’s architecture#

This hasn’t changed. Whether or not your product involves agents, the architecture of your identity system depends on who your users are and how your system interacts with them.

If you’re building a consumer-facing agentic product: You’ll need lightweight sign-in methods (email, phone, social login), and a unified user pool to manage individuals who interact with your app and its agents. Agents act on behalf of these users using delegated tokens (e.g., via OAuth).

Example:

Imagine you’re building an AI scheduling assistant, or an AI-driven calendar bot.

Each user logs in with their personal Google account. Your system uses OAuth to get permission to access their calendar. The agent doesn’t have its own identity, it uses the user’s token to schedule meetings, check availability, or send reminders. The identity architecture is simple: one global user pool, token storage, and consent tracking per user.

If you’re building a B2B agentic platform:

You’ll need to support identity at the organization level, not just individual users. That includes:

1. SSO for enterprise clients
2. Workspace or tenant-level separation
3. Agent delegation policies at the organization level (e.g., controlling what agents can do across teams)
4. Admin-level visibility and logs for all agent activity on behalf of employees

Example:

Imagine you’re building a platform that provides AI agents to automate internal workflows — like a security analyst bot that monitors logs and sends alerts, or a sales assistant that drafts emails from CRM data.

Each company that uses your platform wants to:

1. Log in with their existing SSO
2. Control what the agents can access (e.g., internal tools, document systems)
3. See which agent performed what task, under which employee’s authorization

In this case, your identity architecture needs to support multi-tenant design, scoped agent permissions, and organization-specific policies. Agents still act on behalf of users, but the permissions and identity boundaries are enforced per business tenant.

In both cases, the identity model defines how agents operate, what they can access, and how your system ensures accountability.

Use this guide to help you plan your identity and product architecture.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

You still need security layers to keep your agent-powered apps safe#

Whether it’s an agent app or not, these foundational security layers are necessary for protecting your users and systems:

• Multi-factor authentication (MFA)

  Prevents unauthorized access even if credentials are compromised.

  Example: If an agent helps you perform a high-risk action, like making a transaction or changing identity settings, it should keep a human in the loop and use MFA to confirm the action before proceeding.

• CAPTCHA

  Blocks automated abuse like credential stuffing or bot-driven sign-ups.

  Example: Show CAPTCHA after 3 failed login attempts to prevent brute-force attacks.

• Role-based access control (RBAC)

  Ensures users and agents only access what they’re allowed to.

  Example: An AI assistant in a company workspace can read calendar events, but cannot access billing data unless explicitly assigned a higher role.

• Passwordless login

  Improves UX and reduces the risk of weak passwords.

  Example: Let users sign in using a magic link sent to their email or a biometric prompt like Face ID.

These features apply to both traditional and agent-based apps, especially as agents begin to operate across sensitive data and systems.

What has changed in the agentic world#

Auth is more important than ever#

As agents and multi-agent workflows emerge, we’re seeing new use cases where users, agents, APIs, and MCP servers all interact. The number and variety of these scenarios are growing fast, far more than in the past.

Whenever these connections happen, authorization becomes more visible than ever. Users must give clear consent, and permissions need to be carefully managed across systems. That’s why everyone is now talking about keeping a “human in the loop” making sure users have enough control and visibility over what agents can do, and what scopes they’re authorized for.

Your AI app may need to integrate with many external services#

The MCP ecosystem is expanding, and that means your app is no longer just a standalone service: it’s part of a larger, connected network.

To provide rich, useful context to LLMs, your agents may need to:

• Access multiple MCP servers

  Example: Imagine an AI project manager that pulls task updates from Jira, team availability from Google Calendar, and sales data from Salesforce and each of these could be powered by a different MCP server. To generate one weekly summary, the agent must securely interact with multiple data sources. That’s where authentication and authorization come in, to protect every connection and control how data is shared.

• Connect with external APIs and tools

  Example:A customer support agent might need to retrieve order history from Shopify, update tickets in Zendesk, and trigger workflows in Slack. Without integrations, the agent becomes siloed and ineffective.

As agents take on more responsibilities, integration becomes the key to utility. Your AI product isn’t just about what it can do on its own and it’s about what it can access, orchestrate, and reason over in a connected ecosystem. That’s why building for interoperability, securely and flexibly, is more important than ever.

You need to embrace open standards: OAuth/OIDC are more important than ever#

In the AI era, the need for secure, flexible integrations is growing. That makes OAuth 2.0 and OIDC are more important than ever.

Key use cases include:

• Remote MCP servers: Let third-party agents securely access your product using delegated tokens.
• Third-party integrations: Allow other tools or agents to connect to your app (e.g., a project management platform) without needing raw credentials.
• Agent development: Build AI agents that securely act on behalf of users across services.
• Smart devices: Use OAuth/OIDC for things like AI-powered note-takers to authenticate users and connect to the cloud — especially with minimal UI.

These protocols provide secure, token-based, user-consented access.

That’s critical in a world of agentic, connected systems. Check out this article to see why OAuth and OIDC are important

Designing for trust and scale in the age of agentic software#

As agentic products evolve, the core principles of identity and authorization remain the same but the context is shifting. Agents introduce new surfaces for delegation, consent, and access. That’s why sticking to open standards like OAuth, building a clear architecture, and enforcing solid security practices aren’t just best practices, they’re foundational. Designing with care now means your system will scale with confidence, flexibility, and trust in an AI-powered future.