Guide

IAM vs action authority

Access is not authorization.

IAM tells you who can reach a system. Action authority tells you whether this exact high-risk action should execute right now — refunds, dispatches, delegations, and credential changes.

The category mistake

Enterprises extending IAM to AI agents and automations hit the same wall: a service account with a bearer token can authenticate forever, but nothing asks whether this refund, this deployment, or this delegation should run at this moment.

IAM answers authentication and coarse access. Action authority answers per-action authorization at execution time — with ALLOW, DENY, or APPROVAL_REQUIRED outcomes and replayable evidence.

What IAM does well

IAM is necessary. It is not sufficient for consequential automation where each action has distinct risk.

  • Human and machine identity lifecycle
  • Role-based access to systems and APIs
  • SSO, MFA, and directory integration
  • Audit of who authenticated and when

What action authority adds

Humbleaf sits in the new stack: identity → action authority → approval → execution → evidence.

  • Policy evaluation on the proposed action payload
  • Behavioral risk advisory before execution
  • Human approval bound to the exact action hash
  • Evidence bundles for ALLOW, DENY, and APPROVAL_REQUIRED

When you need both

Use IAM for who can reach your payment API. Use action authority for whether this €4,800 refund from support-agent-04 should execute under refund-policy-v7 right now.

Most enterprises at L1–L2 on the Authority Readiness Model have IAM but lack per-action control for automations.

Frequently asked questions

Does Humbleaf replace IAM?

No. Humbleaf complements IAM with a pre-execution authority layer for high-risk actions.

Can IAM policies express per-action approval?

IAM policies are typically coarse and static. Action authority evaluates the full proposed action with policy snapshots and risk context at execution time.

Where does Humbleaf sit in the stack?

Between identity/authentication and downstream execution APIs — after the actor is known, before state mutates.

Related

Next step

Map your workflows

See where action authority fits in your stack — no credentials required.