How to Implement Runtime Authorization for AI-Agent Actions

Where the evaluate call sits

The useful place is the last function that can still stop the side effect. A system prompt, a tool list, or a comment earlier in the agent loop is not that place. If the agent can still reach the deploy workflow, the payment method, or the export API without passing the check, the check is off the execution path.

Wrap the existing executor. A deployment function, a payment service method, or an internal API that owns the mutation are practical places. The wrapper asks for a decision, then either continues into the executor the team already trusts or returns without calling it. BobSentry does not execute the downstream action. The integration remains responsible for that call.

What runtime authorization is, as a definition, already lives in runtime authorization for AI agents. This article is the implementation: where the call goes, which facts it carries, and how each result is honored.

Put the wrapper on the execution path

Put the wrapper on the path that performs the mutation. Telling the model to ask for a decision does not do that, because the model can still reach the executor. The sequence is short.

1. The agent proposes one consequential action and the facts it already has.
2. The integration normalizes those facts. It does not ask the model to grade its own risk.
3. The integration calls BobSentry before the mutation and waits for ALLOW, REQUIRE_APPROVAL, or BLOCK.
4. The integration either calls the existing executor or stops.
5. The integration keeps the decision id next to whatever the executor later reports.

Preparation can stay outside the wrapper. Drafting a change, reading logs, or opening a review are not the mutation. The wrapper starts where a side effect would otherwise begin.

Facts the integration sends

Send structured facts about this attempt. Name the action, the agent identity, the environment, the target, and the other fields policy needs in order to choose. For a production deploy, that is often the service, the revision, and the workflow that would perform the release. Leave the raw business payload in the customer environment when normalized facts are enough.

• Action name, such as deploy_production or refund_customer.
• Agent identity, separate from the human who owns the integration.
• Environment, such as staging or production.
• Target or resource, such as the service, account, or record set.
• Policy context: amount, destination, destructive flag, permission change, migration, or rollback availability when those facts can change the decision.

Do not send a single field such as risk: low and treat it as the decision. That sentence hides the facts a policy can check. Unknown or unmatched consequential actions require approval under the current product behavior. They do not fall through to a silent ALLOW.

One deploy_production attempt

A release agent proposes a production deploy of payments-api. The integration builds the request at the deploy function, not in the prompt. The same shape works for a refund or an export. The field names below are illustrative. The point is that the facts are structured and specific to this attempt.

Illustrative evaluate request{
  "action": "deploy_production",
  "agent_id": "release-agent",
  "environment": "production",
  "target": "payments-api",
  "facts": {
    "revision": "a1b2c3d",
    "workflow": "deploy-production",
    "migration": false
  }
}

This example shows the authorization facts and where the call sits. It is not a copy-paste production request contract. Exact SDK and API usage is documented for developers. BobSentry returns one of three decisions. The next three sections are the integration's job, not a second opinion from the model.

ALLOW: the integrator may proceed

ALLOW means policy permits the integrator to proceed with this attempt. The integration may call the existing executor. ALLOW does not mean the service was deployed, and it does not mean the rollout succeeded. If the workflow then fails, both facts can be true: authorization permitted the attempt, and the attempt failed.

Record the decision id with the attempt. A later question about why a deploy started should be answerable from the authorization record and, separately, from the workflow log. Those are different objects.

REQUIRE_APPROVAL: wait, then decide again whether to call

REQUIRE_APPROVAL means a person must authorize this exact attempt before the integrator continues. The integration waits. It does not start the production workflow while the decision is unresolved, and it does not ask the agent to retry the same facts until a different result appears.

When the person approves, approval authorizes the integrator to proceed. Approval does not prove execution. The integration still has to perform the deploy, and it still has to record whether that call succeeded. When the person denies the attempt, the integration does not proceed. Denial is not a failed deploy. Nothing was sent.

BLOCK: do not proceed

BLOCK means policy denies this attempt. The integration does not call the executor. Do not treat BLOCK as a suggestion the agent may override by rephrasing the prompt. If the facts change, that is a new attempt and a new decision.

A block is also not a claim that the cloud API was called and rejected. The downstream system was not asked. Keep that distinction in the log the operator will read later.

When the evaluate call fails

The evaluate call can fail before a decision exists. The network can drop, or the integration can time out. For this production deploy, the wrapper should not call the executor just because a decision is missing. That fail-closed behavior is an integration choice for this action. It is not a fourth value beside ALLOW, REQUIRE_APPROVAL, and BLOCK.

A missing decision is not a BLOCK, and it is not evidence that the action was refused by policy. For this production workflow, no authorization was obtained, so the integration should not attempt the mutation. Log the failed evaluate call on its own. Do not treat the failed call as a reason to proceed.

Retries need the same discipline. A second deploy_production with a new revision is a new attempt and needs a new decision. Reusing an ALLOW or an approval that was made for different facts would authorize something the reviewer did not see.

Execution stays with the integrator

BobSentry returns the authorization decision. The existing integration or executor performs or withholds the downstream action.

This article assumes a COOPERATIVE integration: the integration calls BobSentry before the consequential operation and honors the result. OBSERVE evaluates and records what policy would decide without gating downstream execution. The full decision and mode model is on the product page.

Start with one consequential action. Add the next only after the first authorization path is understood and reliable.