What Is Runtime Authorization for AI Agents?

The Problem

Most systems check who an agent is once, at login, and then trust everything that agent does afterward. That works for a person reading a dashboard. It breaks down for an AI agent that can call tools, move data, or trigger workflows on its own, because a single valid session can be reused for actions nobody explicitly approved. An agent may have access without any proof that a specific action was authorized by a user or organization.

What You'll Build

The difference between authentication, signature verification, and authorization
Why a valid signature proves the signer but not the scope of what they may do
How PTERI evaluates identity, delegation, scope, policy, and expiration at request time
What a runtime authorization decision looks like in practice

Prerequisites

Basic familiarity with API authentication concepts (API keys, OAuth, or similar)

Implementation

Pseudocode — illustrative only. See docs.kakr.ai for real SDK and endpoints.

// Step 1: Identify the agent making the request
const identity = pteri.identify({ type: 'agent', credential: agentKey })

// Step 2: Define the action the agent is requesting
const request = { action: 'crm.export_records', resource: 'customer_data', count: 500 }

// Step 3: Authorize — PTERI evaluates identity, delegation, scope, and policy
const decision = await pteri.authorize({ identity, request, policy: 'data_export_policy' })

// Step 4: Act on the decision, not on the session alone
if (!decision.allowed) {
  throw new Error('Insufficient authority: ' + decision.reason)
}

executeExport(request, decision.evidence)

Security Explanation

Identity acting: The specific AI agent making the request, given a distinct verifiable identity separate from the human or organization that deployed it.
Authority granted by: The user or organization that delegated authority to the agent, recorded at the time delegation was granted.
Action requested: The exact action the agent is attempting — for example, exporting a defined set of records, not a generic "access granted" flag.
Scope permitted: The boundaries of what the agent may do: which resources, how much, and under what conditions.
Policy evaluated: The applicable policy checked at the moment of the request, not only when the agent first authenticated.
Evidence created: A tamper-evident record connecting the identity, the authority, the request, and the decision, so the outcome can be verified after the fact.

Allow and Deny Behavior

Allowed

An agent with delegated authority scoped to "export up to 100 records per request" asks to export 80 records. Identity, delegation, and policy all check out, so the action is allowed and evidence is recorded.

Denied

The same agent later asks to export 5,000 records — outside its permitted scope. Runtime authorization denies the request before it executes, even though the agent authenticated successfully.

Production Considerations

Keep authorization policy versioned and auditable, separate from application code.
Revoke or narrow an agent’s delegated authority independently of revoking its authentication credential.
Monitor denied requests as a signal — repeated denials can indicate a misconfigured agent or an attempted scope violation.
Treat evidence records as append-only and tied to a specific identity, action, and policy version.
Plan for policy evaluation latency in latency-sensitive agent workflows.