Episode 201 - GluuFederation/identerati-office-hours GitHub Wiki
Title: AI Agents Need Intent, Not Roles: Introducing IBAC
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Yash Prakash
Channels
Description
AI agents are non-deterministic, often taking actions unpredictable at provisioning time. Traditional models (RBAC, ABAC) confirm identity, but they can't validate purpose.
Intent-Based Access Control (IBAC) closes this gap. By requiring agents to justify every tool call, IBAC uses embeddings and anomaly detection to score alignment against system-defined intent. In this session, we’ll demonstrate how IBAC creates a hard authorization boundary at the tool level. We will explore how IETF transaction tokens propagate context across multi-hop chains and how behavioral signals—like tool sequence analysis—can neutralize prompt injections. Join us to discuss the future of autonomous agent authorization.
Homework
- IBAC specification and paper
- Reva blog: Intent‑Based Access Control: A Technical Primer by Ken Huang
Takeaways
-
⚡ Agents need runtime authorization, not static roles or permissions. Ephemeral agents and sub-agents make traditional provisioning, privilege certification, and role assignment difficult to scale. The better model is zero standing privilege: authorize a specific action against a specific resource at runtime, and certify the governing policies rather than every agent.
-
⚡ Prompt-injection security should focus on containing actions, not perfect detection. An agent may still be manipulated, but preventive authorization controls can stop it from executing actions that do not align with the user’s original intent. This is effectively a “right of the LLM” control: default-deny execution and narrowly authorize permitted capabilities.
-
⚡ A capability is fundamentally an action-resource combination. Natural-language intent is decomposed into capabilities describing what action may be performed against which resource. Agent skills, metadata, historical behavior, runtime context, and the invoking user’s delegated authority all help determine whether the action maps back to the original request.
-
⚡ Human consent should be risk-triggered, not requested for every action. Policy as code should automate normal decisions and bring in a human only when intent drifts, behavior becomes anomalous, a destructive action is attempted, or a resource-specific risk threshold is crossed. The decision model therefore needs more than allow or deny—it should also support defer, monitor, and escalate.
-
⚡ IBAC should be authorization-engine agnostic and combine deterministic policy with behavioral risk. The described architecture uses tuples and graph technology, but it is not limited to OpenFGA; it can also support Cedar and OPA. A central control plane evaluates enterprise policies, intent and behavioral drift, prompt-injection signals, resource sensitivity, and contextual risk before allowing, denying, or escalating an action.