Authentication for AI Agents: Who Is Making This Call?

When a human user clicks "Search flights-layer-ai-agent-search-flights)" on a website, authentication is straightforward. The user logged in. Their session token accompanies the request. The server knows who's asking.

When an AI agent calls the flight search API on behalf of a user, the picture gets murkier. The user sent a chat message. The agent decided to search for flights. The agent called the API. But the API call didn't come from the user's browser. It came from the agent's server-side process.

So who is making this call? The user (who initiated the conversation)? The agent (who decided to search)? The system (which executed the API call)?

The answer is all three, and our authentication system needs to handle that layered identity correctly. Here's how.

The delegated identity problem

In a traditional web application, identity is simple. User authenticates, gets a token, sends the token with every request. The server validates the token and knows who the user is.

In an AI agent system, there's an intermediary. The user authenticates to the application. The AI agent acts on behalf of the user. The agent makes API calls to backend services. These API calls need to carry the user's identity (so the backend knows whose data to access) but also the system's identity (so the backend knows the request is from a trusted service, not a rogue client).

We solve this with a dual-token approach.

User identity token. When the user authenticates, they receive a signed session tokens (JSON Web Token) from our authentication provider. This token identifies the user and carries their permissions. The token is passed to the agent session, and the agent includes it with every API call it makes on behalf of the user.

Service identity. The agent's backend service authenticates itself using request-signature (Hash-based Message Authentication Code) signatures for service-to-service communication. Every internal API call from the agent service to other backend services includes both the user's signed session tokens (identifying the user) and the request-signature signature (identifying the calling service).

The receiving service verifies both: is this user who they claim to be (signed session tokens validation), and is this request coming from a trusted internal service (request-signature verification)? Both must pass for the request to proceed.

Token management for long conversations

Here's a practical problem that doesn't exist in traditional web apps: AI conversations last a long time.

A typical web session might be fifteen minutes. A travel planning conversation might span hours across multiple sessions, with the user leaving and coming back. During that time, the user's signed session tokens might expire.

If the token expires mid-conversation, the agent can't make API calls on the user's behalf. The conversation stops working until the user re-authenticates. That's a terrible experience.

We handle this with a token refresh mechanism specific to agent sessions. The agent session holds a reference to the user's authentication context. When the user reconnects (opens the app, comes back to the chat), their session is refreshed with a new token. Active conversations detect the refresh and resume with the new credentials.

For API calls made during the conversation (not triggered by an explicit user action but by the agent's ongoing processing, like checking a booking status), we use a service-level token that has longer expiry and limited scope. This token can only access data for the specific user and only perform read operations. Write operations (bookings, payments) require a fresh user token.

Rate limiting is configured per route and per user. Even with valid tokens, each user has request limits that prevent abuse. The agent can't flood an API on behalf of a user, even with valid credentials.

Service-to-service authentication

Our backend is composed of multiple services. The agent service talks to the search service, the booking service, the payment service, and the notification service. Each service-to-service call needs authentication.

We use request signatures for this. Each service has a shared secret with every service it communicates with. When Service A calls Service B, it computes an request-signature signature over the request payload using the shared secret. Service B verifies the signature, confirming that the request came from an authorized service.

This is simpler than mutual TLS and more lightweight than OAuth for internal communication. The trade-off is that shared secrets need to be managed and rotated, which we do through our secrets management system.

The request-signature approach also provides request integrity. If the request payload is modified in transit (unlikely within our infrastructure but possible), the signature verification fails. This catches both tampering and corruption.

Audit logging for AI-triggered operations

Every action the AI agent takes on behalf of a user gets logged with full context.

The audit log for each operation includes:

• The user who initiated the conversation
• The conversation turn that triggered the action
• The agent's reasoning (which tool did it decide to call and why)
• The API call that was made (endpoint, parameters)
• The authentication tokens used (token IDs, not token values)
• The response received
• The timestamp and duration

Every AI-initiated action is logged with a full audit trail. This isn't just for debugging (though it's invaluable for that). It's a security requirement. If there's ever a question about whether an action was authorized by the user, we can trace it from the conversation message through the agent's reasoning to the API call.

The audit log is append-only and tamper-resistant. Once an entry is written, it can't be modified or deleted through normal operations. This protects the integrity of the audit trail even if other parts of the system are compromised.

Scoped permissions for the agent

The AI agent doesn't have unlimited access. Its permissions are scoped to the current user and the current operation type.

The agent can search for flights and hotels. It can read the current user's preferences and trip history. It can initiate bookings (with user confirmation). It can process payments (with user confirmation).

It cannot access other users' data. It cannot bypass payment confirmation. It cannot modify system configuration. It cannot read data that isn't relevant to the current conversation (like internal analytics or admin dashboards).

These permission boundaries are enforced in the backend services, not in the agent's instructions. Even if the agent's reasoning were compromised (through a prompt injection attack, for example), it physically cannot access out-of-scope data because the backend services won't allow it.

What competitors miss

Most AI features built into traditional travel platforms skip proper auth delegation entirely. The AI chatbot runs with service-level credentials that can access any user's data. The chatbot's prompts include instructions not to access other users' information, but those instructions are enforced by the model, not by the system.

This is a meaningful security gap. Prompt injection or model manipulation could potentially access data that the system doesn't architecturally prevent. If the only thing stopping the AI from reading another user's booking is an instruction in the model instructions, a sufficiently creative attack can bypass it.

Our approach is defense in depth. The agent's instructions say "only access the current user's data." The agent's credentials limit it to the current user's data. The backend services verify the user identity on every request. The audit log records every access. An attacker would need to bypass all four layers, not just the prompt.

For a system that handles passport numbers, payment information, and travel itineraries, this level of authentication engineering isn't overkill. It's the minimum.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.