AI Agent Identity and Access Control: Who Acts, Who Approves, and What Executes

An AI agent identity is the verifiable identity used to attribute an agent's requests and apply access policy. It should identify a workload, client, or agent instance that a service can authenticate. A model name such as gpt-5 or a friendly label such as release-agent is useful metadata, but neither proves which process made a request.

Production agents rarely act under one identity. A person initiates a task, an agent runtime plans it, an integration calls a service, another person may approve the operation, and a separate credential performs the side effect. Keeping those identities separate makes authorization narrow and incident review possible.

One rule keeps these boundaries intact:

Human approval can add a condition to an operation. It must not add permissions that the agent did not already have.

The five identities behind one agent action

Consider an agent that proposes a production deployment. At least five actors can appear between the prompt and the changed system:

This model is deliberately more specific than "the agent did it." That sentence hides the details an operator needs after a bad deployment or suspicious payment: which run proposed it, which credential could reach the tool, who reviewed it, and which account changed the resource.

The NIST National Cybersecurity Center of Excellence is examining standards-based ways to identify and authorize software and AI agents. Its software and AI agent identity project frames the problem around both access and actions. The OpenID Foundation whitepaper on agentic identity likewise separates authentication, authorization, delegated authority, and workload identity.

Authentication, authorization, and approval are different checks

An authenticated agent is not automatically authorized. An authorized agent does not automatically have approval for every call. These checks answer different questions and should produce separate evidence.

OAuth access tokens can carry scopes and audience restrictions, but possession of a token is not proof that a specific high-impact operation should run. RFC 9700 recommends restricting access-token privileges and audience. RFC 9396 defines structured authorization details for cases where simple scope strings cannot describe the requested access precisely.

Human approval sits after those controls. It answers a contextual question about one operation. It does not replace token validation, resource policy, argument validation, or least privilege.

Effective authority is an intersection

Compute effective authority as the intersection of several limits:

effective authority =
  delegated user authority
  ∩ agent workload grant
  ∩ tool policy
  ∩ resource policy
  ∩ approved operation snapshot

Each term can only narrow the result. If the deployment identity can update checkout-staging but not checkout-production, a production approval must still fail. The approval records human judgment; it does not mint the missing production permission.

This follows the per-request, least-privilege approach in NIST SP 800-207. For environments that already issue workload identities, SPIFFE provides a standard identity namespace and verifiable identity documents. Neither standard decides whether a particular agent operation deserves human review. That decision belongs in the application or gateway that controls the tool call.

A reference record for agent actions

The following record is a vendor-neutral evidence model. It is not an Actionbox request format. Its purpose is to keep identities and decisions distinct while giving logs, traces, and approval systems stable correlation fields.

{
  "initiator": {
    "type": "user",
    "id": "usr_release_manager"
  },
  "agent": {
    "workload_id": "spiffe://example.com/prod/release-agent",
    "run_id": "run_20260901_042"
  },
  "integration": {
    "client_id": "release-orchestrator"
  },
  "operation": {
    "tool": "deployment.promote",
    "resource": "checkout",
    "environment": "production",
    "arguments_sha256": "sha256:<hash of the canonical arguments>"
  },
  "authorization": {
    "policy_id": "release-policy-v4",
    "result": "requires_human"
  },
  "approval": {
    "action_id": "act_<id>",
    "action_version": 1,
    "fingerprint": "sha256:<reviewed Action fingerprint>",
    "status": "open"
  },
  "execution": {
    "credential_id": "deploy-bot-production",
    "status": "not_started"
  }
}

Do not copy credentials, raw prompts, or unrestricted tool arguments into this record. Hashes and stable IDs help correlate protected evidence without spreading the evidence itself through every log system. Keep the canonical operation payload in a system authorized to store it.

Put the approval around the exact tool call

The policy boundary should see the tool name, target resource, environment, and sanitized arguments. Asking a person to approve a plan several steps earlier leaves room for the agent to change the operation afterward.

The OWASP AI Agent Security Cheat Sheet recommends least-privilege tools, human review for high-impact actions, separation between decision and execution, and structured testing of tool misuse. Those controls work together at the tool boundary:

1. Authenticate the workload and validate the credential audience.
2. Authorize the requested tool and resource.
3. Validate and canonicalize the arguments.
4. Classify the operation as allow, deny, or require human review.
5. Bind the review to the current operation snapshot.
6. Re-read the authoritative decision before delayed execution.
7. Execute with the agent's existing downstream credential.
8. Record the real outcome separately from the approval.

Worked example with Actionbox

Actionbox uses separate identity boundaries for software and people. A Source key authenticates a machine integration. A signed-in workspace member reviews and decides the Action. The integration keeps its own downstream credential and performs the operation only after receiving a valid decision.

This request creates a review for one proposed deployment. The Source key is loaded from a server-side secret store. The idempotency key identifies the logical tool call so a transport retry does not create another request. The example expires after 30 minutes and returns expired if nobody decides.

: "${ACTIONBOX_SOURCE_KEY:?Set ACTIONBOX_SOURCE_KEY from your secret store}"
ACTION_EXPIRES_AT="$(jq -nr 'now + 1800 | todateiso8601')"

jq -n --arg expires_at "$ACTION_EXPIRES_AT" '{
    "title": "Promote checkout 2.18.0 to production?",
    "description": "The release agent is paused before the production tool call.",
    "priority": "high",
    "options": [
      {"id": "approve", "label": "Approve deployment", "style": "primary"},
      {"id": "reject", "label": "Reject", "style": "destructive"}
    ],
    "decision_class": "production_deployment",
    "decision_context": {
      "schema_version": 1,
      "reason": "Required staging checks passed.",
      "current_state": "Production is running checkout 2.17.4.",
      "proposed_change": "Promote checkout 2.18.0 to production.",
      "expected_effect": "Production traffic will use the reviewed release.",
      "risk_level": "high",
      "risk_summary": "A faulty release could disrupt checkout traffic.",
      "reversibility": "reversible",
      "rollback_plan": "Restore checkout 2.17.4.",
      "affected_scope": ["production", "checkout"]
    },
    "metadata": {
      "agent_run_id": "run_20260901_042",
      "tool": "deployment.promote",
      "resource": "checkout"
    },
    "expires_at": $expires_at
  }' |
curl --fail-with-body --request POST \
  https://api.actionbox.cloud/v1/actions \
  --header "Authorization: Bearer $ACTIONBOX_SOURCE_KEY" \
  --header "Idempotency-Key: run-20260901-042:deployment.promote" \
  --header "Content-Type: application/json" \
  --data-binary @-

The response includes an Action ID, action_version, and fingerprint. Machine code reads the current state through the Source-scoped endpoint:

curl --fail-with-body \
  "https://api.actionbox.cloud/v1/source/actions/$ACTION_ID?wait_seconds=30" \
  --header "Authorization: Bearer $ACTIONBOX_SOURCE_KEY"

The bounded wait can return while the Action is still open. Keep reconciling through the normal worker loop. Treat reject, cancelled, expired, an API failure, a changed version, or a malformed response as a stop. On approval, execute with the release agent's scoped deployment credential, not the reviewer's account.

After the attempt, report the execution outcome with the action_version and fingerprint from the resolved Action. Approval and execution remain separate facts:

case "$EXECUTION_STATUS" in
  success|failed) ;;
  *) printf 'Invalid execution status\n' >&2; exit 2 ;;
esac

jq -n \
  --arg status "$EXECUTION_STATUS" \
  --arg fingerprint "$ACTION_FINGERPRINT" \
  --argjson version "$ACTION_VERSION" \
  '{
    status: $status,
    action_version: $version,
    fingerprint: $fingerprint,
    rollback: false
  }' |
curl --fail-with-body --request POST \
  "https://api.actionbox.cloud/v1/actions/$ACTION_ID/outcome" \
  --header "Authorization: Bearer $ACTIONBOX_SOURCE_KEY" \
  --header "Idempotency-Key: outcome:$ACTION_ID" \
  --header "Content-Type: application/json" \
  --data-binary @-

EXECUTION_STATUS must be success or failed. Report what the downstream system returned. An approval followed by a failed deployment is a failed outcome, not a successful one.

For the exact credential and response contract, read API authentication, API reference, and decisions and outcomes.

Failure behavior to decide before production

Approval systems should make these branches visible. A generic approved: true field cannot explain whether the agent had permission, whether the payload changed, or whether the operation succeeded.

Review checklist

• Does every production agent have a revocable machine identity?
• Can logs distinguish the initiator, agent run, integration, reviewer, and executor?
• Is authorization checked at the protected tool rather than only in the prompt?
• Are token audience, resource, environment, and operation scope restricted?
• Does approval narrow authority instead of borrowing the reviewer's privileges?
• Is the decision bound to the exact tool arguments or a canonical hash?
• Do rejection, expiry, stale state, and API failure stop execution?
• Is the downstream result recorded separately from the decision?
• Can one compromised agent credential be revoked without disabling unrelated agents?
• Do tests cover tool misuse, privilege escalation, replay, and payload changes?

Sources and further reading

• NIST NCCoE: Software and AI Agent Identity and Authorization
• OpenID Foundation: Identity Management for Agentic AI
• NIST SP 800-207: Zero Trust Architecture
• SPIFFE standard
• OAuth 2.0 Security Best Current Practice, RFC 9700
• OAuth 2.0 Rich Authorization Requests, RFC 9396
• OWASP AI Agent Security Cheat Sheet
• AI agent governance: policy, approval, and outcome evidence around the identity model.
• AI agent audit trails: the event record that connects proposal, decision, and execution.

Create a free Source · Read the Actionbox security architecture · Add human approval to an AI agent