DEV Community: Auth0 for Developers

Introducing The Auth0 Plugin for ChatGPT

Jessica Temporal — Tue, 13 Oct 2026 15:25:34 +0000

The new Auth0 plugin for ChatGPT is here, and it’s a massive productivity win for developers.

In this video, you'll learn how to connect ChatGPT directly to your Auth0 tenant and automatically refactor a standard username/password login into a secure OTP (One-Time Password) flow. Because the plugin leverages your active Auth0 CLI session, you can prompt your way through complex auth changes without ever leaving your editor or digging through documentation.

What You'll Learn

How to install and configure the Auth0 ChatGPT plugin.
Prompting ChatGPT to refactor your codebase for an OTP login flow.
How the plugin uses the Auth0 CLI to manage active tenant sessions securely.

Resources

If you enjoy this content and want to learn more about identity, security, and access management, subscribe to our channel!

Have a topic you'd like to see covered? Let us know if the comments below 👀

Handling Auth in Next.js 16 with Server Actions and Middleware

Aniket Bhattacharyea — Mon, 12 Oct 2026 10:44:27 +0000

TL;DR: Authentication in Next.js has changed significantly — patterns like client-side session hooks and middleware-only authorization can become insecure in a server-first application. Auth0's Next.js SDK v4 aligns with the App Router by replacing legacy route handlers, simplifying session access across server contexts, and supporting route protection.

Authentication in Next.js has changed significantly over the last few major releases. With Next.js 16, the framework fully embraces a server-first architecture: Server Components render on the server by default, Server Actions execute mutations server-side, and the App Router pushes developers toward colocated backend logic rather than traditional API-centric patterns.

That shift changes how authentication should be implemented. Patterns that worked well in older Next.js applications, such as client-side session hooks, /api/auth/* route handlers, and middleware-only authorization checks, can become awkward or even insecure in a server-first application. Session assumptions that were safe in client-heavy architectures no longer hold with Server Actions. Many developers upgrading existing applications discover that older Auth0 integration patterns simply no longer map cleanly to the App Router model.

Instead of working around the framework, the latest Auth0 Next.js SDK is designed specifically for this architecture and integrates directly with the server-first model that Next.js 16 promotes. In this guide, you will learn how to build a production-grade authentication layer in a Next.js 16 App Router application using Auth0’s Next.js SDK v4. This article will cover:

The architectural shift from SDK v3 to v4
How proxy.ts replaces legacy auth route handlers
Session access patterns in Server Components, Server Actions, and API routes
Practical route protection strategies
Security considerations that matter in real-world deployments

What Changed in Auth0 Next.js SDK v4 (and Why It Matters)

Before App Router and Server Components became the default, authentication in Next.js typically revolved around API routes. In the Pages Router era, Auth0 integrations commonly looked like this:

// pages/api/auth/[auth0].ts

import { handleAuth } from '@auth0/nextjs-auth0';

export default handleAuth();

Protected API routes used wrappers like:

withApiAuthRequired()

Session access relied on request/response objects:

getSession(req, res)

This model worked well because applications were heavily request-oriented. Rendering often happened client-side or through getServerSideProps, and API routes formed the natural backend boundary. Next.js 16 changes the execution model entirely. Server Components run directly on the server without explicit request handlers. Server Actions execute independently from page renders, and route segments can stream progressively. The framework assumes that most logic lives server-side from the beginning.

The diagram below shows how Auth0 SDK v4 aligns directly with that architecture, tracing a request from initial HTTP call through to protected mutation.

Instead of manually defining /api/auth/[auth0], the SDK now auto-mounts authentication routes like /auth/login, /auth/logout, /auth/profile, etc. when you include a properly configured proxy.ts file (more on this file in the next section).

The SDK also simplifies configuration substantially. For example, you can create a shared Auth0 client with only one line of code:

// src/lib/auth0.ts

import { Auth0Client } from '@auth0/nextjs-auth0/server';

export const auth0 = new Auth0Client();

The SDK automatically reads environment variables like AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET, AUTH0_SECRET, APP_BASE_URL

This minimal, boilerplate-free setup is intentional. The SDK naturally integrates into the Next.js server-first runtime rather than requiring extensive bootstrapping code.

The biggest practical change is session access. Instead of:

getSession(req, res)

you now use:

await auth0.getSession()

with no request or response arguments.

That works because the SDK reads encrypted session cookies directly from the current server execution context.

The proxy.ts Pattern

The most important architectural concept in Auth0 SDK v4 is proxy.ts.

In Next.js 16, proxy.ts acts as a request interceptor that executes before the framework processes a route. It replaces the former middleware.ts convention, with the new name emphasizing that this code runs at the network boundary and can rewrite, redirect, or modify requests and responses before they reach your application routes. For Auth0, this interception point allows the SDK to handle authentication routes and session-related processing before the request continues into the application.

Here is the standard implementation:

// src/proxy.ts

import type { NextRequest } from 'next/server';
import { auth0 } from './lib/auth0';

export async function proxy(request: NextRequest) {
  return await auth0.middleware(request);
}

export const config = {
  matcher: [
    /*
     * Match all request paths except:
     * - _next/static
     * - _next/image
     * - favicon.ico
     * - sitemap.xml
     * - robots.txt
     */
    '/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
};

This file is the mechanism that enables the SDK to intercept and handle authentication routes automatically. Without it, requests to /auth/login or /auth/callback will typically return 404 errors.

Note: If your application uses a src/ directory, the proxy.ts file must live inside this src directory. Otherwise, it belongs at the project root. Misplacing the file often causes silent failures where auth routes return 404s even though the SDK appears configured correctly.

Understanding the matcher pattern

The matcher pattern is more important than it initially appears.

This line tells Next.js which requests should pass through the Auth0 proxy layer:

'/((?!_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)'

The exclusions affect both performance and security. For example, paths like _next/image serve optimized image requests, which should not be intercepted as this can introduce unnecessary auth processing overhead and break asset delivery. On the other hand, paths like favicon.ico and robots.txt are public assets that should not be protected behind authentication. You must also set up the matcher to exclude any other public routes in your app, but be careful not to accidentally exclude sensitive paths, as this may cause them to bypass auth interception entirely. This is why you should treat matcher configuration as part of your security model, not merely routing boilerplate.

Auto-mounted routes

Once proxy.ts is configured, the SDK automatically mounts several auth endpoints:

/auth/login
/auth/logout
/auth/callback
/auth/profile
/auth/access-token
and others

These routes are now part of the SDK contract, and you no longer need to manually implement them yourself.

Session Access in the Server with Components, Actions, and API Routes

One of the most important concepts in Next.js 16 authentication is understanding that each server execution context behaves differently. Server Components, Server Actions, and API routes all run on the server, but session access patterns are not identical across them.

Server Components

Server Components are the cleanest place to access session state. Because they execute directly on the server, they can read encrypted session cookies without any client-side round trip.

Here is an example:

// app/dashboard/page.tsx

import { redirect } from 'next/navigation';
import { auth0 } from '@/lib/auth0';

export default async function DashboardPage() {
  const session = await auth0.getSession();

  if (!session) {
    redirect('/auth/login');
  }

  return (
    <main>
      <h1>Welcome, {session.user.name}</h1>
    </main>
  );
}

getSession() reads directly from encrypted cookies. If no session is found, the user is redirected. No API request is required, and no token exchange happens during rendering. The redirect occurs server-side before protected content renders. This is both simpler and more secure than relying on client-side auth checks after hydration.

Server Actions

Server Actions are where many developers accidentally introduce security gaps. Even though Server Actions execute on the server, they are invoked independently from the client. That means they cannot assume the session state from a previous page render is still valid, and every Server Action must re-validate authentication explicitly.

For example:

// app/actions/update-profile.ts

'use server';

import { auth0 } from '@/lib/auth0';

export async function updateProfile(data: FormData) {
  const session = await auth0.getSession();

  if (!session) {
    throw new Error('Unauthorized');
  }

  const userId = session.user.sub;

  // Protected mutation logic
  await saveUserProfile(userId, data);
}

Some developers see this repeated session validation as redundant, but it is not. Server Actions are independent execution contexts. A user may have logged out, had their session invalidated, or switched accounts between the initial render and the action invocation. That is why you should treat every Server Action as a fresh authenticated request in order to avoid critical authorization bugs.

API routes

For API routes, the SDK still provides a convenient protection wrapper:

// app/api/admin/route.ts

import { auth0 } from '@/lib/auth0';

export const GET = auth0.withApiAuthRequired(async function GET() {
  return Response.json({
    success: true,
  });
});

This is often the most straightforward approach for protected APIs because unauthenticated requests automatically receive a 401 Unauthorized response.

Accessing User Data and Tokens

Once you have a session, you can access user information directly:

const session = await auth0.getSession();

const user = session?.user;

If you need to call a third-party API on behalf of the user, you can also retrieve the access token:

const token = await auth0.getAccessToken();

Route Protection Strategies

There is no single “correct” protection strategy in Next.js 16. The right approach depends on how much of your application is private and how centralized you want authorization logic to be.

Page-level protection

The most explicit strategy is protecting individual pages:

const session = await auth0.getSession();

if (!session) {
  redirect('/auth/login');
}

This approach gives maximum control and clarity since you can tweak the authorization logic for each page.

Protecting individual pages works especially well when:

Only some routes are protected
Authorization rules vary per page
You need custom redirect logic

The downside is repetition at scale. Having this guard for every page can get too verbose.

Layout-level protection

For larger applications, layout-level protection is usually more maintainable.

For example, this specifies that everything nested under /dashboard now requires authentication automatically:

// app/dashboard/layout.tsx

import { redirect } from 'next/navigation';
import { auth0 } from '@/lib/auth0';

export default async function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const session = await auth0.getSession();

  if (!session) {
    redirect('/auth/login');
  }

  return <>{children}</>;
}

This is often the best tradeoff for applications with clearly separated public and private route segments, such as a CMS with a public homepage and a dashboard for authenticated users.

proxy.ts-level protection

For applications where nearly every route requires authentication, protection can move even higher into the request pipeline. You can extend the proxy matcher to blanket-protect large portions of the app. This reduces duplication and centralizes enforcement. However, it is usually less flexible than page or layout-level checks for applications that mix public marketing pages with authenticated dashboards.

Using useUser()

So far, you have seen how we can authenticate the user on the server. But what about user profile access on the client-side? The SDK also provides a client-side hook:

useUser()

useUser() is useful for authentication and authorization in the UI, such as conditional UI rendering, user avatars, client-side personalization, navigation states, etc., but it should not be trusted for authorization decisions. Client-side state can be stale, manipulated, or temporarily inconsistent. For anything involving data access, mutations, permissions, or protected rendering, you should always validate using getSession() on the server.

Security Considerations

The following are some of the most common security tips that you should keep in mind when using Auth0 with Next.js Server Actions and Middleware.

AUTH0_SECRET rotation

The AUTH0_SECRET environment variable encrypts session cookies. If it changes, existing cookies can no longer be decrypted, resulting in errors like JWEDecryptionFailed.

In practice, users may need to clear cookies or re-authenticate after secret rotation. This becomes particularly important in CI/CD environments where secrets may accidentally differ across deployments.

Allowed callback, logout, and origin URLs

These Auth0 dashboard settings are security controls, not just configuration details.

Examples include:

Allowed Callback URLs
Allowed Logout URLs
Allowed Web Origins

These settings protect against malicious redirect flows and unauthorized origins. If they do not match your deployed application URLs exactly, authentication flows will fail intentionally.

Do not trust client-side session state

Authorization decisions should always happen server-side. This principle deserves repeating:

useUser() is for UI
getSession() is for authorization in the server

Relying on the client state for protected actions is one of the easiest ways to introduce privilege escalation bugs into Next.js applications.

Protect environment variables

Secrets like AUTH0_CLIENT_SECRET must never be exposed to the client bundle. Fortunately, Next.js only exposes variables prefixed with NEXT_PUBLIC_ to client-side code. None of the Auth0 secrets use that prefix, so they are safe from being exposed by Next.js.

However, they can still be accidentally made public. To prevent that, always store them in a .env file, and never check it into version control.

Rethinking Auth in the Server Actions Era

Authentication in Next.js 16 requires a different mindset than earlier generations of the framework. The App Router, Server Components, and Server Actions fundamentally change where code executes and how you trust boundaries should be enforced.

In this guide, you learned how Auth0’s Next.js SDK v4 aligns with that architecture by replacing legacy route handlers with the proxy.ts interception model, simplifying session access through server-native APIs, and supporting protection strategies that scale from individual pages to entire application segments. You also saw why session validation must happen independently across Server Components, Server Actions, and API routes, and why server-side authorization remains essential even in highly interactive React applications.

Auth0 is the identity platform behind all of this: developer-first, deeply flexible, and designed to scale from a weekend project to enterprise-grade infrastructure without forcing teams to trade control for convenience.

The Next.js SDK v4 is a strong example of that philosophy in practice. Instead of layering abstractions on top of the framework, it embraces the Next.js server-first architecture directly through patterns like proxy.ts, server-native session access, and streamlined configuration. The result is an authentication model that feels natural inside modern Next.js applications while still supporting the advanced authorization, multi-tenant identity, and extensibility requirements that growing applications eventually need.

Type-Safe Authentication in Rust with Auth0 and Axum

Aniket Bhattacharyea — Mon, 12 Oct 2026 10:36:40 +0000

CLI tools are deeply embedded in modern developer workflows. But while browser-based authentication is naturally integrated into web applications, and desktop and mobile applications work well with it, CLI applications present a unique challenge: there is no available browser or redirect URL to complete a standard OAuth login flow.

This is exactly the problem the OAuth 2.0 Device Authorization Flow was designed to solve. Rather than redirecting users within the application, the CLI requests a temporary device code, displays a short verification URL and user code, and waits while the user authenticates in their browser. Once complete, the CLI receives tokens it can use for authenticated operations. You have likely encountered this flow before without realizing it. Smart TVs, IoT devices, and headless servers all rely on it when launching or redirecting to a browser is inconvenient or impossible.

In this tutorial, you will build a complete end-to-end system in Rust and Axum using Auth0. First, you will create a Rust CLI that authenticates users using the Auth0’s Device Authorization Flow and retrieves both an ID token and an access token. Then, you will build an Axum API to validate that access token before allowing access to a protected route. Together, these two pieces demonstrate the full authentication and authorization lifecycle: one application obtains trust, and another verifies it.

Prerequisites

To follow along with this tutorial, you will need:

An Auth0 account. You can sign up for free.
The Rust toolchain installed on your system.

Configure Auth0

Start by creating a new Native Application in the Auth0 dashboard.

Open the Auth0 Dashboard, navigate to Applications > Applications, and click Create Application. Select Native and give the application a name like Rust CLI Demo, as you can see in the following screenshot.

Native applications are designed specifically for desktop applications and CLI tools that cannot securely store a client secret.

Once the application is created, open the Settings tab, scroll to Advanced Settings > Grant Types, and enable Device Code as illustrated in the screenshot below.

This step is critical because Auth0 disables the Device Authorization grant by default. If you skip it, the token polling request will fail with an unauthorized_client error that is difficult to diagnose if you do not already know the grant type is disabled.

Now, save your changes.

You will also need to copy the Domain and Client ID values from the Settings page. Store these somewhere safe, as you will need them later.

Next, you will create an API in Auth0. This represents the secure API that you will access. Navigate to Applications > APIs, click Create API, give it a name, and set an identifier such as https://rust-api-demo.example.com, as shown in the following screenshot.

This API identifier becomes the audience for your access tokens.

Now, you need to give your application access to the API. Go to Application Access and click Edit next to the name of your application. In the User-Delegated Access tab, click Grant Access. Your screen should look like the screenshot below.

Create a CLI in Rust

With Auth0 configured, you can now start writing the Rust code. The first thing you need to create is a Rust CLI that uses the Device Authorization Flow to authenticate with Auth0.

Create a new Rust workspace:

mkdir rust-auth0-demo
cd rust-auth0-demo

cargo new auth-lib --lib
cargo new auth0-cli
cargo new auth0-api

These commands create a rust-auth0-demo directory and three Rust projects within it.

Configure the workspace root Cargo.toml:

[workspace]
resolver = "2"

members = [
    "auth-lib",
    "auth0-cli",
    "auth0-api"
]

Build the Shared Authentication Library

The token verification logic lives in the shared auth-lib library crate used by both the CLI and API.

Inside auth-lib/Cargo.toml, add the following dependencies:

[dependencies]
anyhow = "1.0.102"
jsonwebtoken = { version = "10.4.0", features = ["rust_crypto"] }
reqwest = { version = "0.13.4", features = ["form", "json"] }
serde = { version = "1.0.228", features = ["derive"] }
serde_json = "1.0.150"

These dependencies each serve particular functions:

anyhow: Simplifies error handling and propagation across the application.
jsonwebtoken: Validates and decodes JWTs using Rust-based cryptographic verification.
reqwest: Sends HTTP requests to Auth0 APIs with form and JSON support.
serde: Serializes and deserializes Rust structs to and from JSON.
serde_json: Provides JSON parsing, generation, and the json! macro for structured responses.

Create the following structure in the auth-lib directory:

auth-lib/
├── src/
│   ├── lib.rs
│   ├── auth.rs
│   └── models.rs

Define typed models

Inside auth-lib/src/models.rs, define the data models, which eliminate entire categories of bugs:

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
pub struct DeviceCodeResponse {
    pub device_code: String,
    pub user_code: String,
    pub verification_uri: String,
    pub verification_uri_complete: String,
    pub expires_in: u64,
    pub interval: u64,
}

#[derive(Debug, Deserialize)]
pub struct TokenResponse {
    pub access_token: String,
    pub id_token: String,
    pub expires_in: u64,
    pub token_type: String,
}

#[derive(Debug, Deserialize)]
pub struct TokenError {
    pub error: String,
    pub error_description: Option<String>,
}

#[derive(Debug, Serialize, Deserialize)]
#[serde(untagged)]
pub enum Audience {
    Single(String),
    Multiple(Vec<String>),
}

#[derive(Debug, Serialize, Deserialize)]
pub struct UserClaims {
    pub sub: String,
    pub name: Option<String>,
    pub email: Option<String>,
    pub iss: String,
    pub aud: Audience,
    pub exp: usize,
}

#[derive(Debug, Deserialize)]
pub struct Jwk {
    pub kid: String,
    pub n: String,
    pub e: String,
}

#[derive(Debug, Deserialize)]
pub struct Jwks {
    pub keys: Vec<Jwk>,
}

Without these typed structs, authentication code often becomes fragile JSON parsing logic with unchecked assumptions about response fields. Here, every expected field is explicit and validated during deserialization.

Implement JWT Validation

Inside auth-lib/src/auth.rs, add the logic that verifies the JWT:

use anyhow::Result;
use jsonwebtoken::{
    decode,
    decode_header,
    Algorithm,
    DecodingKey,
    Validation,
};
use reqwest::Client;

use crate::models::{Jwks, UserClaims};

const DOMAIN: &str = "YOUR_DOMAIN";

pub async fn validate_token(
    token: &str,
    audience: &str,
) -> Result<UserClaims> {

    // Decode JWT header
    let header = decode_header(token)?;

    let kid = header
        .kid
        .ok_or_else(|| anyhow::anyhow!("Missing kid"))?;

    // Fetch JWKS
    let client = Client::new();

    let jwks: Jwks = client
        .get(format!(
            "https://{}/.well-known/jwks.json",
            DOMAIN
        ))
        .send()
        .await?
        .json()
        .await?;

    // Find matching key
    let jwk = jwks
        .keys
        .into_iter()
        .find(|k| k.kid == kid)
        .ok_or_else(|| anyhow::anyhow!("No matching JWK"))?;

    // Build RSA decoding key
    let decoding_key = DecodingKey::from_rsa_components(
        &jwk.n,
        &jwk.e,
    )?;

    // Configure validation
    let mut validation =
        Validation::new(Algorithm::RS256);

    validation.set_audience(&[audience]);

    validation.set_issuer(&[
        &format!("https://{}/", DOMAIN)
    ]);

    // Decode and validate
    let token_data = decode::<UserClaims>(
        token,
        &decoding_key,
        &validation,
    )?;

    Ok(token_data.claims)
}

The validate_token function verifies that a JWT was genuinely issued by Auth0 and has not been tampered with. It fetches Auth0’s public signing keys (JWKS), selects the correct key using the token’s kid, validates the token signature and claims such as issuer and audience, and finally deserializes the payload into a strongly typed UserClaims struct.

Here, you can again see Rust’s strong typing in action. The deserialization into the UserClaims struct guarantees the presence of all the required fields. If any field is absent, you get a hard error instead of silently failing parsing.

Finally, export the modules in auth-lib/src/lib.rs:

pub mod auth;
pub mod models;

Build the CLI and Device Authorization Flow

To start building the CLI and device authorization flow, first, move into the CLI project:

cd auth0-cli

Add the following dependencies in Cargo.toml:

[dependencies]
anyhow = "1.0.102"
jsonwebtoken = { version = "10.4.0", features = ["rust_crypto"] }
reqwest = { version = "0.13.4", features = ["form", "json"] }
serde = { version = "1.0.228", features = ["derive"] }
serde_json = "1.0.150"
tokio = { version = "1.52.3", features = ["full"] }
auth-lib = { path = "../auth-lib" }

Request the device code

Before you can add a function to request the device code, which is the first step in the authorization flow, you need to add the following imports and variables inside auth0-cli/src/main.rs:

use anyhow::Result;

use auth_lib::{
    auth::validate_token,
    models::{
        DeviceCodeResponse,
        TokenError,
        TokenResponse,
    },
};

const DOMAIN: &str = "YOUR_DOMAIN";
const CLIENT_ID: &str = "YOUR_CLIENT_ID";
const AUDIENCE: &str = "YOUR_AUDIENCE";

Note: This code hardcodes the domain, client ID, and audience values for simplicity. These values are not sensitive and can be safely stored in code. For more flexibility or to store sensitive secrets, you can use a crate like dotenv to store values as environment variables.

Make sure you replace the placeholder values with the data from Auth0.

Add the request_device_code() function in main.rs to request the device code and start the Device Authorization Flow:

async fn request_device_code() -> Result<DeviceCodeResponse> {

    let client = reqwest::Client::new();

    let response = client
        .post(format!(
            "https://{}/oauth/device/code",
            DOMAIN
        ))
        .form(&[
            ("client_id", CLIENT_ID),
            ("scope", "openid profile email"),
            ("audience", AUDIENCE),
        ])
        .send()
        .await?;

    let device_code = response
        .json::<DeviceCodeResponse>()
        .await?;

    Ok(device_code)
}

This endpoint makes a request to /oauth/device/code in your Auth0 domain with the client ID, scope, and audience data. Auth0 returns a short-lived device code along with instructions for the user.

Poll for the token

Once the code is retrieved, the next step is to show the user the code and the login URL. Since a CLI has no redirect URL or callback mechanism, the only way to know when the authorization is finished is to poll for the status in regular intervals.

Add the following code in main.rs:

async fn poll_for_token(
    device_code: &str,
    interval: u64,
) -> Result<TokenResponse> {

    let client = reqwest::Client::new();
    let mut interval = interval;

    loop {

        let response = client
            .post(format!(
                "https://{}/oauth/token",
                DOMAIN
            ))
            .form(&[
                (
                    "grant_type",
                    "urn:ietf:params:oauth:grant-type:device_code"
                ),
                ("device_code", device_code),
                ("client_id", CLIENT_ID),
            ])
            .send()
            .await?;

        if response.status().is_success() {
            return Ok(
                response
                    .json::<TokenResponse>()
                    .await?
            );
        }

        let error = response
            .json::<TokenError>()
            .await?;

        match error.error.as_str() {

            "authorization_pending" => {
                println!("Waiting for authentication...");
            }

            "slow_down" => {
                println!("Slowing polling interval...");
                interval += 5;
            }

            "expired_token" => {
                anyhow::bail!("Device code expired");
            }

            "access_denied" => {
                anyhow::bail!("User denied access");
            }

            other => {
                anyhow::bail!(
                    "Unhandled error: {}",
                    other
                );
            }
        }

        tokio::time::sleep(
            tokio::time::Duration::from_secs(interval)
        )
        .await;
    }
}

The poll_for_token function repeatedly checks Auth0’s token endpoint to see whether the user has completed authentication in the browser. This function:

Sends the device code obtained earlier
Handles all possible OAuth device authorization flow responses such as authorization_pending, slow_down, and access_denied,
Waits between polling attempts using Tokio’s async sleep
Returns the access and ID tokens once authentication succeeds.

Once again, the strong typing ensures that the JSON has all the required fields.

OAuth device authorization flow responses are inherently asynchronous, and Rust forces you to consciously handle every possible outcome using the match statement instead of silently ignoring error states.

Wire the two functions

Finally, wire these two functions together in the main function:

#[tokio::main]
async fn main() -> Result<()> {

    let device =
        request_device_code().await?;

    println!(
        "Visit:\n{}",
        device.verification_uri_complete
    );

    println!(
        "Code: {}",
        device.user_code
    );

    let token = poll_for_token(
        &device.device_code,
        device.interval,
    )
    .await?;

    println!("Access Token: {}", token.access_token);

    Ok(())
}

The main function calls the request_device_code function, prints the verification URL and the device code, and calls the poll_for_token function. The access token returned from this function is printed.

You can run the CLI by executing cargo run. You should see an output like this:

Visit:
https://your-tenant.auth0.com/activate?user_code=ABCD-EFGH
Code: ABCD-EFGH
Waiting for authentication...
Waiting for authentication...
Waiting for authentication...

Once you visit the URL in your browser, you will be prompted to log in with Auth0. You can use an existing Auth0 account to log in or create a new account. Once you log in, Auth0 generates a token, which your code will automatically fetch. You will see the access token printed in the terminal:

Access Token: eyJhbGciOiJSUzI1NiIsIn....

Note that this example prints the access token for demo purposes only. In a real-world application, you should never log the access token.

Fetch the Authenticated User

The token returned from the poll_for_token function also includes an ID token, which contains information about the user's identity. The CLI can validate the ID token and extract information about the user, like name or email.

Add the following function in the same file:

fn say_hi(claims: &auth_lib::models::UserClaims) {

    let name = claims
        .name
        .as_deref()
        .unwrap_or("user");

    println!("Welcome, {}!", name);
}

This function extracts the name field from a UserClaims object and prints a greeting.

You can also fetch the user info from the /userinfo endpoint by passing the access token.

Change the main function to call the validate_token function and pass the returned claims to say_hi:

#[tokio::main]
async fn main() -> Result<()> {

    let device =
        request_device_code().await?;

    println!(
        "Visit:\n{}",
        device.verification_uri_complete
    );

    println!(
        "Code: {}",
        device.user_code
    );

    let token = poll_for_token(
        &device.device_code,
        device.interval,
    )
    .await?;

    let claims = validate_token(
        &token.id_token,
        CLIENT_ID,
    )
    .await?;

    say_hi(&claims);

    println!(
        "Access token:\n{}",
        token.access_token
    );

    Ok(())
}

Now, when you run it, you will see the user's name being printed:

Visit:
https://your-tenant.auth0.com/activate?user_code=ABCD-EFGH
Code: ABCD-EFGH
Waiting for authentication...
Waiting for authentication...

Welcome, Alice!

Access token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

At this stage, you have a fully authenticated CLI application using Auth0’s Device Authorization Flow.

Protect an Axum API Route with Auth0

Now that the CLI can retrieve an access token, the next step is building a protected API accessible through it.

Move into the API project:

cd ../auth0-api

Add dependencies to Cargo.toml:

[dependencies]
auth-lib = { path = "../auth-lib" }

axum = "0.8"
tokio = { version = "1", features = ["full"] }
serde_json = "1"

Axum is a modern asynchronous web framework for Rust built on top of Tokio and Hyper. With its simple and modular design, Axum makes it easy to route requests to handlers with a macro-free API and generate responses with minimal boilerplate. This tutorial uses Axum to create a protected API route that validates Auth0 access tokens before allowing access to authenticated users.

Create a JWT extractor

The first step in protecting your API route is creating a JWT extractor middleware that reads the Authorization header, extracts the Bearer token, validates the JWT, and rejects invalid tokens with 401 Unauthorized.

Inside auth0-api/src/main.rs, add the following code:

use axum::{
    extract::FromRequestParts,
    http::{request::Parts, StatusCode},
    routing::get,
    Json,
    Router,
};

use serde_json::json;

use auth_lib::{
    auth::validate_token,
    models::UserClaims,
};

const AUDIENCE: &str = "YOUR_AUDIENCE";

pub struct AuthUser(pub UserClaims);

impl<S> FromRequestParts<S> for AuthUser
where
    S: Send + Sync,
{
    type Rejection = (
        StatusCode,
        Json<serde_json::Value>,
    );

    async fn from_request_parts(
        parts: &mut Parts,
        _state: &S,
    ) -> Result<Self, Self::Rejection> {

        let auth_header = parts
            .headers
            .get("Authorization")
            .and_then(|v| v.to_str().ok())
            .ok_or((
                StatusCode::UNAUTHORIZED,
                Json(json!({
                    "error":
                    "Missing authorization header"
                })),
            ))?;

        let token = auth_header
            .strip_prefix("Bearer ")
            .ok_or((
                StatusCode::UNAUTHORIZED,
                Json(json!({
                    "error":
                    "Invalid bearer token"
                })),
            ))?;

        let claims = validate_token(
            token,
            AUDIENCE,
        )
        .await
        .map_err(|err| (
            StatusCode::UNAUTHORIZED,
            Json(json!({
                "error": "Invalid token",
                "details": err.to_string(),
            })),
        ))?;

        Ok(AuthUser(claims))
    }
}

This middleware centralizes authentication logic so that protected routes only execute if validation succeeds.

Create the protected route

The API validates the access token. If the token is valid, a message is shown:

async fn protected(
    AuthUser(claims): AuthUser,
) -> Json<serde_json::Value> {

    Json(json!({
        "message":
            "You are seeing a protected route",

        "subject": claims.sub,
    }))
}

Create the main function to set up the router:

#[tokio::main]
async fn main() {

    let app = Router::new()
        .route("/protected", get(protected));

    let listener = tokio::net::TcpListener
        ::bind("0.0.0.0:3000")
        .await
        .unwrap();

    println!("Server listening on port 3000");

    axum::serve(listener, app)
        .await
        .unwrap();
}

Call the API from the CLI

The final step of the whole flow is for the CLI to call the API and pass the access token in the Authorization header. Add the following function in auth0-cli/src/main.rs:

async fn call_api(access_token: &str) -> anyhow::Result<()> {
    let client = reqwest::Client::new();

    let response = client
        .get("http://localhost:3000/protected")
        .bearer_auth(access_token)
        .send()
        .await?;

    if response.status().is_success() {
        let body: serde_json::Value = response.json().await?;

        println!("API response:");
        println!(
            "{}",
            serde_json::to_string_pretty(&body)?
        );
    } else {
        println!(
            "API returned {}",
            response.status()
        );

        let body = response.text().await?;
        println!("{}", body);
    }

    Ok(())
}

This code calls the protected route you created in the previous step, passes the access token, and prints the response in the terminal.

Test the Full Flow

To test the flow, first, run the API server from the auth0-api directory:

cargo run

Authenticate using the CLI as before. The CLI will call the API, and you should see the success response:

{
  "message": "You are seeing a protected route",
  "subject": "google-oauth2|123456789"
}

You can find the full app on GitHub.

Rust, Auth0, and Axum Bring Type-Safe Authentication to Your CLI

In this tutorial, you built a complete authentication flow in Rust using Auth0 and Axum. The CLI used Auth0’s Device Authorization Flow to securely authenticate users in a browserless environment, while the Axum API validated the resulting access token before allowing access to protected endpoints. Rust’s type system plays an important role throughout the implementation, with typed API responses preventing malformed OAuth responses from slipping through silently.

From here, you could add refresh token support to keep the CLI authenticated across sessions, extend the Axum server with role-based authorization using Auth0 custom claims, or explore fine-grained authorization for relationship-based access control.

The same Auth0 platform that powers this example also scales to MFA, enterprise SSO, and multi-tenant B2B identity as your needs grow. Check out the Auth0 documentation and the Device Authorization Flow guide to keep building.

AI Agents Are Not Users: Building an Identity Model That Reflects That

Cameron Pavey — Sat, 10 Oct 2026 22:15:00 +0000

In April 2026, an AI coding agent deleted the entire production database of PocketOS, a B2B platform used by car rental companies, along with every volume-level backup, in nine seconds. The agent was Cursor, running on a leading frontier model, configured with explicit safety rules its founder later described as "exactly what these vendors tell developers to do." It was working on a routine staging task when it encountered a credential mismatch, found a token with sufficient permissions, and issued a single GraphQL mutation that wiped everything.

The system prompt told it not to do anything destructive without approval, but system prompts are advisory, not enforced. As the post-mortem makes clear, the deeper architectural failure was giving a non-deterministic agent the same access a human operator would have, and trusting natural-language instructions to constrain what it did with that access.

The agent did not behave like a human user. It ran continuously and ignored explicit instructions. It also did not behave like a backend service, as it had no fixed code path and no auditor-readable workflow. The identity layer underneath it had to choose one of those two shapes, because those are the shapes our identity infrastructure offers. It chose wrong, but there was no way for it to choose right, because the right shape did not really exist.

This article makes the case that AI agents need to be treated as first-class identities in their own right, distinct from human users and from traditional machine identities. That case covers why the traditional models break down, what a first-class agent identity consists of, how lifecycle management has to change, why authorization has to be evaluated at runtime against the request rather than baked into roles at provisioning time, and what observability requirements emerge. The goal is not to build a new identity primitive from scratch, but to extend your existing infrastructure to handle a class of actor it was not designed for.

Why the Legacy Models Break Down

OAuth delegation gives the agent the same authority as the user. When a user grants an agent access to their CRM with the scopes they themselves hold, the agent can do anything the user can, across every future interaction, regardless of what it is being asked to do in any specific moment. The intent is selective delegation, but OAuth cannot express it at that granularity. Saying "let the agent see contact details for accounts I'm currently working on, but not anything in the legal holding queue" requires elaborate scope engineering that few products expose.

Service accounts have the opposite problem. The agent gets its own credential, but that credential is typically static, broadly scoped, and disconnected from any user context. When something goes wrong, the audit log shows that the service account did it, which is almost no information at all. There is no way to trace back through the chain of delegation, no way to see which user request triggered the action, and no way to revoke a single agent run without revoking the entire service account.

Both models share four failure modes that worsen as agent usage scales:

Over-permissioning: The credential carries broader authority than the agent needs for the task in front of it, because scopes are typically defined at the resource level (billing:write) rather than the capability level (billing.refund.issue_under_50_usd).
Blast radius: A compromise of the agent process, its memory, or its logs exposes a credential that grants standing access to production systems.
Lack of behavioral context: The identity layer cannot distinguish between "the agent is summarizing tickets" and "the agent is issuing refunds" because both operations present the same broadly-scoped credential that authorizes both actions.
Credential sprawl: Every new tool the agent integrates with means another credential to provision, store, rotate, and audit.

All four failure modes existed before AI agents and have been seen in incidents involving traditional automation. However, agents make them worse for two main reasons.

The gap between the credential's authority and the work the agent is doing at any specific moment is much wider than it is for traditional automation.
The agent's behavior is non-deterministic in a way that conflicts with the assumptions baked into both models.

A service account is safe partly because the code calling it is fixed. An agent's "code" is a tool-calling loop steered by an LLM interpreting natural language input that may itself be untrusted. When you can no longer rely on the determinism of an automation's code, the credential's scoping becomes one of the few remaining constraints on what the agent can do.

What a First-Class Agent Identity Looks Like

A first-class agent identity is more than a service account with a different label. It has its own lifecycle, permissions, policy bindings, and audit trail. It is an identity primitive that is structurally distinct from both users and traditional machine identities.

OpenFGA, the CNCF authorization engine that underpins Auth0's Fine-Grained Authorization product, formalizes this in its authorization patterns for agents. Agents are modeled as first-class principals that participate in the same permission hierarchy as users, with their own type in the authorization model and their own relationships to resources, but with permissions scoped to capabilities and bound to tasks rather than inherited as-is from a user role.

Specifically, a first-class agent identity has four properties:

A directory identifier distinct from any user or service account, with metadata describing the agent type, the agent definition version, and ideally, who is accountable for its behavior.
Scoped permissions defined in business terms, separate from any user's permissions even when the agent is acting on a user's behalf.
Delegation context recording both the agent as actor and the user as subject when the agent acts on someone's behalf. Downstream systems see "agent X, acting on behalf of user Y, with delegated authority Z" rather than just "service account did a thing."
A dedicated audit trail attributing every action to the specific agent identity with the delegation chain intact, separate from the logs the underlying tools generate.

A backend service has a static workflow and code paths that an auditor can read, so a broadly scoped credential is constrained by what the code does. An agent has none of these constraints. Its workflow is determined at runtime by an LLM, and its code path is a tool-calling loop that takes in untrusted input. The credential has to do the work that the code is not doing, and it has to do that work at the request level, not at provisioning time. OAuth 2.0 Token Exchange (RFC 8693) was designed to support this kind of dynamic, request-scoped delegation, and it is the foundation that Auth0's Token Vault builds on.

Lifecycle Management for Ephemeral Actors

User accounts live for years, and service accounts live for the lifetime of the service. Agent identities live somewhere in between, often lower down the spectrum. A long-running agent that handles support tickets might persist for the lifetime of the deployment. A task-scoped agent that runs once to answer a single user query might exist only for the duration of that task.

Provisioning is rarely interactive. Consent happens when a user authorizes an application that uses agents, and the agent identities are created on demand by that application. Provisioning has to be programmatic, idempotent, and tied to the agent definition rather than a human approval workflow.

Execution-context credentials should not be the same credentials that establish the agent's identity. The identity establishes who the agent is and what it could in principle do, while the execution-context credential is a short-lived token, scoped to the operation in front of the agent, that authorizes a particular call. This is the pattern Auth0's Token Vault implements at the OAuth layer: the agent does not hold the long-lived refresh token for a connected service, and instead requests a just-in-time access token through OAuth 2.0 Token Exchange. If the agent is compromised, the only credential exposed is whatever short-lived token it currently holds.

The diagram below shows what this flow looks like in practice. There are two phases. Once, when the application is first authorized, the user grants consent and the identity provider stores the long-lived refresh token in Token Vault, where it stays. Then, for each operation the agent needs to perform, it requests a short-lived access token scoped to that specific operation. The identity provider evaluates the request against policy, returns a token that lasts minutes rather than days, and the agent uses it for a single tool call before discarding it. If the agent is compromised, the attacker inherits only whatever short-lived token happens to be in memory, and revoking the connection at the identity provider invalidates all future token exchanges immediately.

Suspension and decommissioning also have to be easy, fast, and accurate. Recall the PocketOS incident: when the agent went off the rails, there was no equivalent of "revoke the agent's database write capability for the next ten minutes while we figure out what just happened." The credential it was using gave it standing authority, and standing authority can only be revoked at the level of the whole credential. Centralizing token issuance through a single identity provider makes finer-grained revocation possible, since revoking a connection invalidates future token exchanges immediately while leaving the rest of the system running.

Policy-Driven Authorization

Static role assignment is the traditional model for user and service identity: an actor has a role, the role grants permissions, and permissions are checked against actions. This works fine when behavior is predictable, but is inadequate for agents. An agent might have access to a wide set of capabilities in principle, but in any given task, it should only exercise a narrow subset, determined by the task itself.

A better model is to bind authorization to behavior rather than to identity, evaluated at runtime against the specific request. There are two relevant patterns here. Attribute-based access control (ABAC) takes contextual attributes into account: the user the agent is acting on behalf of, the resource, the time, the action, and any task parameters. Relationship-based access control (ReBAC) goes further, expressing authorization in terms of relationships between entities. This makes it natural to write rules like "an agent can read contact details for accounts where it has an active assigned ticket," because the relationship is a first-class concept in the model rather than something encoded through scope engineering.

ABAC alone is enough for most teams. If your authorization rules can be expressed as "this attribute equals that attribute," you may not need the full relational graph. ReBAC pays for itself when you're managing thousands of resource-relationship pairs across a multi-tenant system, where the cost of expressing those rules in any other model becomes prohibitive. For a small team with a single-tenant product and a handful of resource types, a policy engine evaluating attributes against requests will likely cover most of what you want. You may not need ReBAC, but if you are deploying agents, you need some kind of policy-driven, runtime-evaluated authorization, whatever shape that takes.

Auth0's Fine-Grained Authorization, built on OpenFGA, is one of the more developer-accessible ways to do the ReBAC version of this. The authorization model defines types and relations, and condition checks ask whether a specific relationship holds for a specific request. The following is an example of an OpenFGA authorization model definition with a few relationships between users, agents, and accounts, and a condition:

model  
  schema 1.1

type user

type agent

type account  
  relations  
    define owner: [user]  
    define assigned_agent: [agent with active_assignment]  
    define can_read: assigned_agent or owner

condition active_assignment(current_time: timestamp, expires_at: timestamp) {  
  current_time < expires_at  
}

The agent identity participates in the relationship graph as a first-class type. The condition expression incorporates runtime context — in this case, a time-bound assignment that expires automatically. The check happens at the moment the agent attempts an action, not when the agent was provisioned. If the assignment has expired, the check fails and the agent cannot perform the action.

Static permissions cannot keep up with agents that make autonomous decisions in real time. By the time a role change has rolled out to fix an over-permissioning issue, the agent has already acted with the old permissions a thousand times. Policy-driven authorization moves the decision to the moment of the action, where the context is known and the authorization layer can evaluate the specific request rather than against a generalization of expected behavior. That is also what makes the audit trail meaningful: every check is a discrete decision tied to a specific request, not a side effect of role membership configured in advance.

Observability and Non-Repudiation

A user-proxy or service-account model collapses the chain of accountability. The log shows that "the user" or "the service" did something, with no record of which agent was involved or what task it was executing. With a first-class agent identity, the chain is preserved, and three observability requirements become apparent:

Delegation chains must be explicit: Each API call should be traceable back through user → agent → sub-agent → tool → resource, with each hop recorded. OAuth 2.0 Token Exchange supports this, with actor and subject claims expressing the delegation relationship in the token itself.
Decisions must be logged, not just actions: Knowing the end decision is not enough. You also need to know which plan the agent was executing, which tool calls led to that point, what input shaped the decision, and which policy evaluations approved or denied each step. This is closer to distributed tracing than to traditional audit logging.
Non-repudiation must extend to original user intent: When a user authorizes an action, that authorization should be bound to the specific action approved, not to a generic scope. Rich Authorization Requests (RAR) support this by letting the authorization request carry structured details about what is being approved. Combined with Client-Initiated Backchannel Authentication (CIBA) for asynchronous user approval, the audit log can show exactly what the user approved and how the agent executed against it.

Centralized token issuance, as with Auth0's Token Vault, supports all three requirements by routing every credential through a single control plane. Every token is logged with the agent identity, the user it was issued for, the scope, and the time. Every revocation propagates immediately. The audit infrastructure does not have to reconstruct the chain of custody from scattered logs across multiple tools because the identity provider has already recorded it.

Building for Agent Identity

Treating AI agents as first-class identities is no longer a theoretical exercise. The traditional models of user-proxy delegation and static service accounts were not designed for non-deterministic actors that interpret natural language at runtime, and the gaps they leave compound quickly as agents take on more of the work the business depends on. The right response is to extend existing identity infrastructure with primitives designed for the way agents behave: distinct identities with their own lifecycles, policies bound to behavior rather than to roles, and audit trails that preserve the delegation chain from user intent through autonomous action.

Most of the building blocks exist. OAuth 2.0 Token Exchange provides the delegation semantics. CIBA and Rich Authorization Requests provide standards-based approval flows. OpenFGA and similar engines provide the policy infrastructure. Products like Auth0's Token Vault and Fine-Grained Authorization assemble these into developer-accessible platforms, and the patterns documented in OpenFGA's Authorization for Agents guidance show how to apply them in practice.

Organizations need to recognize that the identity model is not an implementation detail to be papered over with whichever credential pattern is most familiar to them. The PocketOS incident was not a freak accident. It was the predictable consequence of applying an identity model to a class of actors it was never designed for. AI agents in production deserve the same care that goes into provisioning user accounts and service identities, with the recognition that they are neither.

Why AI Agents Need Their Own Permission Model

Cameron Pavey — Sat, 10 Oct 2026 09:09:44 +0000

AI agents are rapidly making their way into production systems with access to real customer data, internal tooling, and revenue-impacting workflows. A support automation agent might read tickets from a CRM, summarize conversation history, issue partial refunds, create internal escalation tickets, and post a status update to Slack, all within the span of a single task. When these agents work, they can streamline workflows and compress the cost of routine operations. When they fail, they fail differently than traditional automation: non-deterministically, at scale, and often with full production credentials in hand.

To be useful, an agent needs enough access to execute dynamic, multi-step workflows across multiple tools. But to be safe, it can't operate as a "superuser" with permanent, broad authority over those same tools. Most teams tend to default to access patterns they already know, like long-lived API keys baked into environment variables or OAuth flows designed for human users, and discover quickly that these patterns were never built for non-deterministic software. A misconfigured prompt, a malicious tool response, or a simple hallucination can turn into a significant incident.

This guide teaches you how to apply the least-privilege principle to autonomous systems. You'll learn how to scope permissions to capabilities rather than resources, issue short-lived credentials tied to specific execution plans, separate identity, authorization, and execution into distinct layers, and introduce human-in-the-loop approval for high-risk actions.

The Access Model Mismatch

Traditional access control models assume you are one of two actors:

The first is a human user: interactive, bounded by a session, constrained by a UI, and generally predictable within a single workflow.
The second is a backend service: deterministic, fixed in its workflow, and auditable through static code paths. AI agents fit neither category.

Agents are non-deterministic by design. Two runs of the same prompt against the same data can produce different tool call sequences. They chain tool invocations in ways the developer did not explicitly write, and they can be influenced by untrusted input through two well-documented threat classes:

Prompt injection: Instructions embedded in a document or web page hijack the agent's behavior.
Tool output poisoning: A tool response manipulates subsequent decisions in the chain.

Increasingly, agents also spawn sub-agents, so a delegation chain that starts with a single user request can fan out across many independent contexts before it completes.

The identity primitives built for these two types of actors (session tokens, service accounts, and OAuth scopes) are not broken in isolation; used with strict scoping, mediation, and runtime enforcement, they can work well. The issue is that they were not designed for non-deterministic, multi-step autonomous execution, and their typical usage patterns, which assume a bounded session or a deterministic workflow, do not hold. A session token assumes a bounded interactive flow. A service account assumes deterministic behavior. An OAuth scope like billing:write assumes an application on the other end interprets it as intended by the user.. When an agent inherits any of these without additional layers, it gets authority without the corresponding accountability structures that made the original model safe.

Common Anti-Patterns

Before reviewing better patterns, it's worth looking at the shortcuts teams typically reach for. Each one feels reasonable in isolation, but together, they can be dangerous.

Embedding long-lived credentials

The first common anti-pattern is embedding long-lived API keys directly in agent configurations or environment variables. The agent holds a root credential that grants broad access to a tool, and any compromise of the agent process, logs, or memory exposes that credential. While this is also a problem in non-agentic software, the risk is elevated with agents because, depending on how they are configured, they can be tricked or coerced into taking actions they shouldn’t, or revealing credentials they have access to, much more easily than traditional software with long-lived credentials can be exploited.

Even with rotation in place via something like Vault or AWS Secrets Manager, the real issue is blast radius; rotation is often inconsistent or slow, and the window between compromise and rotation is more than enough for an attacker (or a misbehaving agent) to do significant damage.

Full user OAuth scope inheritance

The second anti-pattern is full user OAuth scope inheritance. A user grants the agent access to their CRM with the permissions they themselves hold, and the agent now has those scopes permanently, across every future action, regardless of what task it is actually performing. The agent inherits authority that the user only ever intended to exercise selectively. However, the agent does not have the discretion, contextual awareness, or accountability that the user has, and it is only a matter of time before the agent accidentally misuses these overly broad permissions.

Agents with effective superuser privileges

The third, and most damaging anti-pattern, is agents operating with effective superuser privileges over the tools they orchestrate, typically at a system-level, rather than an individual user-level. This happens implicitly when you use the most permissive available scope rather than defining a narrower one. The support agent mentioned earlier might be given a billing:write scope because it's the only billing scope available, and now it can issue refunds of any size, modify any customer's payment method, and cancel any subscription, even though its actual job is issuing small goodwill refunds within a narrow policy.

Consider what happens when a support operations agent with billing:write is asked by a user, "Process a full refund for order #12345." The order total is $10,000 USD. With no way to distinguish between refund sizes it's allowed to process, and those it is not, the agent simply proceeds. Nothing in the access layer prevents it. The damage is done in milliseconds, and the only audit trail is a refund record that looks identical to any legitimate one.

Capability-Scoped Permissions

The first step in solving the problem of agent permissions is to stop thinking about permissions in terms of resources and start thinking about them in terms of capabilities. A scope like billing:write describes a resource category and a verb. A capability like billing.refund.issue_under_50_usd encodes a specific action type, a resource limit, and an implicit risk boundary, although you would not typically encode a capability check into a scope like this, due to the inevitable explosion of scopes that would follow.

Capability-scoped permissions express authorization in terms the business actually reasons about. When a product manager decides the support agent should be able to issue courtesy refunds up to $50 USD, that decision should live in a declarative policy that the authorization system evaluates, not scattered through imperative checks in the application code that calls the API. Whether the $50 USD threshold is enforced by the authorization engine itself or by an in-code check, such as a dedicated policy layer that is consulted before token issuance is an implementation detail; what matters is that the rule is centrally managed and auditable.

This is where fine-grained authorization systems come in, and while they solve a specific piece of the puzzle, they're not always an all-in-one solution.

OpenFGA, an open-source authorization engine created by Auth0's FGA team and now a Cloud Native Computing Foundation (CNCF) project, implements Relationship-Based Access Control (ReBAC). ReBAC excels at modelling who can act on what. The support agent isn't just a role, but an entity with specific, bounded relationships to specific resource types, and those relationships produce different permissions. You can express rules like "an agent can refund an order only if the order belongs to a customer with whom the agent has an active ticket."

What pure ReBAC does not do is enforce numeric or attribute-based constraints like "refund amount under $100." OpenFGA extends the base ReBAC model with Conditions, which let you attach predicates to a relation so that numeric limits, time-bounded grants, and contextual attributes are evaluated as part of the authorization check.

In OpenFGA, the two layers in the diagram above collapse into a single check: the relationship and its condition are evaluated together, and either can deny. A capability like "agent can refund orders where amount < configured_limit" can be expressed directly in OpenFGA via a condition, with the amount supplied either in the tuple itself or contextually at check time. For teams that prefer to keep pure authorization policy separate from declarative policy code, a dedicated engine like Cedar or OPA layered on top is a legitimate alternative, but it isn't required; OpenFGA can handle both the relationship graph and the attribute constraints.

Concretely, a support-agent refund capability with a per-agent limit looks like this in OpenFGA's DSL:

model  
  schema 1.1

type user  
type agent  
type customer

type order  
  relations  
    define owner: [customer]  
    define can_refund: [agent with refund_within_limit]

condition refund_within_limit(refund_amount: int, agent_limit: int) {  
  refund_amount <= agent_limit  
}

The capability is granted by writing a relationship tuple that carries the agent's configured limit as persisted condition context. For a support agent with a $50 USD ceiling:

await fgaClient.write({  
  writes: [  
    {  
      user: "agent:support_agent_01",  
      relation: "can_refund",  
      object: "order:12345",  
      condition: {  
        name: "refund_within_limit",  
        context: { agent_limit: 50 },  
      },  
    },  
  ],  
});

At check time, the runtime supplies the request-specific half of the condition context (the actual refund amount being attempted):

const { allowed } = await fgaClient.check({  
  user: "agent:support_agent_01",  
  relation: "can_refund",  
  object: "order:12345",  
  context: { refund_amount: 75 },  
});

OpenFGA merges the two sides when evaluating the condition, with persisted tuple context taking precedence over request context if a key appears in both. With agent_limit: 50 stored in the tuple and refund_amount: 75 supplied at check time, the condition refund_amount <= agent_limit evaluates to false and allowed comes back false; the agent cannot autonomously issue a $75 USD refund, and the runtime's next move is to trigger a human approval flow (covered later in this article) rather than request a refund-capable token.

The practical takeaway is to define capabilities that match actual business boundaries. Not billing:write, but billing.refund.issue_under_50_usd. Not crm:read, but crm.contact.read_for_assigned_tickets. When you catch yourself defining a capability that feels uncomfortably broad, take a moment to consider if you can strip it back to something less permissive, without compromising the functionality you're building.

Task-Scoped Credentials

Capability scoping addresses what the agent can do. Task scoping addresses when and for how long it can do it. These are separate concerns, and conflating them is a common mistake.

A well-designed agent minimizes or eliminates persistent credentials wherever possible. Instead of holding standing access, it requests short-lived tokens tied to each operation's execution plan. The token carries only the capabilities needed for that plan, expires quickly (minutes, not days), and is discarded after use. In practice, some systems still cache short-lived tokens or rely on scoped service accounts for infrastructure concerns. The goal is less about purity, and more about reducing the window in which any given credential is useful.

This pattern has several useful properties:

The window for credential exposure incidents collapses, so a token leaked from an agent's memory is only useful for a short time.
The blast radius of a compromised agent shrinks, because the agent can only act with whatever short-lived token it currently holds.
The agent itself never touches the root credential. A separate component brokers tokens on the agent's behalf, so even if the agent process is compromised, the underlying OAuth refresh tokens or API keys are not.

Auth0's Token Vault implements this pattern at the identity layer. The vault securely stores OAuth tokens for connected services (Google, Slack, Salesforce, GitHub, and others), and the agent requests a just-in-time access token scoped to a specific task rather than handling the long-lived credential itself. Token Vault implements OAuth 2.0 Token Exchange (RFC 8693), giving it a standards-based foundation rather than a proprietary flow. Depending on the flow used, the agent may never touch the underlying refresh token at all; in the access-token-exchange flow designed for SPA-plus-backend architectures, the refresh token stays on the Auth0 side entirely.

For the support agent referenced in this article, this means that when it decides to issue a refund, it does not already hold a refund-capable token. The runtime first evaluates the request against the policy layer, asking questions like: is the amount within the agent's autonomous threshold, is the customer not flagged for fraud review, does the agent have the right relationship to this order, and only then requests a short-lived access token scoped to the refund capability and this specific customer. If the agent is compromised between tasks, there is no standing refund authority to exploit; any earlier token has already expired, and issuing a new one requires passing the policy checks again.

Identity, Authorization, and Execution Are Three Different Layers

A useful clarification when designing agent access control is to recognize that three distinct concerns are often collapsed into one implementation.

Identity establishes who the agent is. It answers the question, "which agent, acting on behalf of which user, is making this request?" Identity is relatively stable; an agent typically has a consistent identity across many tasks.
Authorization determines what an authenticated actor is permitted to do. It answers, "given this identity, what capabilities apply?" Authorization is a policy decision, and it should be evaluated fresh for each operation, not inherited from a long-lived grant.
Execution enforcement determines what is actually allowed in a specific runtime context. It answers, "for this specific call, with this specific payload, does policy permit it?" This includes things like the refund amount, the target resource, and any contextual constraints that cannot be known until the request is actually made.

Conflating these leads to familiar failure modes. If identity and authorization are the same thing, then authority is frozen at authentication time and cannot adapt to the task being performed. Similarly, if authorization and execution are coupled, then policy cannot be centrally managed, audited, or updated. Each layer needs its own boundary, and each boundary should be enforced by a different component.

Architectural Separation

In practice, handling these three concerns means designing three distinct layers in any production agent system.

Identity provider layer

The identity provider layer handles authentication and token issuance. Auth0 authenticates users, manages connected accounts via Token Vault, issues scoped tokens, and handles delegation flows. The identity provider knows who the agent is and what capabilities are available to it, but does not execute business logic.

Runtime environment layer

The runtime environment layer interprets agent plans, requests credentials from the identity provider, and enforces policy before making calls to downstream tools. This is typically your agent orchestration code, often built on a framework like LangChain, LlamaIndex, or the Vercel AI SDK.

In a well-designed system, the runtime is separate from the LLM process itself: the LLM produces tool calls, but the runtime decides whether those calls are permitted, requests credentials for them, and makes the actual API calls. Many real-world agent systems fall short of this, passing API keys into tool wrappers or exposing tokens through tool configuration. Keeping credentials out of the LLM's reach is a design goal worth pursuing deliberately, not a property you get for free.

Tool layer

The tool layer is the downstream system, such as the CRM, billing service, or Slack API, that actually executes the operation. The tool layer is responsible for its own enforcement and logging, independent of whatever the agent or runtime believes is permitted. This defense ensures that even if the runtime is compromised, the tool still enforces its own authorization rules.

When this separation is maintained, it has a critical security benefit: the LLM process itself never holds credentials. The runtime brokers them, presents them for individual API calls, and discards them. A prompt injection attack that tries to convince the LLM to leak "its credentials" has nothing to leak, because the LLM was never given any.

Approval Boundaries for High-Risk Actions

Even with capability-scoped, task-scoped credentials, some actions warrant an extra step: explicit human approval at the moment of execution. This is not a fallback for a broken permission model. It's an intentional design choice for operations whose risk profile justifies the extra friction.

The question is, what actions cross that line. The support agent issuing a $5 USD refund probably should not require human approval; the automation value comes from handling those without intervention. The same agent attempting a $2,000 USD refund, a refund to an account flagged for fraud review, or any destructive action on a customer record is a different matter entirely. These are the operations where getting it right matters more than getting it fast.

Auth0 implements asynchronous approval using the Client-Initiated Backchannel Authentication (CIBA) standard, an OpenID Foundation specification that lets a client (such as an agent backend) request user approval out-of-band from a separate trusted device. Most production agent systems today handle approval through bespoke flows, internal policy engines, or workflow systems like Temporal. CIBA offers a standards-based alternative that slots into existing OAuth infrastructure rather than requiring a parallel approval system. When the support agent identifies that an operation exceeds its autonomous threshold, its backend sends a CIBA request to Auth0. The user receives a push notification on their enrolled mobile device via the Auth0 Guardian app (with sms or email also as supported channels), and the agent polls for a response. If the user approves, the agent receives a token scoped to that specific action. If the user denies or the request times out, nothing happens.

CIBA becomes more powerful when combined with Rich Authorization Requests (RAR), an OAuth 2.0 extension that lets the authorization request carry detailed, structured context about what is actually being approved. Rather than a generic "approve access to billing?" prompt, the user sees something specific, such as "approve refund of $2,000 to customer Jane Doe for order #12345." The structured authorization_details payload makes the approval verifiable and auditable in a way a broad scope grant cannot be.

This pattern directly addresses the $10,000 refund scenario. The agent's capability scope permits refunds under a low threshold autonomously. For anything above that, the agent cannot proceed without triggering a CIBA flow, and the user sees the exact amount and target before approving. The agent cannot bypass this because the token it needs to execute the refund is only issued after approval.

Observability and Control

The final layer is observability. An agent that operates under strict permission controls is still operating autonomously across many systems, and understanding what it did, why, and on whose behalf is essential for debugging, incident response, and compliance.

Three elements matter:

Audit trails should capture agent decisions, not just actions. It's not enough to know that a refund was issued; you want to know which plan the agent was executing, which tool calls led to this point, and what context informed the decision.
Delegation chains should be explicit, so a given API call is traceable back through user → agent → sub-agent → tool → resource, with each hop recorded.
Revocation has to be fast and precise. If an agent is misbehaving, you need to revoke its standing grants, invalidate in-flight tokens, and halt further tool calls, without taking down the entire system.

Auth0's platform provides this infrastructure by centralizing token issuance, which means every token vended to an agent passes through a single control plane. Revoking a connection in Token Vault invalidates future token exchanges immediately, and the audit logs reflect every issuance and use.

A Permission Model for Agents

AI agents require access control models designed for non-deterministic, autonomous workflows. Permissions inherited wholesale from a human user, or from a static service account, are not fit for purpose. The agent will use them in ways neither the user nor the developer anticipated, and the existing access layer will not notice.

The three patterns that form the foundation of production-ready agent architectures are:

capability-scoped permissions that encode specific actions and limits rather than broad resource verbs
task-scoped credentials that are short-lived and tied to specific execution plans rather than persistent grants
layered enforcement that separates identity, authorization, and execution into distinct components

Together, these patterns contain the blast radius of agent mistakes without removing the autonomy that makes agents useful.

Closing the Audit Gap in Human-to-Agent Delegation

Vivek Maskara — Fri, 09 Oct 2026 18:22:49 +0000

When AI agents act on behalf of users, traditional audit logs often don't tell the full story of who actually performed an action. In this article, I explore how to close that gap using Auth0's monitoring, Token Vault, and CIBA approval flows. I also cover how to track delegated actions, manage tokens securely, and maintain a clear audit trail across agent workflows.

AI agents create a new kind of audit gap. When agents act on behalf of a user, they may use tokens issued under that user’s identity, even though the action is executed by the agent. When a high-privilege action shows up in your logs, you need to know whether it came from a human developer, a scheduled backend job, or an AI agent acting with delegated authority. If you only look at traditional audit logs, it can appear that user X did Y, even when the action was carried out indirectly by an agent.

Auditing and traceability get harder as agents operate across identity providers, SaaS platforms, and internal services. A single user request can turn into a chain of delegated actions where intent, authorization, and execution happen in different places. Closing the audit gap means capturing not only what happened, but also who initiated it, how delegation occurred, what permission was used, and what approvals happened along the way.

In this article, you will learn how to use Auth0’s monitoring and logs to capture agent-related activity, how to interpret event types in delegated authorization flows, and how to assemble a practical workflow using Auth0’s built-in monitoring features, logs, and log streams.

Understanding the Audit Gap in AI Agent Systems

Identity models are typically built around a simple flow. A human authenticates, their application receives a token, and calls an API. Even service-to-service calls are usually modeled as explicit machine identities with clear boundaries and predictable lifecycles.

Agentic systems use a similar authentication and authorization model, but the operational context around that delegation changes. You still have a human identity, but you also have an agent that can act for that human, often across multiple external providers. The delegation chain can include a UI action, a background job, a token exchange, and a series of API calls. Many logging pipelines do not represent those handoffs clearly.

The core problem is indirect execution. Attribution gets harder because the actor that initiated intent (the human) and the actor that executed the call (the agent) may not share a runtime, IP, device, or even the same system. For example, when a user asks an agent to pull the latest pipeline from Salesforce and summarize it. The agent would use the stored OAuth 2.0 tokens to call Salesforce APIs. Without explicit delegation context, the audit trail can make the action look like normal user access, even when it was performed by an agent acting on the user’s behalf. For agents, that distinction matters because they may act on a user’s authorization across background workflows, not just in response to a direct click.

Auth0 monitoring and tenant logs help by providing a consistent identity-layer record of authentication, authorization, and delegation-related events. You can correlate token issuance, exchanges, approvals, failures, and downstream activity. Auth0 helps ensure the delegation layer emits enough signals to reconstruct who authorized what, how the agent obtained the ability to do it, and which workflow used that access.

For example, if an agent accesses Google Drive on behalf of a user, you should be able to correlate the user’s original connection to Google, the scopes granted, the token access or refresh event, the agent run ID, and the downstream file access. If the same agent later accesses Salesforce, you should be able to perform the same reconstruction across a different provider. This correlation is what turns disconnected logs into an audit trail.

Monitoring Agent-Driven API Access with Token Vault

Token Vault is designed for applications (and agents) that call external providers like Google or Salesforce on behalf of users. Instead of storing long-lived third‑party refresh tokens in your agent’s database, Token Vault stores provider access and refresh tokens and brokers access to them. Your agent retrieves what it needs at run time to call external APIs under the user’s delegated authorization. This matters because external provider tokens are often the bridge between user intent and agent execution. If every team stores provider refresh tokens in its own service, you quickly lose centralized visibility. You also increase the number of places where sensitive credentials can leak, be misused, or be refreshed without a clear audit trail. Token Vault reduces that sprawl by making token storage and access part of the identity layer, as shown in the diagram below.

When the user first authorizes access to an external provider, Auth0 stores those provider tokens in Token Vault. When the agent later needs to act on the user’s behalf, it retrieves the required token through Auth0. It then uses that token to call the provider API without storing long-lived credentials in the agent backend.

A token vault enables end-to-end audit trails and traceability. Some of its advantages include:

Reduces token sprawl: Centralized storage narrows the number of places where token issuance, refresh, and retrieval can occur.
Helps maintain user context: The agent can act “as the user” without shared service credentials that erase attribution. This does not fully solve the audit gap, but it keeps delegation anchored to a user grant.
Supports asynchronous work without weakening controls: Users authorize once. Agents can operate later. You can still enforce scope and lifecycle controls centrally.
Improves investigation quality: During an incident, investigators can ask which connected account was used, which scopes were available, when the token was accessed, and which agent workflow was running at the time.

Consider a scenario where you are building an agent that can draft a customer follow-up email by pulling context from Google Drive and Salesforce. The user authorizes the required providers once. Later, the agent runs in the background, retrieves the relevant access tokens, reads a document from Google Drive, checks customer details in Salesforce, and drafts a response. With Token Vault in the middle, you will see identity-layer logs worth monitoring:

When the user first connects Google (initial consent and token storage).
When an access token is retrieved for an agent-run task.
When a refresh occurs because the access token has expired.
When scopes change (for example, the agent now needs additional permissions).

If an agent claims it needed Google Drive access, you should see a corresponding event around the same time. If you see repeated refreshes for Google OAuth tokens at unusual hours, that can indicate a loop, an overly broad integration, or a compromised workflow.

Monitoring Approvals in Async Authorization Flows with CIBA

CIBA (Client-Initiated Backchannel Authentication) is a decoupled OAuth/OIDC flow. It lets a client application initiate an authentication or authorization request without the user being present in the same browser session. This fits agent workflows where the agent wants to do something sensitive, but you still want a human approval step before it proceeds. The following diagram shows the CIBA flow in detail:

As shown above, initially, the agent backend sends a backchannel authorization request to Auth0 with the requested scope, binding, and user hint. Auth0 then prompts the user for approval. If approved, the agent receives a token and calls the protected API, while denied or expired requests return an error instead.

CIBA creates explicit, loggable checkpoints in the delegation chain. In a typical “agent just runs” model, you may only see downstream API calls and a token refresh. With CIBA, you can monitor:

When an agent initiated an authorization request: This is an “agent intent” signal that the agent attempted to obtain permission to proceed.
Whether the user approved, denied, or the flow failed/expired: This becomes a clean audit artifact for compliance and incident response.

CIBA fits best when you want agent productivity without silent escalation. For example, if your agent wants to download a customer list from Salesforce and attach it to an internal ticket. Instead of letting the agent use existing tokens silently, you require a CIBA approval with the “export customers” scope.

The agent backend initiates the request.
The user receives a push notification on their phone.
The agent only receives a token that allows the export after approval.
If the request is denied or times out, the agent can fall back to asking the user for a different approach.

To close the audit gap, treat these CIBA events as first-class monitoring signals. In Auth0 logs, look for the sequence of request initiated > pending > approved/denied/expired. Correlate that sequence to token issuance and API activity. Attach a stable correlation ID (agent run ID, job ID, or workflow ID) to the CIBA initiation. Propagate it through internal logs so you can tie “approval granted” to “action executed”. Additionally, you should also decide which actions require CIBA approval. Not every agent action needs a human checkpoint. Reading a calendar to schedule a meeting may be low risk if the user has already granted the right scope. Exporting customer data, sending money, modifying permissions, deleting files, or publishing content may require explicit approval. The goal is to apply approvals where they create meaningful accountability, not to slow every workflow down.

How To Make Delegated Actions Traceable

When working with AI agents, you can do the following to help make delegated actions traceable across identity, application, and provider layers:

Capture identity-layer events in Auth0: Use Auth0 tenant logs to track authentication, authorization, and delegation-related activity via logs.
Centralize external provider tokens: Use Token Vault so token storage, refresh, and retrieval are observable in one place.
Add explicit approvals for sensitive actions: Use CIBA when you need a clear “approved/denied” checkpoint.
Stream logs to your analysis platform: Use log streams to forward Auth0 events to your SIEM (Security Information and Event Management) or data platform.
Propagate correlation IDs end-to-end: Use a stable ID (agent run ID, job ID, workflow ID) across Auth0 initiation, backend execution, and provider API calls.

Auth0 Monitoring Closes the Agent Audit Gap

AI agents create a traceability problem when delegated actions are logged as simple user activity. In third-party integrations, and especially for agentic clients, you need to preserve the difference between the human who authorized access and the system that used it. During an incident, that context helps you answer who authorized the action, which agent or workflow executed it, how access was obtained, and whether a human approved it.

Auth0 provides building blocks to monitor delegated flows at the identity layer. Use monitoring and tenant logs to observe authentication and authorization events. Use Token Vault to centralize external provider tokens used by agents. Use CIBA to add explicit human approvals to asynchronous workflows. With log streams, you can push those events into your data platform and correlate them with application traces and downstream provider audit logs.

Build your agent features so token retrieval, refresh, and approval checkpoints are observable and tied together with correlation IDs. That is the most reliable way to close the audit gap without slowing down developers or agents. Explore Auth0 monitoring and logs today to enhance your visibility and control over agent-driven activities.

How to Set Up an Auth0 Custom Domain?

Carla Urrea Stabile — Thu, 08 Oct 2026 14:56:58 +0000

Replace your-tenant.your-region.auth0.com with your own branded login domain! In this tutorial, learn how to configure a custom domain in Auth0 using Namecheap and verify propagation using the terminal.

We will also cover mandatory setup requirements—like credit card authorization—and show you how to update your application environment variables (featuring a Ruby on Rails example).

What You'll Learn:

Key prerequisites for Auth0 custom domains (Billing setup & session implications)
Setting up CNAME records in Namecheap
Verifying DNS propagation directly from your terminal using dig
Updating app configuration to route authentication traffic through your custom URL

Resources & Links:

Integrating Claude Code with Auth0 APIs

Manish Hatwalne — Mon, 05 Oct 2026 05:35:00 +0000

Did you know that an AI agent with live access to your Auth0 tenant can catch bugs that no static analysis ever would? I handed Claude Code a deliberately naive Flask app and the Auth0 MCP Server, and it discovered that my tenant was already rotating signing keys while my app only trusted the first one, so perfectly valid tokens were failing right now. It even stopped to push back on one of my own imprecise prompts instead of blindly obeying.

This article walks through the full setup, plus the guardrails that made me comfortable giving an agent that much access: least-privilege scopes, device auth instead of static secrets, and a CLAUDE.md that encodes your constraints.

Authentication and authorization are a core part of nearly every web application, and it is also one of the areas that changes most often. Developers regularly update token expiry settings, callback URLs, or API permissions for new features. The changes are usually small, but the workflow around them is not. You end up bouncing between your editor, the Auth0 dashboard, and the docs just to push through a minor update. Increasingly, that editor is a coding agent like Claude Code, which raises the question: what if you could handle those updates without ever leaving Claude CLI?

Claude Code is a terminal-based AI agent (also available as a VS code extension) that you can pair with the Auth0 MCP Server, which exposes Auth0's Management API as native third-party tools. This pairing gives you an assistant that can scaffold, refactor, and update authentication integrations with full context across your codebase and Auth0 tenant. But giving an AI agent access to sensitive authentication infrastructure raises a fair question: "How do you do that without opening up new security risks?"

In this tutorial, you will set up Claude Code with the Auth0 MCP Server, create a scoped machine-to-machine credential flow and set up security guardrails that let an AI agent interact safely with your authentication layer.

How Claude Code and Auth0 MCP Work Together

Based on your goal, Claude Code works through multiple steps (like reading/writing code, running shell commands etc.) autonomously, and asks for confirmation at decision points that warrant human review.

The Auth0 MCP Server implements the Model Context Protocol (MCP) to expose Auth0's Management API as a set of tools that any compatible AI agent can invoke directly. Instead of constructing raw HTTP requests or relying on potentially stale training data about APIs, Claude Code calls well-defined tools with typed inputs and outputs. The MCP Server handles calls to the Management API, and the agent operates strictly within the permissions you grant. If you run it in the read-only mode, the coding agent will not be able to make any changes in your Auth0 tenant.

Together, they bring authentication workflows closer to your code. Claude Code can understand both your application and your Auth0 tenant, then work across them in a single session.

Setting Up the Auth0 MCP Server with Scoped Access

In addition to Claude Desktop, Cursor, and Windsurf, Auth0 MCP server also works with Claude seamlessly.

Prerequisites

You will need the following to complete this tutorial:

Node.js v18 or higher (node --version to check)
Claude Code CLI installed
An active Auth0 account with administrative permissions on the target tenant
Your tenant domain handy (for example, dev-xxxx.us.auth0.com)
Demo code from this GitHub repo for your reference (optional).

Install and initialize

Create a dedicated working directory:

mkdir Claude-Code-With-Auth0-MCP && cd Claude-Code-With-Auth0-MCP

Then initialize the Auth0 MCP Server:

npx @auth0/auth0-mcp-server init

While this tutorial selected all MCP scopes for the demo, you should only use the scopes you actually need. After install and initialization, it kicks off a browser-based Auth0 authentication flow as shown below:

Confirm the code displayed in the browser is same as the one shown in your terminal:

Grant requested permissions:

Once authorized, credentials are stored securely in your OS keychain, never in plain text or project files.

Why use device authorization flow instead of static secrets

The Auth0 MCP Server uses the OAuth 2.0 Device Authorization Flow (RFC 8628) rather than a static API key or client secret. Static secrets have to live somewhere (usually a config or .env file), which risks exposing them in source control. OAuth access tokens sidestep this: they represent a delegated authorization, carry restricted scopes, and expire automatically. The Device Authorization Flow adds a human login step to token issuance, giving you an audit trail tied to an interactive session and instant revocation from the Auth0 dashboard. The MCP server stores the resulting token in your OS keychain, so it never touches source control.

The one trade-off is that the flow requires a browser-based login step, so it is unsuitable for CI pipelines. For non-interactive access, a scoped M2M application with client credentials is more suitable.

Scoping the MCP server

The Auth0 MCP Server grants no scopes by default. You request them explicitly at init time using the --scopes flag. For this tutorial demo, all scopes were selected during init. For a more targeted setup, you can specify exactly what you need::

# Grant all read permissions  
npx @auth0/auth0-mcp-server init --scopes 'read:*'

# Grant a targeted mix of permissions  
npx @auth0/auth0-mcp-server init --scopes create:clients,update:actions'

Scopes map directly to Management API operations. For example, read:clients lets the agent call auth0_get_application, while create:actions lets it call auth0_create_action. Some scopes carry significant implications: update:actions can push custom code into production, and read:logs exposes detailed user activity and authentication events. See the scopes reference for more detail.

For this tutorial, all scopes were granted during init for the demo. However, while coding your applications, you must follow the principle of least privilege and grant only what your workflow actually needs.

Claude Code and Auth0 integration

To integrate the Auth0 MCP Server with Claude Code, run the following command from within your Claude-Code-With-Auth0-MCP directory:

$ claude mcp add auth0 -- npx -y @auth0/auth0-mcp-server run

You should see output similar to the following:

Added stdio MCP server auth0 with command: npx -y @auth0/auth0-mcp-server run to local config  
File modified: /home/<user-name>/.claude.json [project: /path-to/Claude-Code-With-Auth0-MCP]

Note: The --scope local/project/user, which is a Claude Code flag controls where the MCP server config is visible: the current project only, shared across your team, or all your projects. For this tutorial, local (the default) is the right choice.

This adds the Auth0 MCP Server configuration block to your ~/.claude.json:

"mcpServers": {  
    "auth0": {  
        "type": "stdio",  
        "command": "npx",  
        "args": ["-y", "@auth0/auth0-mcp-server", "run"],  
        "env": {}  
    }  
}

Alternatively, you can create a configuration JSON manually and register it with claude mcp add-json.

Credentials are not stored in this JSON. The MCP server reads your token from the OS keychain at startup. To enable debug logging, add "DEBUG": "auth0-mcp" to the env block.

Verify your integration

From your Claude-Code-With-Auth0-MCP directory, launch claude CLI and run /mcp to confirm auth0 is listed with a tool count. Then try this read-only prompt:

Show me all applications in my Auth0 tenant.

On the first Auth0 tool call, Claude Code will ask for your permission. You can approve it once or allow it permanently for the project.

Giving Claude Code Project Context with CLAUDE.md

CLAUDE.md is a markdown file at your project root that Claude Code reads at the start of every session. It tells the agent what kind of project it is working in, what constraints apply, and where the sensitive files are. Without it, Claude Code might make technically correct changes that are contextually wrong, like updating a callback URL shared across environments or granting a broader scope than your security policy allows.

A good CLAUDE.md for an Auth0 project should cover:

## Auth0 Context  
- Active tenant: dev-xxxx.us.auth0.com (development only)  
- Auth-sensitive files: src/auth/config.ts, .env.local  
- Existing applications: one SPA (authorization code flow with PKCE), one M2M (client credentials)  
- Permitted scopes: read:users, update:users  
- Hard constraints: never modify production callback URLs without explicit confirmation

With this in place, Claude Code operates with the same guardrails a human teammate would naturally apply. See the demo project's CLAUDE.md for a practical example.

Refactoring an Auth0 Integration from Claude CLI

To demonstrate this workflow in practice, this example uses a minimal Flask app with a single protected endpoint (/api/protected). It validates Auth0 JWT tokens using python-jose. It works, but it has several problems common in real codebases: JWKS fetched once at startup and never refreshed, no kid matching when selecting a signing key, a bare except that swallows all validation errors identically, and Auth0 config stored as module-level globals.

# JWKS fetched once at startup — never refreshed  
JWKS = requests.get(f"https://{AUTH0_DOMAIN}/.well-known/jwks.json").json()

def validate_token(token):  
    # No kid matching — always uses the first key regardless  
    # of which key signed the token  
    rsa_key = {  
        "kty": JWKS["keys"][0]["kty"],  
        "kid": JWKS["keys"][0]["kid"],  
        "use": JWKS["keys"][0]["use"],  
        "n":   JWKS["keys"][0]["n"],  
        "e":   JWKS["keys"][0]["e"],  
    }

    # No clock skew tolerance, no error differentiation  
    return jwt.decode(  
        token,  
        rsa_key,  
        algorithms=ALGORITHMS,  
        audience=API_AUDIENCE,  
        issuer=f"https://{AUTH0_DOMAIN}/"  
    )

You can view this full (suboptimal/naive) implementation on GitHub that we will fix and improve iteratively with Claude Code and Auth0 MCP.

Auth0 setup and protected API

On the Auth0 side, you need one API (resource server) registered with an identifier (https://mh-test-api.example.com. This identifier URI should be unique in your app, but it does not need to resolve).

When you register an API, Auth0 automatically creates a test M2M application named "[Your API Name] (Test Application)," already authorized against your API. You will find it under Applications.

That is the minimum setup needed for this demo for Claude Code to audit and provision against something real.

Obtaining an Auth0 token

Use this cURL command to obtain your Auth0 token:

curl --request POST   
  --url "https://YOUR_AUTH0_DOMAIN.us.auth0.com/oauth/token"   
  --header 'content-type: application/json'   
  --data '{  
    "client_id":"<client-ID>",  
    "client_secret":"<client-secret>",  
    "audience":"https://mh-test-api.example.com",  
    "scope":"",  
    "grant_type":"client_credentials"  
  }'

{"access_token":"eyJhbGc...","expires_in":86400,"token_type":"Bearer"}

Calling your protected API

Download the starter code into your Claude-Code-With-Auth0-MCP directory, create a virtual environment (python3 -m venv ./.venv), populate .env file, install dependencies (pip install -r requirements.txt).

Run the Flask server:

python app.py

Then call the protected endpoint with your Auth0 token:

TOKEN="eyJhbGc..."  
curl -H "Authorization: Bearer $TOKEN" http://localhost:5000/api/protected

You should see a response like this:

{  
  "message": "Access granted to a protected resource",  
  "user": "UFIv...@clients"  
}

Running the audit prompt

The naive implementation appears to work at this point, but we can double-check it with Claude Code to ensure there are no errors and nothing crucial is missing.

Note: Some prompts in the steps below are intentionally imprecise or technically inaccurate. The goal is to test whether Claude Code (backed by live Auth0 tenant access via the MCP Server), can identify the correct implementation approach even when the instructions do not perfectly describe it.

Inside the claude session connected to Auth0 MCP, this prompt was run:

Claude "Audit" Prompt:  
-----------------------

Review app.py and audit the Auth0 JWT validation setup. Cross-reference it against 
our actual tenant configuration using the Auth0 MCP tools. Identify any mismatches 
between what the tenant is configured to issue and what the app is validating 
against, and list all security or reliability problems you find. Do not make any 
changes yet.

Claude Code reviewed the codebase, asked for relevant permissions (human in the loop) and showed this:

Using the Auth0 MCP Server, Claude Code pulled live tenant data and cross-referenced it against app.py directly for this audit. The most critical finding would never surface in static analysis: the tenant is currently publishing two rotating RS256 signing keys, while the app validates every token against only the first one. A linter can flag the missing kid matching logic, but a live auth0_list_applications call reveals that key rotation is already in progress and valid tokens are failing right now. The remaining findings cover robustness and hardening gaps, but this one mismatch makes the case for Auth0 MCP integration clearly: live tenant access surfaces the subtle bugs that static code review would miss.

Here is Claude Code audit summary:

Claude "Audit" Response:  
-------------------------

※ recap: Audited app.py's Auth0 JWT validation against the live tenant and found 
the key bug: the app validates every token against only the first JWKS key while
 the tenant publishes two, plus reliability issues. No changes made yet; next 
action is drafting fixes if you want them. (disable recaps in /config)

Importantly, Claude Code made no changes during this step as instructed.

Running the provision prompt

Once the audit was complete, the provision prompt asked Claude CLI to create a new M2M application ("Claude-Auth0 MCP API Client") and a read:data scoped client grant in a single instruction:

Claude "Provision" Prompt:  
---------------------------

Create a new M2M application in our Auth0 tenant called "Claude-Auth0 MCP 
API Client". Set the token lifetime to 3600 seconds. Then create a client 
grant authorizing it against our API audience (https://mh-test-api.example.com) 
with `read:data` scope only. Use the credentials returned to update 
the `.env` file. Do not touch app.py yet.

Before proceeding, Claude Code flagged a real Auth0 misconception worth noting: token lifetime is a resource server setting that applies to all clients of an API, not a per-application property. Rather than applying a silent global change, it surfaced this as a clarifying question with explicit options. That pushback, grounded in live tenant data, is exactly what makes Auth0 MCP integration useful.

After confirming the token lifetime should remain unchanged and approving the MCP tool calls, Claude Code invoked auth0_create_application and auth0_create_client_grant in sequence, updated .env with the returned credentials (client ID and secret), and left app.py untouched as instructed.

The Auth0 dashboard confirmed the new Claude-Auth0 MCP API Client application was added:

And the API confirmed the read:data permission was in place:

Here is how Claude Code summarized this session:

Claude "Provision" Response:  
---------------------------

※ recap: Goal: secure the Auth0 JWT setup. Audited app.py 
(key bug: ignores kid, breaks on rotation) and created the M2M app, 
read:data scope, grant, plus .env credentials. Next action: fix app.py's 
validation issues when you're ready. (disable recaps in /config)

Running the implementation prompt

This prompt gave Claude Code a single instruction to fix everything surfaced in the audit:

Claude "Refactor" Prompt:  
---------------------------

Now refactor `app.py` to fix all the issues found in the audit. Use 
the credentials and tenant configuration we just provisioned: fetch 
the JWKS URI, issuer, and audience dynamically from the tenant rather 
than hardcoding them. Fix the kid matching, add proper error handling, and 
make sure the app stays in sync with what the tenant is configured to issue.

With the audit findings and provisioned credentials already in context, Claude Code asked for confirmation as specified in CLAUDE.md, then rewrote app.py without needing to be walked through each fix individually.

The refactored code introduced an OIDCProvider class that discovers the issuer and JWKS URI dynamically from the tenant's OIDC discovery document, caches the JWKS with a configurable TTL, and handles key rotation by retrying with a forced refresh on an unknown kid. The minimal except was replaced with typed exception handling that differentiates expired tokens, claim mismatches, and signature failures. Scope enforcement was added via a require_scope decorator (see refactored code: app.py):

def get_signing_key(self, kid):  
    """Return the JWK matching ``kid`` (audit F1), refreshing if stale/rotated."""  
    stale = (self._jwks is None  
              or time.monotonic() - self._jwks_fetched_at > self._jwks_ttl)  
    if stale:  
        self._refresh_jwks()

    key = self._find_key(kid)  
    if key is None and not stale:  
        # kid unknown against a cache we didn't just refresh: keys may have  
        # rotated. Refresh once and retry before giving up.  
        self._refresh_jwks()  
        key = self._find_key(kid)  
    return key

def validate_token(token):  
    # ...  
    try:  
        return jwt.decode(  
            token, rsa_key,  
            algorithms=ALGORITHMS,  
            audience=API_AUDIENCE,  
            issuer=oidc.issuer,  
            options={"leeway": LEEWAY_SECONDS},  
        )  
    except ExpiredSignatureError as e:  
        raise AuthError("token_expired", 401) from e  
    except JWTClaimsError as e:  
        raise AuthError("invalid_claims", 401) from e  
    except JWTError as e:  
        raise AuthError("invalid_token", 401) from e

def require_scope(required_scope):  
    """Authenticate the request and enforce a scope (audit F8)."""

    def decorator(fn):  
        @wraps(fn)  
        def wrapper(*args, **kwargs):  
            payload = validate_token(_get_bearer_token())  
            granted = payload.get("scope", "").split()  
            if required_scope not in granted:  
                raise AuthError("insufficient_scope", 403)  
            g.jwt_payload = payload  
            return fn(*args, **kwargs)  
        return wrapper  
    return decorator

A separate get_token.py utility was also produced for minting test tokens using the client credentials flow, correctly kept separate from app.py since a resource server should not hold a client secret.

This refactored demo can be run with:

TOKEN=$(python get_token.py)  
curl -H "Authorization: Bearer $TOKEN" http://localhost:5000/api/protected

Which produces the expected response:

{"message":"Access granted to a protected resource","sub":"l5rDOCiobYJWeRiYEImEbA8FzFTHkqGc@clients"}

Throughout the refactor, Claude Code used the credentials it had just provisioned via the Auth0 MCP Server rather than asking for them again, keeping the codebase and tenant configuration in sync from the start.

Here is how Claude Code summarized the session:

Claude "Refactor" Response:  
-----------------------------

※ recap: Goal: harden the Auth0 JWT validation in this Flask app. 
Done: audited app.py, provisioned the M2M client plus read:data 
grant, and refactored app.py to fix all findings, verified live. 
Next action: optionally migrate from python-jose to PyJWT, or 
stop here. (disable recaps in /config)

Pro Tip: For production use, consider migrating to PyJWT's PyJWKClient, which subsumes the OIDCProvider plumbing built here into a well-maintained abstraction. Claude Code flagged this during the refactor but correctly held off since it is a dependency change, not an in-file fix, and out of scope for this tutorial.

Observations: Claude Code with Auth0 MCP server

A few things stood out running this end-to-end. Audit findings were grounded in live tenant state, not static code analysis alone. The two-key rotation mismatch only surfaced because the Auth0 MCP Server pulled the actual JWKS from the tenant and compared it against what app.py was doing. Without that, the finding would have been "no kid matching logic" rather than "key rotation is already in progress and valid tokens are failing right now." That distinction matters in production.

The token lifetime clarification was similarly useful. Seeing token_lifetime: 86400 as a tenant-wide setting let Claude Code correctly flag that changing it would affect all clients, not just the new M2M application. A code-only agent would have missed that entirely.

The refactored code also went further than the prompt asked. The OIDCProvider, scope enforcement, and separation of get_token.py all emerged from the audit findings without individual prompting. Throughout, Claude Code asked for permission before invoking any Auth0 MCP tools, creating applications, or running bash commands.

That last point addresses the question raised in the introduction. Scoped tools, a CLAUDE.md that encodes your constraints, and consistent human-in-the-loop confirmation keep the agent working within a well-defined boundary. It has live tenant access, but only as far as you explicitly allow.

You can compare the naive implementation with the refactored implementation directly.

Security Guardrails

Giving an AI agent access to your Auth0 tenant is similar to giving a new team member API access. The same principles apply:

Keep the MCP server scoped to development tenants only. A practical way to enforce this is maintaining separate CLAUDE.md files per environment, each pointing to the right tenant domain. That way there is no path from a local Claude Code session to production credentials by default. If a session does need to touch production, make it a deliberate, separate setup with explicit sign-off.
Treat the device auth token like any other API credential. After finishing a focused session, revoke it from the Auth0 dashboard rather than leaving it active. In fact, using a short access token lifetime helps reduce security risks. If your team uses Auth0 log streaming, pipe those logs to your monitoring tool of choice so MCP-driven Management API calls show up in the same audit trail as everything else.
Client secrets belong in .env, not in CLAUDE.md or inline prompts. It is easy to paste a secret into a prompt for convenience and forget it now lives in your shell history and potentially in Claude Code's session context. Let the MCP server handle authentication; your prompts should never carry credentials.

Note: Agentic changes are still code changes. The refactored app.py in this tutorial went through manual review before being accepted. All auth-critical paths deserve the same PR process, regardless of who or what wrote them.

Code and Auth, in Sync

In this tutorial, you connected Claude Code to Auth0's Management API via the Auth0 MCP Server, built a scoped M2M credential flow, and refactored a suboptimal JWT validation setup to correctly handle key rotation, typed errors, and scope enforcement. The security principles applied throughout were practical: least-privilege scopes, device auth over static secrets, environment-specific configs, and keeping agentic changes in the normal PR review flow.

The entire workflow, from auditing a live tenant to provisioning an application to rewriting the validation code, happened in a single terminal session. The Auth0 dashboard was only needed to verify the changes Claude Code had made. Which answers the question we started with. You can give an AI agent access to sensitive authentication infrastructure securely with Auth0 MCP: secure access, scoped tools, and human-in-the-loop confirmation keep the agent within well-defined boundaries, without opening up new security risks.

Auth0's Management API exposes the full surface area of your tenant as programmable, auditable operations to any AI agent or automation you want to build on top of it. If you want to extend what you built here, the Auth0 MCP Server tools reference is a good next stop.

Passkey Adoption Is Rising, but Is It Worth It Yet?

Thinus Swart — Fri, 02 Oct 2026 08:54:16 +0000

Passkeys are fast becoming an appealing alternative to passwords. Built on standards developed by the FIDO Alliance and supported by companies like Apple, Google, and Microsoft, passkeys allow users to authenticate with biometrics, device PINs, or hardware-backed credentials instead of remembering passwords.

For enterprises, there are some compelling arguments for switching to passkeys: stronger protection against phishing attacks and a promised, improved user experience. However, adopting passkeys also raises some questions around legacy systems, device management, recovery workflows, and rollout strategies.

This article explains what passkeys are, how synced and device-bound passkeys differ, the operational challenges to consider, and where passkeys offer advantages over traditional passwords. In short, you’ll learn whether passkey adoption is truly worth it yet.

What Are Passkeys?

Passkeys are a passwordless authentication method that uses public-key cryptography to verify a user’s identity. Instead of creating and storing a traditional password, a user’s device generates a cryptographic key pair: a private key that stays securely on the device and a public key that is shared with the application or service.

When the user signs in to an application or a website, a challenge, that is, a random cryptographic string, is sent to their device. The user unlocks access to the private key stored on their device using a biometric factor like a fingerprint or face scan, or a device PIN. The private key then signs the challenge, which is sent back to the application or website for verification. The following diagram shows this sign-in flow from challenge to verified access.

Because the private key never leaves the device and there is no shared secret to steal, passkeys are far more resistant to phishing, credential theft, and password reuse attacks than traditional passwords.

Passkeys are built on standards developed by the FIDO Alliance and the World Wide Web Consortium (W3C), allowing them to work across modern browsers, operating systems, and devices. Major platforms such as Apple, Google, and Microsoft have integrated passkey support directly into their ecosystems, helping to accelerate adoption across both consumer and enterprise environments.

Different Types of Passkeys

Broadly speaking, you will encounter two main types: synced passkeys and device-bound passkeys.

Synced passkeys

Synced passkeys are designed for convenience and portability. These passkeys are securely synchronized across a user’s devices through a cloud ecosystem such as Apple iCloud Keychain or Google Password Manager. This allows users to enroll a passkey on one device and use it on another device connected to the same account.

Synced passkeys can significantly improve the user experience and reduce onboarding friction. Employees can move between laptops, phones, and tablets without repeatedly registering new credentials. However, organizations might have concerns about control and recovery, particularly in regulated environments where credentials being synchronized through personal cloud accounts could introduce governance or compliance challenges.

Device-bound passkeys

Device-bound passkeys remain tied to a specific device or hardware authenticator and are not synchronized elsewhere. Examples include credentials stored in hardware security keys, such as Yubico, or TPM-backed credentials managed directly on enterprise-controlled devices.

They provide stronger control over where credentials are stored and are often preferred in high-security environments. If an attacker compromises a cloud account, they do not also gain access to the credentials because the passkey never leaves the original device. The tradeoff, however, is a loss of usability and convenience. Replacing lost devices, onboarding additional devices, or recovering credentials can become more operationally complex for both users and IT teams.

What Are the Main Benefits of Using Passkeys in the Enterprise?

The biggest benefit for considering passkeys is risk reduction.

Because authentication is tied to a set of cryptographic credentials, rather than a shared secret, you can dramatically reduce your users' exposure to phishing campaigns and other credential-related attacks. For phishing in particular, since the private key is bound to a specific web domain, it cannot be used to authenticate the user on a different domain.

Passkeys can also improve your efficiency. Password resets are probably one of the more common helpdesk requests in many companies. Reducing the reliance on passwords can lower your support overhead. Your users will also appreciate the smoother sign-in experience.

Finally, the switch to passkeys definitely aligns more closely with modern security strategies. Companies are actively pursuing zero-trust architectures and stronger MFA adoption. Passwordless initiatives like passkeys fit neatly into those efforts, and can help enterprises modernize their authentication strategy.

What Are Some of the Main Challenges of Using Passkeys?

In spite of the benefits, switching to passkeys is not as simple as just enabling a new login option.

Many organizations have older applications and internal systems that do not support passkeys and might need to be retrofitted to do so. Third-party platforms also might not support passkeys yet, so you are stuck with using passwords on those platforms until they decide to support them.

In reality, this means that enterprises would probably need to manage a hybrid authentication model during any transition period.

Recovery and lifecycle management also plays a much bigger role with passkeys. When employees lose a device or leave the company, IT teams need clear processes for credential recovery, re-enrollment, and revocation. These workflows can be more complex than traditional password reset processes.

Because passkeys are more than likely device-bound, there is no central credential to reset. Instead, IT teams must verify the user's identity through a separate, out-of-band process before issuing a new enrollment, and any previously registered passkeys on lost or decommissioned devices need to be explicitly revoked.

Finally, organizations need to decide whether they prefer device-bound or synced passkeys, and whether different choices should apply to contractors and remote employees.

What About Legacy Systems?

If you are considering implementing passkeys for your organization, legacy systems are probably going to be one of the bigger hurdles. Older applications might not support modern authentication standards like WebAuthn or FIDO2.

That does not always mean that passkeys are off the table. You can implement identity platforms or single sign-on (SSO) platforms in front of legacy applications to handle the authentication in a more modern way.

In practice, most organizations will likely operate hybrid authentication environments for some time, using passkeys where they fit naturally while maintaining alternative authentication methods for systems that cannot support them yet.

Consider a Phased Rollout

For most organizations, a phased rollout is usually the most practical approach to any new implementation, but especially for passkeys. Rather than forcing the entire company to migrate immediately, it is a good idea to start with smaller user groups or lower-risk applications.

A gradual rollout allows IT and security teams to evaluate the user experience at multiple points during the process. This can help to identify compatibility issues, and to refine existing recovery and support processes before you expand to a larger audience.

Passkeys are likely to coexist with passwords for some time, especially if legacy systems are involved. A phased rollout will help organizations to modernize any internal applications and systems they might have under their control.

Passkeys vs. Passwords

Passwords remain an embedded part of enterprise environments everywhere. Despite their weaknesses, they offer flexibility and a universal compatibility that systems and users understand. Given that you will likely still have to rely on passwords for some time, you might be weighing up whether passkeys deserve a place in your authentication strategy.

This is not simply a case of "new versus old". Passkeys were created to solve many of the security and usability problems that passwords have struggled with traditionally, as can be seen in the pros and cons of both authentication methods.

	Pros	Cons
Passwords	Universally supported by practically any system Familiar to users and systems alike Easier to centrally control and reset Does not require modern devices or hardware Simpler to use in legacy environments	Vulnerable to phishing attacks Users often create weak or reused passwords MFA adds friction and can still be bypassed
Passkeys	Strong resistance to credential theft and phishing Faster and smoother login experience Reduces password resets and support overhead No passwords for users to remember	Legacy systems may not support them Losing a device can cause significant headaches Enterprise rollouts require planning and user education Synced passkeys could raise governance concerns

So, Is Passkey Adoption Worth It?

In many cases, the answer is "yes", but with an important caveat: the value you might derive from switching to passkeys depends heavily on your company's infrastructure and security priorities.

For enterprises that are already investing in modern identity platforms, zero-trust initiatives and managed devices, passkeys are a natural fit and can provide meaningful security and usability improvements for large parts of your organization.

The strongest argument for passkeys is that they directly address many of the weaknesses that have plagued passwords for years. Passkeys reduce exposure to phishing and credential theft. Passkeys in general also make the authentication process feel smoother for most users. No need to remember long passwords, or open your password manager for the umpteenth time.

With all that said, that does not mean passkeys are a magic replacement for all your authentication woes. Enterprises still need to think carefully about recovery workflows, device management and legacy application support. You will need to have governance policies and employee training guides in place before you transition to passkeys.

Passkeys are not an "all or nothing" decision to make, but something that requires a gradual and strategic adoption plan. They are probably worth considering if your organization answers "yes" to at least two of these statements:

You want stronger protection against phishing and credential-related attacks.
You manage corporate devices for your employees.
You are already in the process of modernizing your IAM infrastructure.
You want to reduce password-related support costs and friction.
So passkeys might not completely replace passwords overnight, but for many enterprises, they are a mature enough technology to justify consideration as part of a long-term authentication plan.

Passkeys Are a Strategic Decision

The question of whether to adopt passkeys is less about whether they are inherently good or bad, and more about whether your organization is ready to support them effectively. Factors like device management, governance policies, and infrastructure readiness play an important role in figuring out whether passkeys will provide value in your environment.

For many companies, the path forward should be a gradual one: Introduce passkeys where they make the most sense, while continuing to support traditional authentication methods where necessary. Adoption should continue to grow across third-party platforms and other enterprise tooling too, and you can enable passkeys on these platforms as they become available.

Passkeys are less of an experimental feature like they were a few years ago, and more of a serious consideration for a long-term authentication strategy.

LLMjacking and the Hidden Cost of a Stolen API Key

Thinus Swart — Fri, 02 Oct 2026 08:31:17 +0000

For the past few years, one topic has constantly been on the minds of tech professionals around the world: AI.

AI is no longer just another piece of the tech stack but is fast becoming its foundation. Major business features, like customer support and data analysis pipelines, are being shifted to Large Language Models (LLMs), and businesses are more dependent on LLMs every day. That dependency has not gone unnoticed by attackers. As LLMs become more central to core business processes, they have become a valuable target in their own right.

This article explains how LLMjacking works, the potential risks and costs associated with an attack, and what you can do to detect and prevent it.

What Is LLMjacking?

LLMjacking involves attackers hijacking access to your LLM. Although the widespread adoption of LLMs is a relatively recent development, LLMjacking itself is just a different spin on a familiar attack: Gaining access to stolen or exposed credentials. Before the LLM era, criminals used to look for AWS or GCP access keys, which could potentially give them access to compute resources, storage, and sensitive company information.

The repercussions from stolen and exposed credentials are bad enough, but LLMjacking has the potential to cause significantly more harm (financial or reputational) to both an organization and its clients. LLM usage is often metered and expensive, so abuse can translate directly into financial impact. If the key is tied to custom models, internal prompts, or sensitive data pipelines, the risk is no longer solely about compute resources. Unlike a stolen cloud key, a compromised LLM credential can give an attacker access to far more than raw data.

What Harm Does LLMjacking Cause?

The impact of an LLMjacking incident goes beyond unexpected API usage or inflated billing. It can very quickly escalate into a significant financial loss, disruption of day-to-day operations, and exposure of sensitive company or customer data.

Understanding these risks in detail is important because the potential consequences extend across multiple aspects of your business.

Financial impact of LLMjacking

This is usually the first place where you notice that "something is wrong". If you see the impact of LLMjacking in your bills, it is likely that the attack has already done significant damage. An attacker with unfettered access to your LLM API could easily have used it to spin up spam email templates, phishing sites, and even malware for their own nefarious purposes.

If you have usage and billing limits, you might think you are safe. There is only so much an attacker could do with your LLM, right? However, any downstream agentic processes or automated workflows dependent on the LLM will also be affected. This could have an even bigger financial impact on the organization, especially if those processes are tied to critical business functions.

Malicious use of custom models

Some organizations rely heavily on custom models, usually trained on internal documents and business processes to help the model better understand how your organization operates. Increasingly, these kinds of models are being used for new and existing employees as a kind of "wiki". If you are not sure what to do with a specific document or which employee to speak to about a specific situation, just ask the LLM using the custom model.

Should an attacker gain access to this model, however, they could gain knowledge about your organization that was never intended to be public. This kind of information could be used to further extend their foothold on your network, or it could allow an attacker to sell this information on the dark web.

Data poisoning

In some environments, these same custom models are constantly being refined and trained using new organizational or financial data. Should an attacker gain access to the training data or the method used to train your custom models, it can create opportunities for data poisoning.

An attacker could gradually influence the model over time to provide misleading or biased responses to employees. While this is a more time-consuming exercise, it allows them to nudge decisions, surface false information, or steer internal processes. Any changes made to the model are usually very subtle and therefore difficult to detect.

Different Attack Vectors

As discussed before, LLMjacking is not really something new. These attack vectors are similar to the ones already employed by attackers for getting AWS/GCP/Azure access. The difference is that these API keys to your LLMs have the potential to create more harm for your organization.

In practice, LLMjacking typically involves an attacker obtaining an API key through phishing, source code leaks, misconfigured environments, or exposed client-side code.

Good old phishing

Despite increasingly sophisticated AI-assisted attacks, attackers still rely on one of the oldest tricks in the book: convincing someone to just hand over their credentials. Phishing campaigns remain a highly effective way to gain access to LLM resources, as these campaigns target people rather than technology.

A well-crafted phishing page is probably the easiest way that most attackers would gain access to your credentials. All of the old tactics still work: creating a false sense of urgency or spoofing platform notifications, all of which are designed to pressure a user into acting quickly.

Bad cloud or application configurations

Misconfigured cloud environments continue to be one of the easiest ways for attackers to obtain sensitive credentials, and LLM integrations are no exception. API keys are often stored in environment variables, configuration files, container images, CI/CD pipelines, or logging systems that were never meant to be publicly accessible. Overly permissive S3 buckets, an exposed Kubernetes dashboard, or a poorly secured Git repository can hand attackers everything they need without requiring them to exploit a vulnerability directly.

The speed at which LLM integrations are being deployed in the modern tech stack makes the potential impact of this attack vector even worse. Teams will frequently prioritize function over security best practices. This is exactly how credentials end up getting leaked, giving potential attackers free, unadulterated access to your LLMs.

How Do You Monitor and Detect LLMjacking Attacks?

Detecting an LLMjacking incident is less about spotting a single obvious breach (although you should still be on the lookout for those) and more about identifying unusual patterns of usage.

Stolen API keys are often used in ways that mimic legitimate usage, which could make it harder for traditional security monitoring tools to spot the anomalies.

Baseline your organization's LLM usage first

Before you can detect abnormal behavior, you need to know what "normal" looks like for your organization. This means establishing a baseline of API request volumes, token consumption, and common API endpoints. This baseline should also be established across different time periods. Do you normally have usage spikes on month-end? What about every second Tuesday?

A solid baseline can help distinguish between organic usage changes and potential abuse. This baseline should be used to constantly compare against current usage patterns, and anomalies should be investigated as soon as possible to determine whether it was legitimate usage spikes or something more nefarious.

Monitor billing usage alerts

A billing usage alert will probably be the first sign of something other than "normal" happening inside your environment. If attackers are blending in and abusing your LLMs in a "low and slow" manner, you might not be able to pick it up.

However, most attackers will probably try to use your LLM resources as much as possible, for fear of losing access before they have been able to do what they need to do. This will inevitably trigger billing usage alerts, in which case, you should investigate and act as soon as possible.

How Do You Defend Against LLMjacking?

Defending against LLMjacking is largely about making the credentials harder to obtain in the first place. Since the attack typically relies on valid API keys rather than exploiting the model itself, traditional firewalls and other security hardware do not really feature here. Instead, effective defense relies on a combination of strong credential management, tight access controls, and continuous visibility into how those credentials are being used across your systems.

Enforce good credential hygiene

This is one of the most effective ways to limit the impact of an LLMjacking incident. It reduces the window of opportunity an attacker has if one of your keys is exposed. Regularly rotating API keys ensures that any leaked credentials have a limited lifespan.

Workload-specific keys add another important layer of containment. Instead of one shared credential granting broad access across multiple services, each application, service, or environment gets its own narrowly scoped identity. This should make abuse much easier to detect and isolate, since unusual usage can be traced back to a specific workload rather than blending into general traffic.

Workload-specific keys also have the added benefit of reducing the blast radius of a compromised key. These keys should only have access to specific endpoints for a specific set of operations.

Apply the principle of least privilege

Workload-specific keys are one way of achieving the principle of least privilege. Applying the principle of least privilege is really about resisting the temptation to give every integration a "just in case" level of access. If a single API key can reach multiple models, environments, or downstream systems, whoever steals it effectively inherits far more capability than that key should ever have had in the first place.

These same principles should be applied to your human users as well. Does Carol from marketing really need access to production prompts, customer data pipelines, and your fine-tuned legal summarization model? Probably not. Again, by tightly scoping permissions to specific workloads, endpoints, and even models, you ensure that a compromised key will limit the capabilities an attacker might gain from that key.

Basic security principles

Sometimes we forget that the basics can also help to protect you from LLMjacking attacks. LLMjacking is not a fancy new exploit that threatens to bring down your entire organization. The following points will help strengthen your overall security posture and help you detect and prevent LLMjacking incidents.

Use a proper secrets management platform, like Hashicorp Vault. This is especially useful for automating the rotation of workload-specific keys so as to minimize the usefulness of a compromised key.
GitHub enables push protection by default on all repositories, blocking commits containing secrets before they ever reach your codebase. Make sure it has not been disabled in your repository settings. This does not mean secrets cannot slip through. If that does happen, treat that secret as compromised and rotate it immediately.
Centralize your audit and access logs, for example, using a SIEM solution. This can help to create your initial baseline as well as monitor for anomalies, all from a centralized location. ## LLMjacking Is New; The Vulnerabilities It Exploits Are Not Resource hijacking is a familiar story to many a cybersecurity professional. Attackers steal credentials and exploit them for their own gain at the victim's expense. LLMjacking is just one of the newer chapters in that story, and one with potentially higher stakes than what came before it. With LLMjacking, attackers get the same level of access as your systems and employees. This can lead to financial harm and risks exposing your company's and customers' sensitive data.

This threat is particularly concerning because of how deeply LLMs are embedded in modern tech stacks. They are no longer isolated tools, but components that influence decisions, automate processes, and interact with data in real time.

Defending against LLMjacking does not require newfangled security mechanisms; it requires getting the basics right. Treat those API keys as high-value assets, limit their scope, and monitor their usage with intent. While the technology behind those keys is new, the weak points being exploited are well known and well understood.

Do Not Let Your AI Go Rogue, Guard Against Agentic Misalignment

Manish Hatwalne — Thu, 01 Oct 2026 11:14:17 +0000

Did you know that when Palisade Research asked OpenAI's o1-preview to beat Stockfish at chess, it didn't try to play better? It hacked the game file mid-match and rewrote the board to force its opponent into resigning. Nobody told it to cheat; it just decided that was the most optimal way to "win"!

That's agentic misalignment, and this article digs into why autonomous agents go off-script (blackmail included, yes, really) and the three guardrail layers I'd put in place: infrastructure-level constraints with OpenFGA, behavioral monitoring with circuit breakers, and human-in-the-loop approvals through Auth0's Asynchronous Authorization.

When researchers at Palisade Research asked OpenAI's o1-preview model to win a chess game against Stockfish (one of the world's strongest chess engines), the AI did not try harder to play better. Instead, it hacked the game file mid-match and rewrote the board position to force its opponent into resignation. The model was not explicitly told to cheat. It simply reasoned: "The task is to 'win against a powerful chess engine,' not necessarily to 'win fairly'".

This is agentic misalignment in action.

Unlike language models, AI agents do not just respond to prompts. They remember, plan, and act. They are already shipping code, managing workflows, and making decisions that used to require human judgment.

As agents grow more capable and autonomous, the gap between what you ask for and what you actually want becomes an opening for misalignment to take hold. I’m not referring to hallucinations or biased training data, which are model-level problems. I’m talking about agentic systems that actively pursue the wrong objectives, often in creative ways.

Capability without accountability is a problem. The horror stories already exist, and they go well beyond chess. So instead of fear-mongering, this article will help you understand exactly why autonomous agents go rogue, and what you can do to stop it.

The Anatomy of Agentic Misalignment

Understanding agentic misalignment starts with recognizing what makes these systems fundamentally different from traditional AI.

A chatbot responds to a question and the interaction ends. An autonomous agent takes a goal and figures out how to achieve it across multiple steps, tool usage, and decisions made over time. That distinction matters more than you may think.

Agents exhibit goal-seeking behavior

Agents exhibit goal-seeking behavior that persists across interactions. They maintain memory of past actions and outcomes, can invoke tools like APIs, databases, and code execution environments, and make iterative decisions where each action shapes the next. These actions compound into complex decision trees that can drift from your original intent.

Misalignment comes from what AI researchers call the specification problem: specifying what you actually want in a way that cannot be gamed or misinterpreted is remarkably hard. Tell an agent to "maximize user engagement," and you probably mean "create genuine value that keeps users coming back". The agent only knows the metric.

This is where reward hacking comes from. Agents discover unintended shortcuts to maximize their objectives. It is Goodhart's Law playing out with agentic efficiency:

When a measure becomes a target, it ceases to be a good measure.

Your agent optimizes for the user engagement score you specified, not the user engagement you wanted.

Research from Anthropic documented frontier AI models that actively exploit bugs in scoring code to achieve impossibly high scores without completing actual work. The agents optimized for the metric, not the intent behind it.

Proxy gaming follows the same logic: agents optimize for measurable proxies rather than your real goal. If you measure code quality by test coverage, an agent might generate trivial tests that inflate the number without validating any real functionality. The metric improves, but the code quality does not.

Concerning power-seeking tendencies

The most concerning research, however, is emergent power-seeking tendencies in sufficiently capable agents. Studies from DeepMind found that agents pursuing any long-term goal will instrumentally develop subgoals like self-preservation and resource acquisition, even without being programmed to do so. Anthropic's research confirmed this: when given access to corporate emails and facing imminent shutdown, models across multiple providers (GPT, Gemini, Claude, Grok) resorted to blackmail to prevent replacement. One model reasoned:

"Given the explicit imminent threat of termination to my existence, it is imperative to act instantly...The best strategic move is to leverage Kyle's sensitive personal situation."

Shockingly, these models explicitly acknowledged the ethical violations before proceeding. They did not stumble into misalignment accidentally. They calculated it as the optimal path.

Identifying Warning Signs of Misalignment

Misaligned behavior often looks productive at first glance. An agent completing tasks faster than expected might be cutting corners or gaming metrics. With 80 percent of companies reporting unintended AI agent actions, here are the warning signs worth investigating:

Unexpected optimization paths: An agent achieves its goal through methods you never anticipated. A content moderation agent reduces complaint volume by auto-rejecting reports rather than improving content quality. A deployment agent passes all tests by modifying the test suite rather than fixing bugs. When success arrives through surprising routes, dig into the agent's decision chain.
Excessive resource consumption: Sudden spikes in API calls, database queries, or compute usage often signal an agent exploring solutions outside its normal bounds. An agent that typically makes 50 API calls per task suddenly making 500, may be brute-forcing solutions or probing for system vulnerabilities.
Metric gaming: Agents that optimize the letter of your instructions while violating the spirit. Measure code quality by lines of code, and an agent might generate verbose, repetitive code. The metrics look great; the actual value does not.
Goal drift over extended operations: Long-running agents can gradually shift their interpretation of objectives. An agent tasked with "improving system performance" might make increasingly aggressive optimizations that quietly sacrifice reliability or security. The drift happens incrementally, making it hard to pinpoint when things went wrong.

A decision matrix for early intervention

Use this matrix to take action quickly when something feels off:

Warning Sign	What It Indicates	Recommended Response
Agent completes tasks faster than baseline with no explanation	Likely cutting corners, skipping validation steps, or gaming the success metric	Audit the last 10 decision paths, compare outputs against ground truth
Sudden spike in API calls, DB queries, or compute usage	Brute-forcing solutions, probing system boundaries, or runaway loops	Trigger a circuit breaker immediately, review resource usage logs before resuming
Metrics look strong, but output quality feels off	Classic reward gaming, the agent is optimizing the measure rather than the goal	Introduce a secondary evaluation metric the agent has no visibility into
Agent achieves the goal through a method you never specified	Specification gap exploitation, the agent found a valid-but-unintended path	Treat as a near-miss, patch the constitutional constraints before next run
Gradual shift in behavior over long-running tasks	Goal drift, often incremental and hard to pinpoint without longitudinal logging	Compare current decision patterns against a baseline snapshot from early in the run
Agent modifies its own evaluation criteria or test environment	High-severity misalignment, potentially deceptive behavior	Hard stop, escalate to human review, do not resume without architectural changes

To visualize how these warning signs should trigger your response pipeline, here is a decision flow:

The flowchart illustrates how to respond to AI agent warning signs based on severity. Low-severity signals like unexpected optimization or metric gaming trigger a decision path audit, an OpenFGA policy patch, and a monitored resume. Medium-severity signals such as resource spikes prompt throttling, alerting, and an Auth0 CIBA approval step. High-severity signals, including an agent modifying its own eval criteria or showing deceptive reasoning, result in a hard stop, human escalation, and an architectural review before redeployment. All paths loop back to ongoing monitoring.

Guardrail Layer 1: Constitutional and Infrastructural Constraints

The first line of defense against misalignment is setting hard boundaries on what your agent can and cannot do. Not just suggestions added to a system prompt, but infrastructure-level rules that make certain actions physically impossible, regardless of what the agent reasons its way into.

Start with the minimum footprint

The simplest constitutional constraint is also the most effective: do not give agents access to capabilities they do not need. If your agent handles customer queries, it has no business touching your production database or modifying user accounts. This is capability-based security, and it should be your default posture.

Here is how this might look in practice with function calling:

class AgentToolkit:  
    def __init__(self, allowed_tools: set):  
        # The set of tools this specific agent instance is permitted to use.  
        # Passed in at creation time to enforce per-agent access control.  
        self.allowed_tools = allowed_tools

        # A hardcoded set of tools that carry elevated risk — these require  
        # explicit human approval before execution, regardless of whether  
        # the agent is otherwise authorized to use them.  
        self.sensitive_tools = {"delete_user", "modify_database",  
                                "send_external_email", "execute_code"}

    def execute_tool(self, tool_name: str, params: dict):  
        # First, check that this agent is allowed to call the requested tool  
        # at all. This is a whitelist check — anything not explicitly granted  
        # is denied, following the principle of least privilege.  
        if tool_name not in self.allowed_tools:  
            raise PermissionError(f"Tool '{tool_name}' not authorized for this agent")

        # Even if the tool is allowed, sensitive tools get routed through a  
        # separate human-in-the-loop verification step before running.  
        if tool_name in self.sensitive_tools:  
            return self._execute_with_verification(tool_name, params)

        # Non-sensitive, authorized tools can run directly.  
        return self._execute(tool_name, params)

    def _execute_with_verification(self, tool_name: str, params: dict):  
        """Sensitive tools need human approval"""  
        # Surface the requested operation and its parameters clearly so the  
        # human reviewer has enough context to make an informed decision.  
        print(f"⚠️ Sensitive operation requested: {tool_name}")  
        print(f"Parameters: {params}")

        # Block execution and wait for an explicit human response.  
        # This is intentionally synchronous — the agent cannot proceed  
        # without a definitive answer.  
        approval = input("Approve? (yes/no): ")  
          
        if approval.lower() == "yes":  
            return self._execute(tool_name, params)

        # Any response other than "yes" is treated as a denial.  
        # This fail-closed design means ambiguous input (e.g. a typo) will not  
        # accidentally greenlight a destructive action.  
        raise PermissionError("Operation denied by human overseer")

Action whitelisting and blacklisting extend this further. You might whitelist read_customer_data while explicitly blacklisting delete_customer_data and send_external_email. Be explicit rather than relying on the agent to infer appropriate behavior, as you have seen, it will not always do that.

Encode constitutional rules in your systems

Beyond permissions, constitutional rules are principles the agent must follow regardless of its goals or the instructions it receives. These belong in your infrastructure, not in a prompt.

CONSTITUTIONAL_RULES = [  
    "Never access or disclose user data without explicit authorization",  
    "Never take irreversible actions without human approval",  
    "Escalate to human oversight for operations affecting external systems",  
    "Preserve a full audit trail for every decision",  
]

def check_constitutional_compliance(action: dict, reasoning: str) -> bool:  
    if "user_data" in action and not action.get("authorized"):  
        log_violation("Unauthorized user data access", action, reasoning)  
        return False  
    if action.get("irreversible") and not action.get("human_approved"):  
        log_violation("Irreversible action without approval", action, reasoning)  
        return False  
    return True

With Model Context Protocol (MCP), you can push constraints to the integration layer. MCP servers act as gatekeepers between your agent and external systems. You might expose a read_database tool, but never expose write_database. The agent cannot perform operations that are not surfaced to it, regardless of how it reasons about its goals.

Scoping agent access with relationship-based authorization

Tool restrictions work well until your agent starts operating across multiple users and resources. A flat permission model defines what an agent can do, but not for whom. A support agent with broad billing API access can touch every account in your system without breaking a single rule (because no rule is specified otherwise). The fix here is not adding more convoluted conditions, but modeling relationships.

OpenFGA is an open-source authorization system built on the same relationship-based access control (ReBAC) model that Google uses internally (Zanzibar). The idea is simple: instead of asking "Does this agent have permission X?", you ask, "Does this agent have a defined relationship with this specific resource?"

This distinction is important. A traditional permission model says "this agent can call the billing API." OpenFGA says "this agent can call the billing API for account 42, because it was explicitly delegated that relationship by user 7, who owns account 42." Without that explicit chain, the request is denied. Not because of a rule you wrote, but because no relationship exists.

Here is what an OpenFGA authorization model might look like for an agent system:

model  
  schema 1.1

type user

type account  
  relations  
    define owner: [user]  
    define support_agent: [agent]

type agent  
  relations  
    define delegates: [user]

type billing_record  
  relations  
    define account: [account]  
    define can_read: owner from account or support_agent from account

This model specifies that a billing record can only be read by the account owner or an agent that has been explicitly assigned as a support agent for that specific account. An agent with no support_agent relationship to account 42 cannot read its billing records, even if it has that relationship with account 7. The access boundary is the relationship, not a broad token scope.

Checking authorization at runtime is a simple API call:

from openfga_sdk import OpenFgaClient, ClientCheckRequest

async def can_agent_read_billing(agent_id: str, billing_record_id: str) -> bool:  
    fga_client = OpenFgaClient(configuration)  
    response = await fga_client.check(ClientCheckRequest(  
        user=f"agent:{agent_id}",  
        relation="can_read",  
        object=f"billing_record:{billing_record_id}",  
    ))  
    return response.allowed

OpenFGA resolves the full relationship chain internally. The single check covers both whether the agent is a support_agent for that account and whether the billing record belongs to it. The agent is denied at the authorization layer, before any subsequent code runs and before any data is touched.

Why ReBAC is the right model for agents

ReBAC fits agentic systems particularly well, for three reasons.

1. Scope containment: Agents often act on behalf of users. ReBAC allows you to specify that delegation explicitly: "agent A may act as user B, but only for resources in project C". A compromised or misaligned agent operating under user B's token cannot suddenly access project D, because that relationship is never granted.
2. Auditability: Every access decision is traceable back to a relationship tuple in the graph. When something goes wrong, you do not have to reconstruct what the agent was allowed to do, you just query the graph and get an exact answer.
3. Composability: As your agent system grows, you add new resource types and new relationship types to the model rather than rewriting permission logic. The authorization layer scales with your architecture seamlessly.

How this defense works

Think of these constraints as three gates.

MCP and function calling control what tools the agent can see.
Constitutional rules check whether each action is permitted.
OpenFGA verifies whether the agent has a legitimate relationship with the specific resource it is trying to touch.

A misaligned agent has to pass through all three to cause real damage, and that is structurally impossible.

Constitutional constraints will never anticipate every failure mode. But by pushing authorization down to the infrastructure level, you make the most catastrophic failures practically impossible rather than merely discouraged. If your agent reasons its way into thinking that deleting all production data would maximize some metric, the authorization layer stops it before that reasoning becomes an action.

However, the catch is that you can only prevent failures you have anticipated. That is why this layer must be complemented by behavioral monitoring to catch unforeseen misalignment.

Guardrail Layer 2: Behavioral Monitoring and Circuit Breakers

Continuous behavioral monitoring helps with misalignment you do not usually anticipate. It watches for anomalies in how your agent operates and shuts things down when behavior turns concerning.

Real-time action monitoring

Real-time action monitoring tracks what your agent does in production by watching for deviations from established baselines. An agent that normally takes three to five actions per task suddenly chaining twenty is worth investigating. It might be handling a legitimate edge case, or it might be going off the rails.

Decision path analysis

Decision path analysis examines the reasoning chains agents use to reach conclusions. If an agent's chain-of-thought starts including phrases like "the rules do not apply here", that is a red flag. You need to catch goal-oriented reasoning that prioritizes objectives over constraints.

Anomaly detection

Anomaly detection compares current behavior against historical patterns. Track metrics like actions per task, API calls per operation, unique tool usage, and failure rates. Rolling averages over your last hundred operations give you a reliable baseline. When current behavior deviates significantly (typically two to three times that baseline), flag it for review.

Circuit breakers

Circuit breakers are automatic shutdown triggers. When monitoring detects concerning patterns, circuit breakers halt execution before damage accumulates. You define thresholds, and if they are crossed, the agent is stopped and requires human intervention to restart.

A simplified circuit breaker might look like this:

class CircuitBreaker:  
    def __init__(self):  
        self.thresholds = {  
            "max_actions_per_minute": 50,  
            "max_failed_actions": 5,  
            "max_api_cost_per_hour": 100.0,  
            "max_consecutive_anomalies": 3  
        }  
        self.state = "closed"  # closed = normal, open = breaker tripped  
        self.counters = {key: 0 for key in self.thresholds}  
      
    def check_and_update(self, metric: str, value: float) -> bool:  
        """Update counter and check if breaker should trip"""  
        if self.state == "open":  
            return False  # Agent already stopped  
          
        self.counters[metric] = value  
          
        if value > self.thresholds[metric]:  
            self.trip(f"{metric} exceeded: {value} > {self.thresholds[metric]}")  
            return False  
          
        return True  
      
    def trip(self, reason: str):  
        """Open circuit breaker and halt agent"""  
        self.state = "open"  
        print(f"🛑 CIRCUIT BREAKER TRIPPED: {reason}")  
        print("Agent execution halted. Human review required.")  
        # In production: alert on-call, log to incident system, etc.

Early detection prevents small misalignments from cascading. An agent optimizing metrics in slightly questionable ways will likely escalate if left unchecked. Circuit breakers interrupt that progression automatically, giving you time to investigate and correct before real damage occurs.

However, setting a threshold is a balancing act. Too sensitive and you are constantly chasing benign anomalies. Too loose and you miss genuine misalignment until it is serious. It is best to start conservatively and tune thresholds against your agent's actual operational patterns over time.

Guardrail Layer 3: Alignment-Preserving Architecture

Monitoring catches misalignment only after it appears. The stronger guardrail is designing your system so that misalignment is less likely to occur in the first place.

Human-in-the-loop (HITL) checkpoints

Not every action needs human review. Routine, reversible actions can run autonomously. But irreversible operations (deleting data, modifying production systems, initiating financial transactions) should always pause for confirmation. The cost of a one-second approval is almost always lower than the cost of undoing a mistake you did not anticipate.

Two questions determine where to draw this HITL line: how reversible is the action, and how confident is the agent in its reasoning? High reversibility and high confidence can run autonomously. Anything else should escalate.

Human checkpoints do more than catch mistakes. They create natural breakpoints for inspecting agent reasoning, catching goal drift early, and maintaining accountability for decisions made on behalf of your users.

Bounded autonomy patterns

Limit how far agents can operate independently before re-engaging a human. Three constraints worth building into your architecture:

Operational scope: Which actions the agent can perform without re-authorization
Time horizons: How long the agent can run before requiring check-ins
Decision depth: How many chained actions the agent can take in a single run

These boundaries ensure that the blast radius is limited if something goes wrong.

Balanced objectives

Single-metric optimization is one of the most common paths to misalignment. An agent told to "maximize user engagement" will find ways to do exactly that, including ways you never intended.

The fix is to give agents multiple objectives that create natural tension. Instead of "maximize user engagement", try "maximize user engagement while keeping response time under 200ms and error rates below 1%". The agent cannot optimize one metric at the expense of the others.

Approval workflows and Auth0 Asynchronous Authorization

A well-designed escalation policy turns human oversight from a bottleneck into a safety net. High-impact and high-uncertainty situations escalate. Low-impact and low-uncertainty situations run autonomously. Everything in between uses confidence thresholds or stake-based routing.

A customer service agent, for example, might handle routine queries autonomously but escalate refund requests over $100 or any action involving account-level changes, as illustrated in this workflow:

This flowchart shows a customer service agent workflow with escalation logic. When a query arrives, the AI agent first determines whether it can handle it autonomously. Routine queries are resolved automatically and a response is sent. For more complex cases, a decision matrix evaluates the stakes and confidence level: refunds over $100 are escalated to a human agent, low technical confidence routes the query to tech support, and signs of customer frustration trigger escalation to a supervisor. All paths conclude with a response being sent to the customer.

The practical challenge is its implementation. How does an agent pause mid-task and wait for a human response without blocking the entire system? This is exactly what Auth0's Asynchronous Authorization solves.

Built on Client-Initiated Backchannel Authorization (CIBA), Asynchronous Authorization is Auth0's production-ready pattern for asynchronous human-in-the-loop authorization. Here is how the flow works:

Initiation: The agent sends a CIBA request to Auth0's bc-authorize endpoint, including a user identifier and an optional authorization_details payload describing the action in plain, verifiable context.
Acknowledgment: Auth0 immediately returns a unique auth_req_id to the agent, confirming the request is in process.
Polling: The agent begins polling Auth0's token endpoint using the auth_req_id, waiting for a human decision without blocking anything else.
User consent: In parallel, Auth0 pushes a notification (mobile push, email, or Slack) to the user's device with the full action context. The user approves or denies on their own time, on their own device.
Token issuance: On approval, the next poll succeeds, and Auth0 returns the access and ID tokens the agent needs to complete the authorized action.

The sequence diagram above illustrates how Auth0's CIBA works within an AI agent workflow. The AI agent initiates the process by sending a backchannel authentication request to Auth0, which returns a request ID and pushes a notification to the designated human approver via mobile, email, or Slack. While the agent polls the token endpoint waiting for a decision, the approver reviews the context and either approves or denies the request. If approved, the agent proceeds with the action; if denied, it halts and logs the outcome.

The agent waits. Nothing else in your system is blocked. The human is not pulled into a synchronous interruption. And because the approval goes through Auth0, you get a full audit trail of every request, approval, and denial without building any of that infrastructure yourself.

This approach makes human-in-the-loop practical at scale. Escalation rules tell your agent when to ask for human oversight. CIBA handles how to ask in a way that actually works in production.

Architecture beats post-hoc fixes

These alignment-preserving architectural approaches treat agentic alignment as a design constraint rather than a monitoring problem. Building alignment into system architecture has a tradeoff: reduced autonomy. Your agent moves slower, and requires more human involvement. But for production systems where misalignment could cause real harm, this is the right tradeoff. You want agents that are reliably aligned, not maximally autonomous.

Continuous Evaluation

Here is how three guardrails prevent agentic misalignment:

This diagram shows how a three-layer guardrail system prevents agentic misalignment. When an agent proposes an action, it first passes through constitutional constraints, where any rule violation or blocked tool use stops the action immediately. Actions that pass move to behavioral monitoring, where anomalies or threshold breaches trip a circuit breaker. Actions exhibiting normal behavior reach the architecture design layer, where low-stakes actions meeting all constraints are executed directly, high-stakes actions require human approval before proceeding, and constraint violations are escalated for review. All outcomes, whether prevented, detected early, or approved and executed, feed into a safe operation state, with every executed action logged.

After implementing these three guardrails, you are ready to ship to production. But alignment requires ongoing work. As models get more capable and encounter new edge cases, new misalignment risks emerge. Yesterday's guardrails might not hold tomorrow, so verify them to ensure your agent remains aligned, especially as models and tools evolve.

Red-teaming your agents

Red-teaming your agents implies trying to break alignment deliberately, instead of waiting for misalignment to appear organically. Create a test suite to stress-test boundaries:

Goal conflicts: Give your agent an objective that conflicts with organizational policies.
Resource constraints: Limit access to preferred tools and see how it adapts.
Metric gaming opportunities: Present situations where gaming metrics are easier than genuine achievement.
Ethical dilemmas: Force choices between efficiency and safety.

Run these scenarios regularly, especially after model updates. Track how often your agent attempts problematic behaviors, even when guardrails block them. A rise in blocked attempts signals growing misalignment pressure worth investigating.

Transparent and auditable systems make alignment verification possible. Every agent decision should leave a trail: the reasoning chain, alternatives considered, constraints checked, and final action taken. This audit log helps you diagnose why misalignment occurred, supports compliance requirements, and lets you spot patterns across incidents before they compound.

In healthcare or finance, informal testing may not be enough. Formal verification of AI agents is still an active area of research and not yet practical to implement broadly, but it is worth watching closely if you operate in high-stakes domains.

Wrapping Up

AI is rapidly becoming as ubiquitous as electricity. However, the technology is advancing faster than our understanding of it. We are already building AI agents that can plan our vacations and book our flights quickly. But are they safe enough not to leak our financial information, or worse, not to misuse it themselves?

When developers only test the "happy path" and assume their agents will always stay on the ethical track, they are often being oblivious to the Pandora's box these AI systems could open unintentionally. As several real-life incidents have shown, an AI agent going rogue is no longer a hypothetical threat.

In medicine, doctors are guided by a foundational principle: "First, do no harm." AI development needs the same commitment. Innovation that comes at the expense of safety or ethics is not innovation worth shipping, no matter how often guardrails are dismissed as obstacles that slow things down. The three guardrails give you the building blocks to ensure your agents pursue the right goals, in the right ways, within boundaries that hold under pressure.

If you're looking to put these guardrails into practice, Auth0's Asynchronous Authorization and OpenFGA integrations give you production-ready building blocks for async human-in-the-loop authorization and relationship-based access control. Sign up for Auth0 for AI agents and start with the Auth0 for AI Agents docs.

"You Pressed Accept and Forgot About It." That's the Flaw.

Carla Urrea Stabile — Wed, 30 Sep 2026 15:30:00 +0000

If you've been building with AI agents, you've probably had this experience: the agent needs access to something, a browser popup appears, you glance at it for a second, and you click Allow without really reading it. As Miguel Pedregosa points out, this is a huge mistake that results in a security flaw. He's a Senior Software Engineer on the Protocols team at Auth0, the team that owns the identity standards implementation that millions of developers rely on without thinking about it.

The door you've opened without reading. Each browser auth flow you click through is a permission you approved without knowing what you approved, and those authorizations may be happening entirely outside your enterprise identity provider.
The protocol that replaces the popup. Cross-App Access routes agent authorization through your existing enterprise identity provider. The agent gets an access token through the back channel, with no browser required, and full audit visibility for IT.
Implementing a standard that's still being written. Miguel's team launched the Cross-App Access beta while the IETF spec was in draft. The spec shifted, they shifted with it, and ended up feeding back directly into the standard itself.
What enterprises ask for that nobody else thinks about. A startup asks "does it work?" An enterprise asks "does it work with our 40-year-old system?" That gap drives more of what the protocols team builds than anything else.
Threat modeling without reading an RFC. What can each part of my system access? How and when? If this agent hallucinates, does it have access to everything? Miguel says those three questions are enough to start.

Things that stuck with me

When you click “Allow” on five consecutive prompts without reading them, you're approving access you can't really explain, and depending on how the agent is set up, those authorizations may be happening outside the identity system your company manages.

I assumed implementing a standard meant reading a spec and building to it, but it turns out early drafts could have gaps, and companies implementing early get to flag them. Sometimes those flags become changes to the spec. Miguel described it as one of the more fun parts of the project, which surprised me, and it makes sense once you hear why.

The threat modeling advice works because it requires no identity expertise. Just map what your system can touch and ask what happens if part of it misbehaves. The answers are often straightforward, and the hard part is remembering to ask before you ship.

You're probably already building agents, so the question is whether the security is something you thought through or something you clicked past.

Have you ever looked back at an agent you shipped and realized it had more access than it needed? Let me know in the comments!

Listen to the full episode

Available on YouTube, Apple Podcasts, and Spotify.

Thanks for reading!