Every time a new IAM vendor promises to “solve” agentic identity by adding a feature to their platform, ask one question: what is their backend?

If the answer involves LDAP or a relational database as the primary identity store — and for the vast majority of platforms it does — then the feature is a facade built on a foundation that was designed before the concept of an AI agent existed.

This post is a technical examination of why the IAM backend stack — the LDAP directories and SQL schemas that underpin most of the market — creates structural friction for agentic identity management, and what a purpose-built modern backend looks like.

This post is a companion to Three Generations of IAM Tools — and Why None of Them Were Built for the Agentic Era.

Why the Backend Matters More Than the Frontend

When organisations evaluate IAM platforms, they assess dashboards, certification workflows, connector counts, and AI feature announcements. The backend data architecture rarely appears in an RFP.

This is a mistake.

The backend determines:

  • How fast access decisions can be computed at runtime
  • Whether delegation chains can be traversed efficiently
  • Whether ephemeral identities can be created, used, and destroyed at machine speed
  • Whether policy can be enforced without a human in the loop

A modern UI bolted onto a 1990s data model is still a 1990s data model. And the data models at the core of most enterprise IAM deployments are, in substance, 1990s designs.

The LDAP Problem

What LDAP Was Designed to Do

LDAP — Lightweight Directory Access Protocol — descends from the X.500 directory standard developed in the 1980s. It was designed to answer one question efficiently:

“Given a username, return the attributes associated with this entry so I can authenticate and determine group membership.”

That is the entirety of the use case LDAP optimises for. It is a read-heavy, hierarchical, attribute-lookup system.

flowchart TD
    A[Client: Who is jsmith?] --> B[LDAP Query:\ncn=jsmith,ou=users,dc=acme,dc=com]
    B --> C[Directory Response:\nmail: jsmith@acme.com\nmemberOf: cn=finance,ou=groups\nmemberOf: cn=vpn-users,ou=groups]
    C --> D[Access decision based\non group membership]

    style A fill:#1e3a5f,stroke:#3b82f6,color:#fff
    style D fill:#1e4620,stroke:#22c55e,color:#fff

For this use case — a human employee authenticating to a corporate application — LDAP is adequate. Millions of enterprise deployments prove it.

Where LDAP Breaks for Agentic Identity

The assumptions baked into LDAP’s design directly contradict what agentic identity demands.

flowchart LR
    subgraph LDAP["LDAP Design Assumptions"]
        direction TB
        L1[Long-lived records\nchanged rarely]
        L2[Hierarchical tree\ncn=user,ou=dept,dc=org]
        L3[Static attributes\nnot time-bounded]
        L4[Synchronous lookup\nresult is current state]
        L5[No concept of\neffective permissions]
    end

    subgraph Agent["Agentic Identity Requirements"]
        direction TB
        A1[Ephemeral identities\ncreated and destroyed in minutes]
        A2[Graph relationships\ndelegation chains, cross-org trust]
        A3[Time-bounded metadata\nTTL, execution count, scope]
        A4[Real-time policy\nbehavioural signals + context]
        A5[Effective permission\ncomputation across delegation chain]
    end

    L1 -.-|"<b>conflict</b>"| A1
    L2 -.-|"<b>conflict</b>"| A2
    L3 -.-|"<b>conflict</b>"| A3
    L4 -.-|"<b>conflict</b>"| A4
    L5 -.-|"<b>conflict</b>"| A5

    style LDAP fill:#4a1a1a,stroke:#ef4444,color:#fff
    style Agent fill:#1e3a5f,stroke:#3b82f6,color:#fff

Friction Point 1 — High-frequency writes

LDAP is architected for infrequent writes. Directory replicas synchronise asynchronously; write amplification across replicas adds latency. In an agentic world, creating and destroying agent identities at the rate of thousands per hour is a required capability. LDAP backends under this write load become a bottleneck and a source of replication inconsistency.

Friction Point 2 — Hierarchical tree cannot represent delegation graphs

An LDAP Distinguished Name (DN) like cn=agent-abc,ou=ai-agents,dc=acme,dc=com encodes a static position in a tree. But Agent A delegating to Agent B, which delegates to Agent C — each with progressively narrowed scope — is a directed graph, not a tree position. There is no native LDAP mechanism to express “this agent’s authority is derived from, and bounded by, that agent’s authority.”

Friction Point 3 — No time-bounded attributes as a first-class concept

LDAP attributes are static records. Expressing “this agent credential is valid for 15 minutes and can only make 5 API calls” requires custom schema extensions or external systems. These constraints live outside LDAP, in token metadata — which means the directory is no longer the authoritative source of truth for access rights.

Friction Point 4 — Context-free lookups

LDAP returns attributes. It does not evaluate policy. It cannot say “deny this agent access because its IP is anomalous, even though the group membership would normally allow it.” This context-sensitivity is essential for agentic access control, and it requires a policy engine layer that sits entirely outside LDAP.

The SQL Problem

What Relational Schemas Were Designed to Do

The SQL identity store in most IGA platforms was designed to answer lifecycle governance questions:

  • Who has access to what, right now?
  • Was this access approved?
  • When should it expire?
  • Has it been reviewed recently?

The schema looks something like this:

erDiagram
    IDENTITY {
        string id PK
        string displayName
        string hrStatus
        string managerID
    }
    ROLE {
        string id PK
        string name
        string appID
    }
    ASSIGNMENT {
        string identityID FK
        string roleID FK
        date approvedDate
        date reviewDate
        string approverID
    }
    ENTITLEMENT {
        string id PK
        string roleID FK
        string resource
        string action
    }

    IDENTITY ||--o{ ASSIGNMENT : "<b>has</b>"
    ROLE ||--o{ ASSIGNMENT : "<b>assigned via</b>"
    ROLE ||--o{ ENTITLEMENT : "<b>grants</b>"

This schema is correct for its intended purpose. It accurately represents stable, human-centric access relationships that change through defined lifecycle events.

Where SQL Breaks for Agentic Identity

Problem 1 — Volume × Complexity = Performance Collapse

At a 90:1 NHI-to-human ratio, an enterprise with 50,000 employees has 4.5 million NHIs. Running a SoD analysis, a certification campaign, or a blast-radius query across that population using relational joins is not just slow — it is architecturally incoherent. These operations require full table scans or multi-hop joins that relational optimisers were not designed to handle at this scale.

Veza’s Access Graph manages over 30 billion permission relationships. There is no SQL schema that efficiently stores and traverses 30 billion rows for graph-pattern queries.

Problem 2 — State vs. Event: The Wrong Paradigm

A relational identity store models current state: who has what access, right now. But agentic access is fundamentally event-driven:

  • An agent is instantiated
  • It requests a credential with a specific scope
  • It uses that credential to access Resource X
  • It delegates a sub-scope to Agent B
  • It expires

None of these events are well-represented in a state table. The governance question for agentic identity is not “what role does this agent have?” but “what did this agent do, to what resources, under what delegated authority, and what was the delegation chain?”

That is an audit and provenance question, which requires event sourcing — an append-only log of identity events — not a state table with last_modified columns.

Problem 3 — The Ephemeral Identity Anti-Pattern

SQL schemas are optimised for stable records. Creating and deleting records at high frequency causes:

  • Table fragmentation and index bloat
  • Lock contention under high write concurrency
  • Audit log growth that quickly becomes unmanageable

Attempting to represent AI agent identities in a traditional IGA SQL schema treats what should be a token with embedded metadata as a record with a lifecycle — and the mismatch creates operational pain at every layer.

The Four Bottlenecks Together

%%{init: { 'themeVariables': { 'lineColor': '#64748b' } } }%%
flowchart TD
    %% TIER 1: SOURCE OF TRUTH (LEGACY)
    subgraph Legacy["Legacy Tier (Sources of Truth)"]
        direction LR
        LDAP[LDAP / Active Directory<br><i>Human Identity Master</i>]
        SQL[SQL / IGA Database<br><i>Governance & Certifications</i>]
    end

    %% TIER 2: INGESTION & PIPELINE (MODERN INTERNALS)
    subgraph Modern["Modern IAM Platform Stack"]
        direction TB
        
        subgraph Pipeline["1. Ingestion & Streaming"]
            E[Event Stream<br><b>Kafka / EventBridge</b><br>Identity Event Log]
        end

        subgraph CoreState["2. Relationship & History Engine"]
            G[Graph Database<br><b>Neo4j / Neptune</b><br>Real-time Graph State]
            A[Audit Store<br><b>Immutable Ledger</b><br>Queryable History]
        end

        subgraph Runtime["3. Runtime Authorization Engine"]
            T[Token Service<br><b>JWT / Biscuit / SPIFFE</b><br>Short-lived Context]
            P[Policy Engine<br><b>OPA / Cedar</b><br>Policy Evaluation]
        end
    end

    %% TIER 4: OUTPUT/DECISION SPLIT
    OUT[<b>Access Decision</b>]
    PERMIT[<b>Permit</b>]
    DENY[<b>Deny</b>]

    %% CROSS-TIER CONNECTORS (Pipelines)
    LDAP -.->|CDC Sync| E
    SQL -.->|Batch Ingest| G

    %% INTERNAL PLATFORM CONNECTORS
    E -->|<b>Hydrate / Update</b>| G
    E -->|<b>Stream Archives</b>| A
    
    G -->|<b>Graph Context</b>| P
    T -->|<b>Ephemeral Claims</b>| P
    
    P --> OUT
    OUT --> PERMIT
    OUT --> DENY

    %% STYLING
    style Legacy fill:#2a1f1f,stroke:#ef4444,stroke-width:2px,color:#fff
    style Modern fill:#0899,stroke:#3b82f6,stroke-width:2px,color:#fff
    
    style Pipeline fill:#1e293b,stroke:#475569,color:#fff
    style CoreState fill:#1e293b,stroke:#475569,color:#fff
    style Runtime fill:#1e293b,stroke:#475569,color:#fff
    
    style OUT fill:#1e293b,stroke:#94a3b8,stroke-width:3px,color:#f1f5f9

    %% NATIVE CLASS DEFINITIONS FOR THE DECISIONS
    classDef permitClass fill:#1e4620,stroke:#22c55e,stroke-width:2px,color:#4ade80;
    classDef denyClass fill:#7f1d1d,stroke:#ef4444,stroke-width:2px,color:#f87171;

    class PERMIT permitClass;
    class DENY denyClass;

The Graph Database

The core of a modern IAM backend is a graph database — Neo4j, TigerGraph, or Amazon Neptune are the most enterprise-viable options. Access relationships are stored as edges between nodes (identities, resources, roles, policies), enabling:

  • Sub-second traversal of delegation chains regardless of depth
  • Blast-radius queries: “if Agent X is compromised, what can it reach?”
  • Path analysis: “show every route from Identity Y to Production Database Z”
  • Efficient queries at billions-of-edges scale that would take minutes in SQL

Veza’s Access Graph is the commercially proven implementation of this approach. The graph is not a replacement for SQL — it is the right data structure for permission relationships, with SQL remaining appropriate for compliance records.

Event-Sourced Identity Log

Identity state should be derived from an immutable event log. Every grant, revocation, delegation, credential issuance, and expiry is an event appended to a stream (Kafka, EventBridge, or a purpose-built event store).

Benefits:

  • Full provenance: reconstruct the exact permission state of any agent at any point in time
  • Audit by default: no separate audit table needed; the event log is the audit trail
  • Point-in-time queries: “what could Agent X access at 14:32 on Tuesday?”
  • Replay for forensics: reconstruct an incident’s full access trajectory

This is the correct answer to the OpenID Foundation’s identified gap around closing the auditability gap — the current inability to distinguish agent-performed actions from user-performed actions in audit logs.

Policy-as-Code Engine

Policy evaluation must be decoupled from the identity store and executed in real time. The two leading options are:

Engine Language Best For
OPA (Open Policy Agent) Rego Cloud-native, Kubernetes-native, flexible
Amazon Cedar Cedar AWS-native, formally verified, high-performance

The pattern follows the OpenID Foundation’s recommended PEP/PDP separation (Policy Enforcement Point / Policy Decision Point from NIST SP 800-162):

  • The PEP intercepts the agent’s access request (API gateway, service mesh, SDK)
  • The PDP evaluates the policy against current context: agent identity, delegation chain, resource sensitivity, time, behavioural risk score
  • The decision is returned in milliseconds, not seconds

Legacy IGA platforms with nightly batch certification runs are not policy engines. They are audit tools pretending to be enforcement tools.

Short-Lived Token Service

Agent credentials should be short-lived tokens with embedded constraints, not long-lived secrets stored in LDAP or SQL records.

The options:

  • JWT (JSON Web Token) with short TTL — the current standard; widely supported
  • SPIFFE SVIDs — cryptographically verifiable workload identity; suitable for infrastructure-level agent identity
  • Biscuits / Macaroons — enable offline scope attenuation; allow an agent to generate a more restricted sub-token for its sub-agents without a round-trip to the authorization server

This last point directly addresses the OpenID Foundation’s identified gap around recursive delegation — scope attenuation where permissions provably narrow at each delegation hop.

The Migration Reality

Replacing LDAP and SQL entirely is a multi-year program for most enterprises. The pragmatic path is layered augmentation:

%%{init: { 'themeVariables': { 'lineColor': '#64748b' } } }%%
flowchart TD
    %% CENTRAL SPINE (PHASES)
    Phase1[<b>Phase 1</b><br>Audit]
    Phase2[<b>Phase 2</b><br>Graph Layer]
    Phase3[<b>Phase 3</b><br>Policy Engine]
    Phase4[<b>Phase 4</b><br>Event Sourcing]
    Phase5[<b>Phase 5</b><br>Legacy Decommission]

    %% HIERARCHICAL BRANCHES
    N1[Inventory all NHIs<br>Map current LDAP/SQL<br>Identify gaps]
    N2[Deploy graph DB alongside<br>Sync from LDAP/SQL<br>Enable blast-radius queries]
    N3[Implement OPA/Cedar<br>Replace batch-mode policy<br>Real-time decisions for agents]
    N4[Introduce event stream<br>Audit log migration<br>Point-in-time provenance]
    N5[Migrate human identities<br>Decommission legacy directory<br>Full modern stack]

    %% LINKING THE SPINE (Top to Bottom)
    Phase1 --> Phase2
    Phase2 --> Phase3
    Phase3 --> Phase4
    Phase4 --> Phase5

    %% LINKING THE HIERARCHICAL DETAILS (Side-branching)
    Phase1 -.-> N1
    Phase2 -.-> N2
    Phase3 -.-> N3
    Phase4 -.-> N4
    Phase5 -.-> N5

    %% GLOBAL STYLING
    classDef phaseBox fill:#1e293b,stroke:#475569,stroke-width:2px,color:#fff;
    classDef detailBox fill:#1e293b,stroke:#64748b,stroke-width:1px,color:#e2e8f0;
    
    class Phase1,Phase2,Phase3,Phase4,Phase5 phaseBox;
    class N1,N2,N3,N4,N5 detailBox;

    %% HIGHLIGHTING START AND FINISH
    style Phase1 fill:#1e3a5f,stroke:#3b82f6,color:#fff
    style Phase5 fill:#14532d,stroke:#16a34a,color:#fff

Most organisations will complete Phases 1–3 within a 2-year window. Phase 4 requires organisational maturity around event-driven architecture. Phase 5 is a 5–7 year horizon for most large enterprises.

The key insight: you do not need to decommission LDAP to start getting agentic identity right. Deploying a graph layer that reads from LDAP and SQL — while adding the event stream and policy engine — provides the capabilities that matter for agents, without requiring a rip-and-replace of the human identity infrastructure.

Key Takeaways

  • LDAP was designed in the 1980s for read-heavy, hierarchical, attribute-lookup of human directory entries. It is structurally incompatible with ephemeral agent identities, delegation graphs, and time-bounded credentials.

  • SQL schemas model identity state accurately but fail at NHI volume, graph-pattern queries, and the event-sourced access patterns that agentic provenance requires.

  • The combination of LDAP + SQL + batch-mode policy + human approval workflows creates four compounding bottlenecks. The practical result is either blocked agent operations or developer bypasses (hardcoded secrets).

  • A modern IAM backend requires: a graph database for permission relationships, an event-sourced identity log for provenance, a real-time policy engine (OPA/Cedar) for access decisions, and a short-lived token service with scope attenuation support.

  • Migration is layered, not rip-and-replace. Deploy the graph and policy layers alongside existing LDAP/SQL infrastructure first. This unlocks agentic identity capabilities without destabilising the human identity foundation.

  • The vendors who get this right — Veza/ServiceNow’s Access Graph being the most commercially advanced example — built graph-native from day one. Gen2 platforms adding agentic features on LDAP/SQL foundations are solving the wrong layer.

Part of the IAM for the Agentic Era series.