AI agents are moving into production fast. They call APIs, read databases, send mail and trigger workflows. In most setups they do this with a service account, a long-lived API key or a token copied from the developer who built them. There is no clear answer to who the agent is acting for, what it is allowed to do, or what it actually did.

This is an identity problem, and the IAM world has already started working on it. This talk walks through the building blocks: agent identity and workload identity, OAuth token exchange for delegation, ID-JAG (Identity Assertion Authorization Grant) for cross-domain access, the AAuth proposal for agent-specific authorization, and agent gateways as the place where policy is enforced and every call is logged.

We look at how these pieces fit together in a Java stack, where they overlap, and where the standards are still moving. Along the way we cover the questions to ask before an agent gets access to anything: which user or system it represents, how its permissions are scoped and expire, and how you trace an action back to a decision.

You leave with an overview of the concepts and specifications in use today. Some are still experimental at the time of writing; some may be finished RFCs by the time this talk is given. Either way, you will know what to look for and what to ask your vendors.

Participants understand why AI agents are a new class of identity and why service accounts and API keys are not enough. They know the main building blocks for agent access: workload identity, OAuth token exchange, ID-JAG, the AAuth proposal and agent gateways, and how these fit into a Java stack. They can judge which parts are stable and which are still experimental, and know which questions to ask before an agent gets access to a system: who it acts for, what it may do, and how to trace it.