Why governing AI agents starts with the identities and permissions they inherit.
Every AI agent action has three layers: the Bot, the Launcher and the Target. That is the BLT problem of agent access (see what we did there?). The BLT problem (Bot, Launcher, Target) is a useful frame for what makes agentic access hard. But it understates where most teams are actually exposed right now.
If agent deployments have access controls in place, they are typically live at the MCP layer: they filter which tools the agent can call, maybe which resources it can name. What they critically miss is the entitlement underneath, the shared service account or delegated human permissions the agent actually uses to act. There is no context about who triggered the session or the business intent for the task at hand. It just has access, usually far more and long lasting than any single job requires.
You cannot govern the agent without understanding who or what invoked it and what system it is trying to access.
When those identity layers carry standing privilege, stale access or poorly scoped credentials, the agent inherits a bad baseline, and no tool-level filter catches the gap. This 30-minute session covers why controlling what an agent can call is not the same as controlling what it can do, and how just-in-time access and Zero Standing Privilege give you a model where the credential itself enforces the grant.