What’s changed and what hasn’t in Auth and Identity for agentic apps
As AI agents become more capable and connected, building secure and scalable agentic products requires a strong foundation in authentication and identity. This guide breaks down what’s changed, what hasn’t, and what every builder needs to know to navigate the new landscape.
GuamianProduct & Design
Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
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.
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.
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.
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:
SSO for enterprise clients
Workspace or tenant-level separation
Agent delegation policies at the organization level (e.g., controlling what agents can do across teams)
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:
Log in with their existing SSO
Control what the agents can access (e.g., internal tools, document systems)
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.
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.
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.
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.
