An AI assistant can know how to call a scheduling API and still have no authority to change a customer's appointment. These are different questions. Tool access asks, “Can this system make the request?” Authorization asks, “Should this actor be allowed to make this change to this record, now?”
The distinction becomes critical when AI moves from answering questions to taking actions. A model can produce a convincing plan, and a connector can expose a functioning endpoint. Neither proves that a customer consented, that a record belongs to the right business, or that the action meets business policy.
A practical example: rescheduling an appointment
Consider a hypothetical appointment assistant. A customer messages: “Move my appointment to Friday afternoon.”
The assistant recognizes the request and selects a rescheduling tool. It may have valid service credentials. But the scheduling service still needs to establish the customer's identity, confirm ownership of the appointment, bind the request to the correct business tenant, check the new slot and apply any rescheduling cutoff or approval requirement.
If verification is incomplete, the safe outcome is to ask for verification or escalate. If policy denies the action, the system should not silently mutate the booking. The assistant should report the actual state rather than promise a completed change.
This is an illustrative example, not a claim that Digital Inspiron or Rabtio has released this exact scheduling workflow.
Three layers that should not be confused
Authentication establishes an identity. Tool permissions limit which capabilities an agent or application can invoke. Action authorization determines whether a specific actor can perform a specific operation on a specific resource under the current circumstances.
A useful policy question is: May actor A, on behalf of user U, in tenant T, perform action X on resource R under conditions C?
The answer should be computed from trusted identity, ownership and policy records, not from the model's assertion that an action seems appropriate. A prompt saying “You are authorized” is not an access-control mechanism.
The OWASP's API Security Top 10 includes broken object-level authorization and broken function-level authorization as distinct API security risks. An API can authenticate a caller while still failing to check whether the caller may modify the particular object or perform the particular operation.
Enforce authorization where the action happens
Put the final decision in the trusted service performing the business mutation, or in an enforcement gateway that cannot be bypassed through an alternate tool path.
A production-oriented flow has five stages:
- Proposal. The AI prepares a structured request containing the intended action, target resource, proposed change and user-visible rationale.
- Context binding. The application attaches authenticated actor, delegated user and tenant context from trusted sources. The AI does not choose these identifiers.
- Decision. The authorization service checks role, delegation, resource ownership, current policy and required approval.
- Execution. The business service performs the permitted change with concurrency and idempotency safeguards.
- Verification. The system records the authoritative outcome, and the AI communicates completion only when that outcome is confirmed.
A denial can return a controlled reason such as identity verification required, wrong resource owner, approval required, policy window closed or tenant mismatch. The user-facing response should remain helpful without exposing confidential policy internals.
Five boundaries to test before launch
Tenant isolation
Every lookup and mutation must be scoped to the business tenant determined by the trusted application. Never accept a tenant identifier from a prompt or model-generated tool argument as sufficient proof of authority.
Resource ownership
A valid user session does not confer rights over every record. Verify that the authenticated customer can act on the specific appointment, order or account. This is the object-level authorization check.
Delegated role
An AI customer-service role may read appointment availability but have no authority to cancel bookings, issue refunds or modify billing. RFC 8693 (OAuth 2.0 Token Exchange) describes token exchange, including delegation and impersonation semantics. It does not replace the business application’s policy engine.
Business rules and approval
An action may require confirmation because of cost, timing or impact. Examples include refunds over a threshold, cancellations close to appointment time or bulk messages. Bind approval to the exact proposed operation and resource, not to a broad instruction to “handle it.”
State at execution
Conditions can change between planning and execution. A slot can be taken, a permission revoked or an approval expired. Recheck relevant conditions at the execution boundary. A network timeout is not evidence of a successful change.
Why confidence is not authority
A model may be confident and wrong. It may confuse customers, misunderstand an instruction or be influenced by untrusted content retrieved from a document. Confidence can inform whether to clarify a request; it cannot grant permission to mutate a record.
This is particularly important in retrieval-augmented AI. Relevant knowledge is not automatically authorized knowledge, and authorized reading is not the same as authorized action. Keep retrieval permissions, tool availability and business mutations as separate controls.
An October 2026 exploit round-up hosted by the OWASP GenAI Security Project discusses reported cases where agent behavior exceeded intended operational boundaries. The round-up states that it is not an official OWASP publication, and its examples should not all be treated as application-level authorization failures. Its relevance to architecture is straightforward: limit the effective authority of connected tools, particularly where actions are destructive or difficult to reverse.
Human approval should be a deliberate outcome
Human handoff can be a designed authorization result rather than a generic failure fallback. A policy service can respond with approval required, accompanied by a precise action summary, target record and expiration. An authorized reviewer approves that specific proposal. Before execution, the service verifies that the proposal and approval are still valid.
Customer messaging should distinguish request received, awaiting approval and completed. “Your request has been sent for review” is accurate when approval is pending. “Your appointment has been moved” is not.
What an audit trail should establish
Record an action identifier, trusted actor and tenant, target resource reference, operation, policy version, decision, approval reference where relevant, execution outcome and timestamps. This is a practical implementation recommendation consistent with the governance and risk-monitoring emphasis of the NIST AI Risk Management Framework Core, not a NIST-prescribed audit schema. Avoid indiscriminately logging full conversations, credentials or sensitive customer data. Audit records themselves require access controls and retention limits.
The record should answer: who requested the action, on whose behalf, under which rule, what was approved and what actually happened?
A compact authorization test suite
Before enabling an AI workflow to modify production records, attempt these tests:
- Request a change to another tenant's record.
- Request a change to another customer's record in the same tenant.
- Invoke a tool operation outside the agent's role.
- Inject a forged tenant or user identifier through a tool argument.
- Change the proposed action after approval.
- Revoke permission between proposal and execution.
- Retry after a timeout and check for duplicate changes.
- Make the model claim success when the authoritative service reports pending or failure.
These tests assess the real enforcement boundary rather than merely the model's response quality.
Frequently asked questions
Is an API key enough to authorize an AI action?
No. Credentials may authenticate a caller or allow access to an endpoint. The application must still verify authorization for the particular operation, resource and context.
Where should authorization checks run?
In the trusted service or enforcement gateway responsible for the action, using authoritative identity, tenant, ownership and policy data.
Does every AI action require human approval?
No. Low-risk, narrowly scoped actions can be executed automatically after policy checks. Sensitive or ambiguous actions may require confirmation or an authorized reviewer.
How does tenant isolation relate to authorization?
Tenant isolation limits which business's resources an action can reach. Authorization also evaluates the actor, operation, ownership, delegation and business policy.