How We Secured Our AI Agent's API Calls Using AuthSec and LangChain

The Rise of AI Agents in Real Applications

AI agents are no longer a research curiosity. Teams everywhere are building agents that can answer customer questions, look up order history, check billing status, and interact with backend systems — all autonomously, triggered by a simple user message.

LangChain has become the go-to framework for building these agents. It lets you define tools — functions the AI can choose to call — and wire them to a language model that decides when and how to use them. The developer experience is genuinely good.

But once you move past demos and start connecting agents to real APIs, a question hits you fast: when the agent calls our billing API or our user service — whose identity is it acting under? How do we know it's authorized? How do we prevent it from accessing data it shouldn't?

The Problem: Agents Calling APIs Without Identity

Traditional API security is built around the idea that a human logs in, gets a token, and makes requests. The token carries their identity. Access control is straightforward.

AI agents break this model. The agent isn't a human. It doesn't log in. It makes dozens of API calls in the background, often chaining them together. If you give it a static API key or a long-lived service token, you've essentially handed it a master key — it can access anything, anytime, on behalf of anyone.

Three things kept us up at night:

• No delegation context — the downstream API had no way of knowing why the agent was calling it or on whose behalf. It just saw a request with a token.
• Overprivileged tokens — service-to-service tokens are usually broad. The agent could theoretically access billing data for every customer, not just the one it was supposed to help.
• No audit trail — when something went wrong, there was no clean way to trace which agent action led to which API call. Security and compliance teams were not happy.

The Solution: Delegation Tokens via AuthSec

AuthSec is an identity and authorization platform built with AI agents in mind. Its LangChain SDK introduces a simple concept: delegation tokens.

Instead of a long-lived service credential, the agent requests a fresh, short-lived JWT right before each downstream API call. This token expires quickly (no long-term exposure if intercepted), carries context about the agent and the action being taken, is verified by the downstream service against AuthSec's public keys, and creates a clear audit record on the AuthSec side.

The agent doesn't hold credentials permanently. It earns the right to make each call at the moment it makes it.

How It Works in Practice

Here's the flow in plain terms:

A user sends a message to the agent: "Show me my billing details." The LangChain agent decides to call the get_customer_billing tool. Before hitting the billing API, the tool asks AuthSec for a token scoped to that call. AuthSec returns a short-lived JWT — valid for seconds to minutes, not hours. The tool calls the billing API with that token in the request header. The billing API validates the token with AuthSec and responds. The agent returns the result to the user.

The billing API never saw a static credential. The token was purpose-built for that call and is already expired by the time anyone could misuse it.

What We Built

We created a LangChain agent with three tools that each talk to different parts of our backend. Every tool follows the same pattern: ask AuthSec for a delegation token, use it for exactly one downstream call, done.

The AuthSec SDK handles token caching internally — if a token is still valid, it reuses it rather than fetching a new one every time. This keeps things efficient without sacrificing the security model.

Setting it up took less than an hour. The SDK has two required configuration values — your AuthSec server URL and a client ID — and one method call (get_delegation_token()) that you drop into any tool that needs to make an authenticated request.

• Billing tool — fetches a customer's current plan and charges
• User profile tool — retrieves account information
• Orders tool — lists recent purchases

What Changed for Us

Before AuthSec, our agent was using a shared service token that lived in an environment variable. It worked, but it was uncomfortable. Every engineer who looked at it knew it was a shortcut.

After integrating AuthSec, the agent code itself barely changed — but the security properties improved significantly.

• Downstream APIs can verify who is calling and why at the token level
• Tokens expire fast, so a leaked one is mostly useless
• We have a proper audit log of every delegation the agent requested
• Compliance had much less to complain about

The Bigger Picture

AI agents are going to call APIs. That's what makes them useful. The question isn't whether they should — it's whether you've thought carefully about how that access is controlled.

Static API keys and service tokens were designed for human-operated systems. They're the wrong tool for autonomous agents that make decisions on their own. Delegation tokens give agents an identity that is bounded, traceable, and short-lived.

LangChain makes it easy to build capable agents. AuthSec makes it safe to deploy them. If you're building agents that touch real data, it's worth taking the delegation model seriously before you go to production — not after.