Securing AI agent access

AI agents are fundamentally workloads, whether they’re user-driven assistants like Claude Desktop or autonomous decision-makers. They authenticate to systems, request credentials, and access enterprise resources. The same identity and access management principles that secure your applications and services apply to AI agents.

Everything Aembit has built for workload IAM (attestation methods, SPIFFE compatibility, credential issuance, access policies) extends to agentic AI. The difference is the workload type, not the security model.

Most organizations struggle with this because they treat AI agents as a special case. They either block agents entirely or distribute long-lived API keys that give every user’s agent identical access with no visibility or control.

Both traditional applications and AI agents follow the same path: authenticate with Aembit, receive short-lived credentials, and access enterprise resources under policy control.

User-driven AI agents

AI assistants like Claude Desktop or Gemini CLI that act on behalf of an authenticated user. These agents have a — access ties to both the user’s identity (from your IdP) and the agent’s workload identity, so policies can scope permissions based on “who is using which agent to do what.”

The rest of this page focuses on user-driven agents, the most mature category and the one organizations are deploying today.

What Aembit solves

Organizations want to deploy AI agents, but security and compliance requirements block progress. Without centralized identity controls, teams wait on security reviews, agents lack access to internal systems, and long-lived API keys distributed as workarounds create unmonitored risk.

Aembit’s Model Context Protocol (MCP) integrations bring identity-based access control to AI agents through blended identity—combining the user’s identity with the agent’s workload identity in every access decision. Instead of distributing static credentials to each agent, Aembit authenticates the user behind the agent, identifies which agent they’re using, and issues short-lived tokens based on your access policies.

Static API keys can’t scope per-agent or revoke access without rotation. Virtual Private Network (VPN)-based access doesn’t distinguish agents from users. AI vendor built-in auth is provider-specific and not unified across systems. Aembit treats AI agents as workload identities with the same attestation, policy, and audit capabilities used for any other workload.

With Aembit, you get:

Blended identity access control that evaluates both the user (through your IdP) and the agent (through workload identity) in a single access decision—not just “who is this user?” but “who is this user, using which agent?”
Credential isolation, so AI agents never see the actual credentials for backend systems
Per-user credential scoping, where each user’s agent receives different downstream credentials based on their identity, even when all users share the same agent and policies
A centralized audit trail that logs every agent request with both user identity and agent identity
Instant revocation by disabling access for a specific user, agent type, or user-agent combination through policy changes, not credential rotation

Real example: securing Claude Desktop access

Your team wants to use Claude Desktop to query Jira issues and search Confluence documentation. Without Aembit, you’d need to:

Create API tokens for Jira and Confluence
Distribute those tokens to every user’s Claude Desktop configuration
Hope nobody commits their config file to a repository
Accept that you have no idea which user made which API call

With Aembit, this flow looks different:

When a user opens Claude Desktop and connects to your MCP server, the MCP Authorization Server intercepts the connection. Aembit redirects the user to your identity provider to authenticate. Once authenticated, Aembit evaluates your Access Policies to determine if this user, at this time, from this location, should have access.

If approved, Aembit issues a short-lived token that the MCP server validates. The user’s Claude Desktop session can now access Jira and Confluence through MCP. The actual API credentials never leave Aembit’s control.

How MCP OAuth 2.1 authorization works

The Model Context Protocol (MCP) specification defines how AI agents discover and connect to servers that provide context (data sources, tools, resources). MCP uses with dynamic client registration, which means:

AI agent clients don’t need static credentials to authenticate to the MCP Authorization Server (no pre-shared secrets)
The agent registers itself at runtime, receives a client ID, and uses to complete the OAuth flow
After user authentication, the MCP Authorization Server issues a token with a limited lifetime (default 1 hour), which the agent uses to access the MCP server

This differs from traditional OAuth 2.0 by eliminating client secrets, since AI agents running on user devices can’t protect stored secrets. It also requires PKCE for all clients, not just public clients.

MCP Authorization Server vs. MCP Identity Gateway

Aembit offers two components for securing MCP traffic:

MCP Authorization Server (available now) Issues short-lived tokens to AI agents after user authentication. The agent holds the token and presents it to the MCP server on each request. Implements blended identity through a single access policy that evaluates both user and agent.

MCP Identity Gateway (limited beta) Proxies all MCP traffic through Aembit, so the AI agent never holds any credential—not even the short-lived token. Every MCP request flows through the gateway, which validates the user’s identity and injects credentials on the fly. Extends blended identity across two policy hops, enabling per-user credential isolation for each downstream MCP server.

The gateway model provides the strongest security (zero credential exposure to the agent and per-user credential scoping) but introduces latency and a single point of failure. The authorization server model is simpler and sufficient for most use cases, as the short-lived tokens expire fast and scope to specific resources. Both models implement blended identity, combining user and workload identity in every access decision.

Why this architecture matters for AI agents

AI agents introduce security challenges that traditional secret management doesn’t address.

Unlike scripts or applications, AI agents make decisions about what to access and when. An agent might query your entire Jira backlog or search Confluence for sensitive keywords. Blended identity policies let you scope access based on both the user and the agent—so you can allow your security team to use Claude Desktop for vulnerability data while restricting engineering to Jira and Confluence only.

As AI assistants become standard developer tools, every employee needs access to backend systems. Distributing static credentials to hundreds of agent configurations creates significant risk. Blended identity eliminates this problem. Aembit issues credentials per user per session, scopes them to specific resources, and never shares them across users or agents.

When an AI agent takes an action on behalf of a user, compliance teams need to know who was responsible. Aembit’s logging ties every MCP request to both a verified user identity and the specific agent that made the request.

Aembit’s AI agent security isn’t a separate product. It leverages the same Trust Providers, Credential Providers, and Access Policies you use for securing service-to-service communication. The MCP Authorization Server is an integration layer on top of Aembit’s workload IAM foundation, and it extends to new agent types without rebuilding the security model.

Audit and compliance for AI agents

AI agents introduce a new audit challenge. When an agent takes an action, compliance teams need the same answers they require for human access: who was responsible, what did they access, and when did it happen?

Because Aembit’s blended identity model captures both user and agent identity, every access event includes full attribution. Aembit logs every AI agent request with both verified user identity and agent workload identity, treating agent access events the same way you’d audit a human logging into a VPN or accessing a database. Logged events include:

Authentication events, covering which user authenticated to which agent, at what time, from what location
Authorization decisions, including which access policies evaluated, what conditions matched, and what access Aembit granted or denied
Workload events, showing what resources the agent accessed, what operations it performed, and what credentials Aembit issued

Why audit for AI agents differs from traditional application logging

Traditional applications have predictable behavior: a web service queries the same database endpoints, a cron job runs the same script. AI agents make decisions in real time about what to access and how to use it. One user’s agent might query three Jira tickets; another might search your entire Confluence knowledge base.

This unpredictability means you can’t rely on static application logs to understand what happened. You need identity-based audit trails that tie every agent action to a responsible user, just like you would for human access to sensitive systems.

Aembit’s access logs provide this by capturing not just “an MCP request happened,” but “user@example.com’s Claude Desktop agent accessed Jira at 2:34 PM, received access under policy ‘Jira-Read’, and made 3 API calls.”

For organizations with audit requirements around privileged access or regulatory compliance (SOC 2, HIPAA, PCI), this agent-level logging satisfies the same controls as human access monitoring.

Supported AI platforms

Aembit’s MCP Authorization Server supports OAuth 2.1 with dynamic client registration, which means it works with MCP-compatible AI platforms including:

Claude Desktop, the Anthropic desktop application with MCP support
Gemini CLI, Google’s command-line AI assistant
Custom MCP clients (any application implementing the MCP specification)

Next steps

Start with the MCP Authorization Server

MCP Authorization Server overview covers how OAuth 2.1 authorization works for MCP clients
Set up the MCP Authorization Server walks through configuring Aembit as your MCP authorization provider

Understand blended identity

Blended identity explains how Aembit combines user and workload identity for AI agent access control

Configure identity and policies

Trust Providers for connecting your identity provider for user authentication
Access Policies for defining who can access which MCP servers and under what conditions

AI and LLM Access covers securing your applications’ access to AI APIs (OpenAI, Anthropic, etc.), which is distinct from securing AI agents’ access to your enterprise resources
Multicloud explains how Aembit provides unified workload identity across cloud providers, relevant if your AI agents access resources across AWS, Azure, and GCP