Runtime Action Authorization

What This Protects

An agent can read information, form a plan, and propose a tool call. A consequential tool call—transferring money, changing a production record, sending a message, or deleting a file—needs a separate check. Runtime Action Authorization gives that check a narrow question: may this authenticated runtime perform this exact action on this exact resource for this registered execution right now?

A valid login answers only who is calling. It does not answer whether a particular transfer, update, or deletion is in scope. AIGP combines the caller's authenticated identity with a server-stored delegation and the active policy set before returning ALLOW or DENY.

Who Does What

PDP means Policy Decision Point: it decides. PEP means Policy Enforcement Point: it is the gate in front of the real tool. Keeping those jobs separate matters because AIGP cannot directly execute or observe an external database, payment gateway, or SaaS API.

Bring Your Own Identity

AIGP needs a trustworthy answer to “which workload is calling?” Your cloud or identity provider can supply that answer. The provider identity authenticates the issuer and runtime; AIGP still owns the separate, execution-scoped delegation and policy decision. This is an integration boundary, not a claim that these providers are native AIGP integrations.

The Decision Sequence

The trusted delegation is stored before the agent proposes an action. AIGP resolves it again during authorization; the PEP then either runs the exact bound operation or stops it.

1. Register the execution. The application creates a canonical AIGP execution for the external run.
2. Issue the delegation. A separately authorized issuer creates a short-lived grant for that execution, runtime identity, action, and resource scope. AIGP evaluates the active delegation-issuance policy, then stores the immutable grant.
3. Prepare the actual tool arguments. The runtime canonicalizes those arguments and computes their SHA-256 digest.
4. Ask for authorization. The runtime sends its authenticated request, the delegation ID/version/digest, action/resource identity, and tool-argument digest.
5. Resolve trusted state. The PDP reads the delegation from its own tenant-scoped store and discovers every active policy registered for that action and resource type.
6. Decide. Mismatched identity, execution, scope, digest, expiry, revocation, or policy state produces DENY. Otherwise matching safe APPROVE rules can produce ALLOW; REJECT and BLOCK override an allow.
7. Enforce immediately. The PEP checks the unexpired response against the actual pending call, including the arguments digest. Only then does the runtime invoke its protected tool.

Trusted and Agent Inputs

Policies and Delegation

Setup has two separate policies. The first governs who may issue a delegation. The second governs whether a delegated runtime operation may be allowed. Create and activate both before the first protected run; they are standing control-plane rules, not inputs chosen by an individual agent request.

A runtime-action policy opts into this decision path through definition metadata. Its policy version must target AgentExecution and contain the ordinary structured rules that match the server-resolved facts.

{
  "runtime_action_authorization": {
    "purpose": "runtime_action_authorization",
    "registered_actions": ["payments.transfer"],
    "registered_resource_types": ["bank.account"]
  }
}

The issuer additionally needs the runtime_action_delegation.issue platform permission. That permission alone is not enough: the active issuance policy must also match the requested scope.

Authorization Request

The runtime calls the authorization endpoint for one operation. It sends bounded identifiers and digests, not raw tool arguments, prompts, credentials, model responses, or reasoning. The exact public schema is runtime-action-authorization/v2.

{
  "schema_version": "runtime-action-authorization/v2",
  "execution_id": "exec_01J...",
  "correlation_id": "transfer-request-4821",
  "action_id": "payments.transfer",
  "resource": {
    "resource_type": "bank.account",
    "resource_reference": "account:operating-001"
  },
  "delegation_id": "delegation_01J...",
  "delegation_version": "1",
  "delegation_digest": "sha256:...",
  "tool_arguments_digest": "sha256:...",
  "idempotency_key": "transfer-4821-authorize",
  "context": { "request_channel": "scheduled-maintenance" }
}

A successful response contains the ALLOW or DENY outcome, reason code, decision and expiry times, request fingerprint, delegation bindings, and the policy ID/version set evaluated by the PDP. A decision is not a reusable bearer grant: it is bound to this operation and expires quickly.

Runtime Enforcement

The authorizer is not the tool runner. Your runtime must place a PEP directly before the consequential call. Recompute the canonical tool-arguments digest from the arguments about to be executed, require a current ALLOW, and compare the execution, runtime identity, action, resource, delegation, and digest bindings. Any timeout, malformed response, denial, expiry, revocation, or mismatch stops the tool.

prepare exact arguments
  → compute canonical arguments digest
  → request AIGP authorization
  → verify current ALLOW and every binding
  → invoke protected tool once
  → report bounded outcome evidence

Evidence and Review

AIGP persists the authorization result as a RUNTIME_ACTION_AUTHORIZATIONevent on the canonical execution. The event carries bounded operational facts such as the outcome, reason code, action/resource identity, policy references, decision expiry, and digests. If the runtime performs the tool call, it reports a TOOL_CALL event with the authorization decision as its causation ID.

This proves the decision AIGP made and the tool outcome the runtime reported. It does not turn AIGP into an independent observer of the external database or API. Review the ordered timeline in Studio's Agents Runtime area, and use the LangGraph governed operations guide for a live local walkthrough.

REST API

• POST /api/v1/runtime-action-delegations — issue a bounded immutable delegation as the authorized issuer.
• POST /api/v1/runtime-action-delegations/{delegation_id}/revoke — record a one-way revocation; it affects new decisions.
• POST /api/v1/runtime-action-authorizations/authorize — request the decision for one protected operation.

Use the interactive API reference for the published request and response schema. The Policy Engine guide covers policy lifecycle and the Agent Runtime Integration guide covers execution and event evidence.

Boundaries

• AIGP does not schedule the agent, choose its branch, execute its tool, or store the raw tool arguments.
• The control plane owns delegation state and authorization decisions; the external runtime owns PEP enforcement and the protected-system integration.
• Revocation blocks a new decision. A previously issued ALLOW is usable only until its own short expiry.
• The arguments digest binds exactly what the PEP intended to call; it does not replace domain validation such as transfer limits or database constraints.
• Use durable SQLite or PostgreSQL control-plane storage for a deployed integration. In-memory storage is appropriate only for isolated tests.