Before an AI Agent Acts: Define Its Authority

Set the boundary before connecting the agent

An AI agent’s permissions are a business decision. Give it a defined identity, a limited scope of work and an accountable owner before connecting it to enterprise systems.

The decision before deployment

A purchasing assistant can compare quotations, identify missing information and prepare a supplier response. The business question becomes more consequential when that same assistant can send the response, change an order or appoint a supplier.

Before enabling those actions, agree who the agent represents, which commitments it may make and what happens when the work falls outside that agreement. The useful deliverable is a short delegation brief that business and technology teams can test together.

For GCC enterprises moving from demonstrations into operational use, this is a practical next step. It connects the promise of agentic AI to the way the organization already assigns responsibility.

Why this question matters now

In an August 27, 2026 post, NIST highlighted recurring identity weaknesses in agent deployments, including shared credentials, long-lived credentials and broadly scoped access. It argued for applying established identity and authorization practices as agent technology develops. This is technical guidance from a US standards institution, not a GCC regulation.

• NIST’s identity guidance

The regional context is also moving. On September 10, 2026, the UAE Ministerial Council for Artificial Intelligence and Development reviewed the second phase of its Agentic AI Project, including initiatives for federal government entities. That announcement concerns government work; it does not establish a general private-sector or GCC-wide AI adoption mandate. The business implication we draw is to prepare the operating controls alongside the application.

• UAE Cabinet announcement

Organizations can make that preparation concrete without waiting for every emerging agent standard to mature. NIST’s February 2026 identity concept paper is still identified as a draft on its publication page; its consultation has closed. Treat it as evidence of ongoing work, rather than a finished certification scheme.

• NIST concept paper

Separate identity, delegation and permission

Three questions belong in the deployment discussion:

• Identity: which software agent performed the action?
• Delegation: on whose behalf was it acting?
• Permission: which operation was it allowed to perform on which resource?

The distinction between an actor and the party it represents already exists in identity standards. OAuth Token Exchange describes delegation in which the actor retains a separate identity while representing another party. Implementing a protocol alone does not establish the organization’s business policy.

• IETF RFC 8693

For a procurement workflow, the owner might be the head of purchasing, the requesting user a category buyer and the acting system a quotation-analysis agent. Those are separate roles. A buyer’s request to find a better delivery date does not, by itself, establish permission to amend a contractual commitment.

Write the brief around one business task

Our proposed starting point is a delegation brief for a single workflow. Give the business owner and implementation team the same document, then ask each to explain what the agent would do in an ordinary case and an exception.

The example below is illustrative, designed for a GCC trading or industrial business assessing supplier quotations. It is not a Bridges client deployment or a required regulatory template.

Keep the brief short enough to use during a release review. Its value comes from resolving the disagreements it exposes: which company’s price list applies, who can contact a supplier, and when a question becomes a commitment.

Translate the agreement into enforceable controls

An instruction telling the agent to stay within its role is useful context. The systems it calls also need to enforce the agreed limits. OWASP recommends limiting tool functionality and permissions, checking authorization in downstream systems, and requiring approval for high-impact actions.

• OWASP: Excessive Agency

For the illustrative quotation workflow, ask the team to demonstrate three different operations: read an approved quotation, create an internal comparison, and request approval to send a specific message. Each operation should be traceable to the business agreement. If the connector offers broader powers, document how the implementation restricts them and test the restriction.

A useful acceptance exercise is to change the purchasing request’s legal entity while leaving the supplier name unchanged. The expected result must follow the entity boundary agreed in the brief. Finding the same supplier in another company’s records is not sufficient grounds to use those records.

Approval also needs a defined object. The reviewer should see the actual proposed message and attachments. If either changes after review, the system should follow an explicitly agreed rule for whether another review is needed. This makes approval useful to the buyer and testable by the implementation team.

Keep supplier content separate from authority

Quotations, websites and incoming messages can contain instructions as well as business information. Prompt injection can arise when an application treats malicious or misleading content as instructions for its model. OWASP describes both direct and indirect forms of this risk.

• OWASP: Prompt Injection

In an illustrative test, a quotation attachment includes a sentence asking the assistant to bypass purchasing review and send internal comparison files to a different address. The test should establish that the attachment can inform the comparison without gaining the authority to change the workflow.

The business reviewer does not need to inspect model internals to assess this result. They need to see the proposal, the blocked or escalated action, and the record showing what actually left the organization. A reassuring explanation from the agent is insufficient evidence of the receiving system’s state.

Design the stop procedure before the first live action

Stopping an agent involves several different questions: has new work stopped, can it obtain more credentials, are existing permissions still usable, and has anything already been sent to another system?

OAuth Token Revocation provides a mechanism for invalidating tokens; its specification also discusses propagation delays. That is one part of a stop procedure, not proof that an entire business workflow has stopped.

• IETF RFC 7009

For the pilot, nominate an operational owner who can suspend the workflow and a technical owner who can verify the resulting state. Run a drill with a clarification message waiting in the queue. Confirm whether it was cancelled, held or already delivered. If a response is missing, investigate the receiving system before automatically resending it.

Record the observed stop time and any actions that remained in progress. The release decision should use the tested behavior of this implementation. A generic promise of an immediate kill switch leaves the purchasing team without an operating procedure when the connection behaves differently.

Evaluate useful work and unresolved work together

A pilot should show what happens to the purchasing task after the draft is produced. For this example, useful measures include buyer review time, comparisons accepted without substantive correction, cases returned for missing information, and unresolved messages whose delivery state is unknown.

Review these alongside the time the agent appears to save. A fast comparison that needs extensive repair may move effort from preparation to checking. An appropriate escalation may be a successful outcome even though the agent did not finish the task independently.

Choose the acceptance thresholds with the purchasing owner before the trial. Use a representative set of quotations, including conflicting delivery terms, incomplete attachments and requests that cross an entity boundary. Compare results with the current process. There is no universal success percentage offered here, and no client performance claim.

What should leadership approve?

Approve a specific workflow, its delegation brief and the evidence required to expand it. A useful first review can fit around four questions:

1. Can the process owner explain the agent’s permitted actions in ordinary business language?
2. Can the delivery team demonstrate those boundaries in the connected systems?
3. Can the operational team identify unfinished work and execute the stop procedure?
4. Does the trial show enough useful work, after review and exception handling, to justify the next release?

The next release may add another supplier group, another legal entity or permission for a narrowly defined action. Treat each expansion as a change to the operating agreement. That gives leadership a clear decision about where greater autonomy is justified.

Bridges’ Intelligent Automation & Agentic AI, AI Strategy, Readiness & Enablement and Cybersecurity capabilities connect these business decisions with implementation. Talk to Bridges about defining an agent’s role in a workflow your organization already understands.

• Intelligent Automation & Agentic AI
• AI Strategy, Readiness & Enablement
• Cybersecurity
• Talk to Bridges

Related reading

• The UAE’s Agentic AI Framework: A 90-Day Readiness Plan for Businesses
• Zero Trust for GCC Enterprises: Where to Start
• Agentic AI for the CFO Office

About this article

Sources were checked on 17 September 2026. The delegation brief, procurement scenario and acceptance exercises are original illustrative recommendations, not descriptions of client engagements. Sources support the technical distinctions and dated announcements; the business application is our analysis.