← home

Execution-Centric Authorization: Why Least Privilege Must Be Derived from Execution in Agentic Systems

January 24, 2026

Traditional IAM assumes permissions can be assigned upfront.

That assumption quietly breaks with AI agents.

In the human world, access control works because identities are stable and workflows are predictable. Users are onboarded, roles are defined, permissions are granted, and execution follows.

AI agents invert this model.

They are autonomous, long-running, and adaptive mid-execution. They reason, act, observe results, and replan — often across multiple systems — before the full shape of execution is even visible.

This is why least privilege for AI agents is no longer a provisioning problem. It must be derived from execution and enforced at runtime.

From Identity-Centric to Execution-Centric Authorization

The traditional model looks like this: 

Identity → Registration → Role → Permissions → Delegation → Execution

This model assumes:

  • permissions can be enumerated in advance
  • execution paths are known
  • delegation is static and safe

Agentic systems break all three.

The agentic model looks fundamentally different: 

Intent → Execution Graph → Minimal Required Permissions → Enforced Action

Permissions are no longer inputs to execution. They are derived outputs of execution.

I think of this shift as Execution-Centric Authorization: access is mechanically derived from what the system is executing right now, not statically assigned based on identity or role.

Why Delegated Permissions Fail for Agents

Most enterprises today secure agents through delegated permissions: OAuth scopes, service accounts, or impersonation tokens granted upfront.

This creates an unavoidable tradeoff:

  • Constrain delegation → agents stall, replan endlessly, or fail to deliver value
  • Broaden delegation → agents become over-privileged, expanding blast radius

This is not a tuning issue. It's a structural IAM mismatch caused by static delegation in a dynamic execution model.

This problem is amplified when agents operate partially or entirely outside enterprise trust boundaries.

Long-running agents do not execute fixed workflows. They discover execution paths dynamically:

  • plans branch at runtime
  • tool calls depend on intermediate results
  • cross-system access emerges late in execution

Static delegation assumes we can predict access before execution. Agents reveal required access during execution.

The question:

"How much access should this agent have?"

is the wrong control question.

The correct one is:

What access does this execution require right now?

A Concrete Example

Imagine an agent tasked with: "Prepare the QBR for Acme Corp."

At runtime, the agent discovers it needs:

  • read access to CRM data
  • temporary read access to support tickets
  • write access to a shared slide deck
  • short-lived access to revenue metrics

None of this is knowable at onboarding time. All of it must be constrained during execution.

Granting all of this upfront over-privileges the agent. Restricting it upfront breaks the task.

Only runtime-derived permissions resolve this tension.

Why Execution Graphs Are Hard — and Unavoidable

Least privilege depends on knowing what will be executed.

In agentic systems, that information exists only as an execution graph — and extracting it is hard because execution itself is emergent.

Execution graphs are difficult to capture because:

  • planning and execution are interleaved
  • tool calls are data-dependent
  • cross-system fan-out is dynamic
  • LLMs are not reliable narrators of intent
  • execution mutates over time
  • execution spans trust boundaries

Agents often run across a trust spectrum — from first-party code to third-party or vendor-managed runtimes — reducing observability and control.

From an IAM perspective, this breaks every assumption behind static permission assignment.

But despite the difficulty, execution graphs are the only sound input from which least privilege can be derived.

Without them:

  • permissions must be guessed
  • delegation must be over-broad
  • blast radius is unknowable
  • audit trails are meaningless

Execution-graph extraction isn't an optimization. It's a prerequisite for least privilege in autonomous systems.

What the Agentic Model Requires

Instead of delegating static capability sets, an execution-centric system must:

  • reconstruct permission hierarchies
  • compute the minimal scope set that satisfies the execution graph
  • enforce permissions mechanically, per action, per session, and per trust boundary

    • This moves least privilege from: 

    identity → policy → hope

    to: 

    execution → derivation → enforcement

    Six Requirements for Execution-Centric Authorization

    Once authorization becomes execution-centric, least privilege stops being a guideline and becomes a set of hard requirements:

  • Minimal scope + temporal bounds — Permissions apply only to the current task and expire when it ends.
  • Explicit intent — Every permission must be bound to a declared purpose.
  • Monotonic attenuation — Delegation can only reduce authority, never expand it.
  • Auditable provenance — Every action must have a complete chain of custody.
  • Non-bypassable enforcement — Controls must live at the infrastructure boundary, not in application code.

    • Taken together, these requirements imply a deeper shift:

    Least privilege for agents is not about assigning permissions. It's about deriving and enforcing permissions from execution.

    The Real Takeaway for IAM and Security Teams

    AI agents aren't breaking security models. They're exposing where those models were never designed to reason about execution.

    Least privilege for agents is:

    • not a policy problem
    • not an onboarding problem
    • not primarily an identity problem

    It's a runtime execution-control problem where permissions must be derived from execution itself.

    If your system cannot observe and constrain execution as it unfolds, you don't have least privilege — you're just capping worst-case damage.

    Curious how others are operationalizing AI agents today, especially for long-running agents and third-party tools operating across trust boundaries?