Video summary

Identity and Access Management for the Decade Ahead - Thivaharan Kalyanasundaram, WSO2

Main summary

Key takeaways

Technology

Tech focus: IAM “for the decade ahead” (WSO2 / Thunder ID)

The talk argues that modern IAM is being reshaped by two major shifts:

  1. Identity has outgrown humans Non-human entities (services, workloads, and especially autonomous AI agents) now dominate identity counts and often carry excess privileges. Many security/privacy incidents stem from agent misconfiguration or missing IAM controls for agents.

  2. Trust has outgrown the provider The traditional central identity provider + federation model is increasingly limited by scalability/privacy concerns and by the need for partner pre-registration and trust relationships.

Core IAM concept: manage AI agents as “first-class identities”

A key recommendation is that agents should not be forced into existing identity constructs (users/applications/service accounts) because agent behavior differs fundamentally.

What makes an AI agent identity different (4 characteristics)

Agents are autonomous software entities that:

  • run autonomously
  • operate with varying degrees of human oversight
  • can use external tools (APIs, databases, etc.)
  • have memory/context and can do multi-step reasoning, including delegation to sub-agents

Because agents can delegate and act unpredictably, the identity model must include accountability, boundaries, delegation chains, and full lifecycle governance.

Must-haves for agent identity

  • Independent accountability tied to a liable owner entity
  • Granular permissions/boundaries for what the agent can do alone vs on behalf of someone
  • Governed lifecycle (commission/decommission/state management)
  • Delegation transfers captured explicitly (including chains to sub-agents and/or users)
  • Auditability for every allowed task/action, including invoked tokens/calls

The 4A framework (Admin / Authenticate / Authorize / Audit)

The talk presents an IAM workflow tailored for agents:

  1. Administer

    • Give each agent a unique identifiable credential
    • Perform life cycle governance and link to a liable owner

  2. Authenticate

    • Provide credentials the agent uses to prove identity
    • Ranges from client_id/client_secret to cryptographic attestations

  3. Authorize

    • Determine what the agent can do using existing access control models such as:
      • RBAC
      • ABAC
    • Authorization differs for:
      • agent acting on its own
      • agent acting on behalf of another user/agent

  4. Audit (often missed but critical)

    • Because agents do complex, multi-step tasks, you need detailed auditing:
      • what tasks were allowed/performed
      • who invoked the agent
      • what circumstances/scopes applied
      • token calls and external access requests

Practical deployment scenario: enterprise agentic systems

A typical deployment is described as:

  • Initiators (users, apps, schedulers, other agents) invoking the agent
  • The agent connected to an LLM (“brain”)
  • Agents delegating/spawning sub-agents
  • Agents accessing tools/external services both inside and outside trust boundaries

The talk emphasizes each connection as an attack surface, especially given agent unpredictability.

Live-use-case demo: “Wayfinder” flight booking agent with Thunder ID

Example flow:

  • Wayfinder app embeds an agent that can search flights using its own permissions.
  • When asked to book flights on behalf of a user, the agent needs delegated permissions:
    • the user consents
    • auditing captures subject=user and actor=agent
  • If the agent is asked to do something outside consent, it fails because the obtained token lacks required scopes.

How Thunder ID implements it (grounded in OAuth/OIDC)

The speaker clarifies the agent approach is not proprietary-only:

  • Autonomous behavior: uses OAuth client credentials grant to obtain an M2M token
  • On-behalf-of user: uses authorization code grant with user consent
  • Additional grants mentioned:
    • CIBA (client initiated back-channel authentication) for background agents needing dynamic permission requests during long-running tasks
    • token exchange grant for downscoping permissions per agent as needed
  • Mentions identity/lifecycle tooling:
    • SCIM for managing agent lifecycle, plus upcoming agent-specific SCIM extensions
  • Mentions agent/tool communication protocols:
    • MCP (tool access)
    • A2A (agent-to-agent communication/delegation)

Second problem & solution: trust outside the single org (decentralized identity)

Why federation breaks down

The current “central identity provider + federation” model:

  • makes the identity provider see/mediate every login
  • leaks privacy/attributes across all federation parties
  • requires pre-negotiated trust and pre-registered identity providers for federation partners

Decentralized identity + verifiable credentials (VCs)

The proposed inversion:

  • no central authority brokers identity
  • issuer → issues verifiable credentials (VCs)
  • holder (user/agent) stores them in a wallet
  • holder selectively discloses only necessary attributes to a verifier (relying party)

In the Wayfinder example:

  • Wayfinder acts as issuer, signs a VC for the agent containing attributes like:
    • agent allowed actions/characteristics
    • billing clearance
    • owner/validity details
  • The agent presents a self-contained proof using selectively disclosed fields to partners.
  • The external organization verifies the VC signature via a decentralized identifier (DID) referenced by the issuer.

This avoids centralized login/federation and avoids exposing internal configs/owner identity unless needed.

“Converged identity platforms” and Thunder ID product pillars

The speaker argues the agent identity problem and decentralized trust are connected and should be handled in a single converged identity core managing primitives like:

  • identifiers
  • credentials
  • entitlements/claims
  • audit records

They connect to broader IAM concerns:

  • post-quantum readiness (crypto-agile, PQ-safe)
  • zero trust access (real-time verification + audit based on context)
  • identity governance (joiner/mover/leaver lifecycle)
  • privileged access management (contextual, just-in-time rights)
  • directory/data source integration (merging/central management when needed)

They reference Gartner terminology: converged identity platforms.

Thunder ID’s four pillars (as described)

  1. Agent-native

    • manage agents as first-class identities
    • support delegation, consent, and traceability

  2. Decentralized identity first-class

    • issue/verify verifiable credentials
    • integrate with wallets and trust registries to bridge relying parties

  3. Cloud native

    • lightweight
    • supports containers/runtime and declarative configs
    • supports GitOps-style deployment via declarative configurations

  4. Post-quantum safe

    • uses hybrid / PQ-safe algorithms
    • “crypto agile” design from the core (crypto agility highlighted repeatedly)

Also noted:

  • Thunder ID is fully open source
  • Thunder ID will be contributed to the Open Wallet Foundation (near-final; hosted at Linux Foundation EU)

Q&A highlights (tokens, observability, compliance)

  • Thunder ID role: can act as a stand-alone issuer and stand-alone verifier (not only an IdP).
  • Token structure: standard-based; mentions JWT, with standard actor/subject claims.
  • Observability & control:
    • logs token calls and relevant interactions
    • mentions token revocation as part of enforcement/observability
    • supports publishing audit logs via connectors/events into existing logging frameworks (filtering by tasks/severity)
  • Scopes/roles model:
    • agent roles/scopes are scoped to the agent, not directly to the owning user
    • agents can get M2M tokens via client credentials when acting autonomously
  • Post-quantum:
    • algorithms chosen for PQ readiness “from day one,” with hybrid transitions
    • token encryption/signing may be configurable depending on use case (signed vs encrypted; KWS token mentioned)
  • JIT elevation / tool access:
    • tools/resources modeled as resources
    • dynamic consent mechanisms like CIBA-style back-channel requests enable just-in-time permission elevation for long-running agents

Main speaker(s) / sources

  • Thivaharan Kalyanasundaram / Divakaran Kalyanasundaram, Software Engineer at WSO2; maintainer of Thunder ID
  • Product/context references:
    • Thunder ID
    • standards/protocols: OAuth 2.0, OIDC, CIBA, SCIM, MCP, A2A, DIDs, Verifiable Credentials, Open Wallet Foundation
  • Industry concept citation: Gartner (converged identity platforms)

Original video