Agent Can’t Do That

When AI agents have continuous access, irreversible actions lack enforcement boundaries. This system uses Auth0 to ensure execution only happens when explicit runtime approval exists.

Comment

Inspiration

An AI agent recently wiped out years of production data.

It didn’t malfunction. It didn’t hallucinate.
It executed exactly what it was allowed to do.

That is the failure mode this project addresses.

Today, most agent systems tie an agent’s capability directly to the access it is given.

When access is persistent, irreversible actions have no boundary at the moment they execute.

This project implements a different approach:

Authorization depends on the action being executed and the moment it runs.

Authorization is not stored.
It is created only when an action needs to run.

What it does

This system demonstrates a production-style agent workflow for enterprise customer offboarding, executed in a controlled environment.

Workflow Entry Control

Before anything runs:

  • The operations manager must approve the workflow start
  • Without that approval, the agent cannot execute any step

Autonomous Execution (Low-Risk)

Once approved, the agent executes routine steps automatically:

  • Revoke access
  • Export billing data
  • Cancel subscriptions

These actions execute automatically without additional approval.

High-Risk Execution Boundary

When the agent reaches irreversible actions:

  • Issue refund
  • Delete customer data

Execution is blocked by default.

Each action requires:

  • Role-specific approval
    • CFO -> refund
    • DPO -> data deletion
  • A single-use authorization
  • Immediate consumption after execution

A refund approval cannot be reused for deletion.

Enforcement Model

Each action is validated at execution time.

Request -> 403 (Blocked Before Execution)

How I built it

The system orchestrates a structured workflow where every execution step is validated at runtime.

Auth0 for AI Agents

  • CIBA -> handles human approval (out-of-band)
  • Token Vault -> provides execution credentials only at runtime

CIBA handles approval.
Token Vault enables execution.

Workflow Engine

  • Temporal
    • Durable execution
    • Handles async approval delays
    • Maintains workflow state

Backend

  • NestJS
    • Enforces authorization checks at every step
    • Rejects execution if authorization is missing

Frontend

  • Next.js console
    • Displays live execution
    • Surfaces approvals
    • Reflects backend state, not enforcement

Data Layer

  • PostgreSQL
    • Append-only authority ledger

Issued -> Claimed -> Consumed

  • Prevents reuse and replay

Execution Model

  • Credentials are issued only at execution time
  • Not reusable
  • Not carried forward

Access exists only at the moment it is required for execution

Challenges I ran into

  • Enforcing authorization at workflow start, not just execution
  • Ensuring enforcement happens in the backend, not UI
  • Managing one-time authorization lifecycles without race conditions
  • Handling asynchronous Auth0 CIBA approval delays using Temporal
  • Preventing reuse or carry-forward of approvals
  • Making execution observable and verifiable in real time

Accomplishments that I'm proud of

  • Every 403 is a real backend rejection, not a UI simulation verifiable during execution
  • Authorization enforced at workflow initiation and per-action execution
  • Implemented per-action, single-use authorization using Auth0 CIBA
  • Used Token Vault for runtime-only credential issuance
  • Prevented authority reuse across independent actions
  • Built an append-only ledger reflecting actual system decisions

What I learned

Building this system made one thing clear:

Authorization becomes unsafe when treated as persistent state.

The challenge was designing a lifecycle where authorization:

  • cannot be reused
  • cannot be forwarded
  • cannot be implicitly assumed

This applies to both execution steps and workflow initiation.

What's next for Agent Can’t Do That

  • Package this as a reusable authorization layer for agent frameworks
  • Extend to multi-agent systems with shared workflows
  • Add stronger guarantees around audit integrity and non-repudiation
  • Explore policy-driven classification of reversible vs irreversible actions
  • Expand integrations beyond the demo workflow

Bonus Blog Post

Read the full blog here:
👉 https://medium.com/@gawalishivam5/securing-autonomous-ai-with-runtime-authorization-using-auth0-ec6387570f15

While building this system, the hardest part was not integrating Auth0 it was designing how and when authorization should exist.

Most systems treat access as something that is granted once and reused. That approach breaks down when agents are allowed to execute irreversible actions.

Using Auth0, I separated approval from execution.

  • Auth0 CIBA handles human approval
  • Auth0 Token Vault provides credentials only at execution time

Each authorization is tied to a single action, validated at execution, and removed immediately after use.

The agent can plan freely, but execution is always constrained by backend-enforced authorization.

This pattern applies to financial operations, sensitive data handling, and infrastructure control.

Built With

Share this project:

Updates