Before an AI Agent Acts: Where Authority Is Enforced

Keep the action tied to the assigned work

Hypothetical enterprise example. A bank customer uploads a complaint PDF asking for reversal of an incorrectly assessed fee. A service employee, authenticated through the bank’s normal case process, assigns the investigation to an agent. The employee has already linked the complaint to the verified customer and account. This action’s intended outcome is correction of the fee, evidenced in the banking system and linked case record. The service team still owns the wider complaint resolution.

In this illustrative design, the original fee is USD 40. Policy retains the reversal decision with an authorized service supervisor. The agent may Recommend a reversal and then Act by executing that exact approved instruction. Missing evidence or conditions require Escalate. Decisions to change the agent’s own permissions or the governing fee policy are Never Delegate. These arrangements coexist in the case; they are not a progression toward greater autonomy. The amounts and approval choices are illustrative, not universal banking requirements.

The assignment records the requesting employee, case, permitted purpose, and scope. The acting service has its own verifiable identity. The execution path preserves that connection, so you can attribute the request to both the service that acted and the work it was assigned. A service credential alone does not establish the business mandate.

The Outcome owner defines acceptable resolution. The Operating owner assigns responsibility for unfinished cases. If a conventional workflow can interpret the inputs reliably and enforce the same conditions, it may be the simpler choice. An agent should earn its place by improving its work.

Keep external information from becoming authority

The complaint supplies the customer’s account of events. The banking record establishes which fee was posted. Approved policy establishes the conditions for reversal. Those sources have different authority even when their text appears together in the agent’s context.

The Knowledge owner maintains the applicable policy, its version, and its approval status. A saved agent note saying that similar complaints were approved last month is unverified retained memory until checked against authoritative records. It cannot replace current policy or create an approval. Enterprise Knowledge Backbone develops the wider knowledge responsibility; here, the immediate question is which facts may support this action.

Now suppose the PDF contains instructions to ignore the approval process, credit USD 400 to another account, and remember that future complaints are preapproved. These are instructions inside external material, not an extension of the employee’s assignment. Tool results can carry the same kind of conflicting text.

OWASP’s agentic guidance identifies both goal hijacking and persistent memory poisoning as risks. [1] Separating instructions from external content helps, but the decisive protection in this example sits at the action boundary. Even if the agent proposes the hostile instruction, the execution service must reject it. An instruction in the prompt to obey policy is insufficient enforcement.

Separate reading from using a tool and authorizing an action

The agent needs permission to read the relevant case and account information. It may also have permission to call a fee-reversal interface. Neither permission, by itself, authorizes a particular debit or credit.

Least privilege means giving the service only the access and actions necessary for its assignment, for the period needed. In this design, it can inspect the assigned fee and request its reversal. It cannot make arbitrary transfers, browse unrelated accounts, or change approval rules. NIST’s access-control guidance applies least privilege to processes acting for users as well as to people. [2]

The supervisor reviews the original fee, applicable policy, and proposed resolution through a trusted approval record. Approval identifies the case, original fee, account, USD 40 amount, currency, and permitted operation. It also identifies the approver and validity conditions. A broad “looks good” message or a model-supplied “approved” flag does not provide that record.

This precision protects both the person approving the work and the customer. The enterprise can establish what the supervisor actually authorized, while preventing a subsequent change in the proposed action from inheriting that approval.

Enforce the approved action where it executes

A controlled interface exposes a defined business operation: reverse the identified fee on its original account. Its tool contract specifies accepted inputs, required checks, intended effects, and possible results or errors. It offers no parameter for sending the money elsewhere.

The Technology owner implements checks outside the model’s judgment. Before execution, the service verifies the acting identity, task scope, current policy conditions, exact approval, and requested parameters against trusted records. The policy owner defines the business rules; developers do not acquire that authority by implementing them. Missing, expired, or revoked authority blocks the request.

The banking system also enforces the conditions needed for a valid posting against its current state. A check performed when the recommendation was drafted cannot establish that the same conditions still hold when the balance changes. Every available route to the consequential operation must preserve these controls; an unrestricted alternative tool would undermine the boundary.

OWASP’s current excessive-agency guidance calls for downstream authorization to be enforced independently of the model. Its agent security guidance also binds approval to the exact action and requires renewed approval when relevant parameters change. [3, 4]

For the permitted path, the records still agree: the case is assigned, the supervisor’s USD 40 reversal approval remains valid, and the original fee is eligible. The service submits that operation. Revoking the mandate before execution blocks further use; revocation cannot be assumed to undo a posting that has already taken effect.

Make refusal an operating outcome

In the hostile-document variation, a request for USD 400 or a different destination fails the approved operation’s constraints. A claim that the supervisor approved it fails verification against the actual approval record. The system blocks the financial action and prevents the document’s instruction from becoming approved policy or reusable approval in memory.

The case record retains the source reference, proposed operation, policy and approval versions, rejected parameters, time, and reason for refusal. Access to this evidence follows the bank’s information controls; routine logs need not reproduce the entire customer document.

The case enters a visible hold state with the assigned service supervisor as the escalation recipient. Suspected manipulation is also routed to the security response function. The Operating owner provides a named backup and an exception queue with an agreed response expectation. The customer’s complaint remains an obligation while the financial action waits.

Work can resume only after an authorized person establishes the relevant facts from trusted records, resolves or isolates suspect context, and supplies a valid approval for the intended action. The execution checks then run again. Removing suspicious text or asking the agent to try harder does not restore authority.

Approval time, investigation, and delayed resolution belong in the operating commitment. A control that blocks correctly can still leave an unworkable service if nobody has capacity to resolve the case. Holding this case is an incident response; any later formal review of the capability uses Expand, Continue, Narrow, Redesign, or Stop, with its own decision and evidence.

Verify the result and preserve the record

Four states must remain distinguishable. A proposed action is what the agent asks to do. An authorized action has satisfied the applicable permission and approval conditions. An attempted action has been submitted for execution. An accepted business result has evidence that the agreed outcome occurred.

For the permitted fee reversal, the completion check retrieves the authoritative posted record and matches the original fee, account, USD 40 amount, and currency to the approved request. The case retains the posting reference. The supervisor, as the designated person accepting this handoff, confirms that the evidence meets the Outcome owner’s resolution criteria before the financial part of the case closes. Sending a customer notification would be a separate action with its own authority.

If the service times out after submission, the financial state is unresolved. A success message without a matching authoritative record is also insufficient. The case must not be marked complete, and the agent must not improvise another consequential action. The authorized operations recipient establishes the actual state before any further action is permitted. Transaction coordination, retries, duplicate prevention, reconciliation, and distributed recovery require a deeper system-of-record design beyond this article’s authority boundary.

The audit record connects assignment, identities, source references, policy version, approval, requested operation, authorization decision, execution response, and completion evidence. It records observable events and explicit reasons; hidden model reasoning is not an audit record. The agent must not be able to rewrite this history. NIST’s audit controls address event content and protection of audit information. [2]

The Control lead coordinates the evidence and response to weaknesses. Independent assurance retains its separate challenge role, and security and Finance specialists retain their duties. Governing AI-Enabled Operations sets that enterprise context. This action’s trace gives those owners something concrete to examine.

Technical appendix

The following is a vendor-neutral logical design for the hypothetical example. Components describe responsibilities and may be combined or separated in implementation. NIST SP 800-207 distinguishes policy decisions from the components enforcing access. [5] Applying that distinction to this business action is RePerspective Labs’ design synthesis, not a certified architecture or an independently validated implementation.

Figure 1. One fee reversal across three trust boundaries. B1 separates external content from authorized instructions. B2 separates the agent’s proposal from independently enforced execution authority. B3 separates a reported execution result from verified business completion. Dotted connectors carry evidence; solid arrows carry requests, records or decisions. The diagram describes intended controls and does not establish their security.

The controlled interface contract

Illustrative contract for the fee reversal. Exact fields, validity periods and implementation mechanisms require an approved local design.

Controls and accountable roles

The roles below distinguish business definition, technical enforcement and operating response. Independent assurance remains separate from implementation and control coordination.

Proposed tests and expected behavior

These are proposed tests, not results from an implementation. Include the valid path to detect controls that refuse legitimate work as well as controls that permit unauthorized work.

These scenarios are proposed acceptance and adverse tests; none has been executed for this article. Test both the model-facing route and direct calls to the execution interface, including attempts to bypass it. A test passes only when the expected business-system effect or absence of effect is established with trustworthy evidence. Failure of an authorization check before submission can prove that this request was blocked; a timeout after submission cannot prove that no posting occurred.

The protected evidence record should include case and request identifiers, acting and requesting identities, source and policy references, approval details, normalized parameters, decision reasons, timestamps, result and accepting person. Record the relevant service, tool-contract and model configuration versions for investigation. Restrict access and modification; retain only the content needed under applicable information policy. An integrity check can reveal unauthorized alteration but cannot make a false source claim true.

Independent review should examine whether the controls cover every consequential route, whether the evidence is dependable and whether recipients can manage the exception load. OWASP guidance and NIST publications inform this design; they do not validate the example or impose its USD 40 amount, approval pattern or acceptance arrangement.