BlueBear Insights · Agent Security · 3 min read

AI Agent Authorization: Identity, Delegation, and Least Privilege

By Phillip Joe — Founder, BlueBear.ai · AI engineer

BlueBear governance evidence ladder connecting identity policy execution and outcome records
Production agents need a control decision and an evidence record for every consequential action.

AI agent authorization is the action-time decision that a specific agent may use a specific capability on a specific resource, for a delegated purpose, inside a bounded context. Authentication answers who the actor is. Authorization answers whether this action is permitted now.

In plain terms: an agent should never be able to do something just because it holds a key. Each action should be checked against who asked for it, what that person may delegate, what the agent is for, and how risky the action is.

Why shared API keys fail

A shared key authorizes everything the key can reach, for as long as it exists. It cannot tell one agent from another, cannot express "only for this customer" or "only below this amount", and cannot be revoked for one agent without breaking the rest. It also tends to end up in prompts, logs and traces.

The authorization tuple

allow = policy(subject, delegator, agent, action, resource,
               tenant, workspace, purpose, risk, time, approval)

Leaving any of these fields implicit creates confused-deputy and privilege-expansion risk. A model-generated plan must not be able to change the subject, scope, or approval requirement.

Decision sequence

  1. Authenticate the human or service that initiated the work.
  2. Resolve the versioned agent and its workload identity.
  3. Verify delegation: who allowed this agent to act, for what purpose, and until when?
  4. Resolve tenant, workspace, resource, data class, and requested tool action.
  5. Evaluate least-privilege policy and any separation-of-duties rule.
  6. Require a bound approval for high-impact actions.
  7. Issue or resolve a short-lived, audience-bound credential only after allow.
  8. Record the decision and downstream receipt under one correlation ID.

MCP authorization boundary

The Model Context Protocol authorization specification is explicit on two points. Servers "MUST validate that access tokens were issued specifically for them as the intended audience", and an MCP server "MUST NOT pass through the token it received from the MCP client" to an upstream API (MCP specification, 2025-06-18). Use a separate upstream credential and keep bearer material out of prompts, traces, and model-visible context.

Policy example

{
  "subject": "agent:invoice-review:v7",
  "delegated_by": "user:finance-manager",
  "workspace": "finance-prod",
  "action": "invoice.propose_update",
  "resource_scope": "region:us;amount<10000",
  "approval_required": "invoice.execute_update",
  "expires_in": "15m"
}

Common mistakes

  • Granting the agent the permissions of the user who configured it, permanently.
  • Checking authorization once when the session starts instead of before each consequential action.
  • Treating an approval as valid after the action's destination or amount changed.
  • Letting a nested tool call inherit a broader scope than the plan that started it.

Tests that prove the boundary

  • Replay the token against another server and expect denial.
  • Request a broader resource after approval and require re-approval.
  • Revoke the workload identity during a queued run and fail closed.
  • Inspect model context and telemetry for credential leakage.
  • Verify an administrator cannot both change policy and approve their own high-impact action without an explicit exception.

Run the 12 denied-action cases to prove the boundary, and see why broad keys fail review. Review how BlueBear separates agent identity, workspace assignment, policy, and tool execution.

Primary sources