AI agents need authority, not instructions

Most AI agents in professional services are governed by intent rather than control, which is a comfortable illusion until those agents are given access to real systems, real data, and real budgets.

We tell them what they should do, what they should avoid, and how they ought to behave, then quietly grant them capabilities that would never be left unchecked in any other part of the firm. That tension is often framed as cautious innovation, but it is nothing of the sort. It is a governance failure caused by treating a control problem as if it were a prompting problem.

Professional services already understand delegated authority. Juniors do some things. Seniors do others. Final responsibility sits with named individuals, and systems exist precisely to enforce those boundaries when pressure, time, or optimism get in the way. AI agents should not be an exception.

Authority is the missing primitive

The core issue with most AI deployments is not model quality or technical sophistication, but where governance is being applied. Prompts are being asked to carry responsibilities they were never designed to handle.

Prompts express intent, which makes them useful for steering behaviour, but they are advisory by nature and incapable of enforcing boundaries once an agent can act. An authority-based approach starts from a more grounded question: what is this agent allowed to do, under what conditions, and with whose approval?

Answering that question forces clarity across four dimensions:

• Identity: the agent has a real system identity rather than a loosely defined persona
• Scope: its operation is explicitly tied to a matter, engagement, or workflow
• Permission: allowed and blocked actions are defined in advance
• Enforcement: actions are checked before execution, not rationalised afterwards

Once capability is separated from permission, risk stops being a matter of trust and becomes a matter of design.

A concrete walkthrough: an AI agent on a legal matter

Consider a mid-market corporate transaction involving a share purchase agreement, disclosure schedules, and supporting documents. It is routine work, but the consequences of advice leaking or actions being taken without review remain significant.

The firm introduces an AI agent into the matter, not as a chatbot, but as an internal assistant operating under a defined mandate. The first decision is not how the agent is prompted, but how it is authorised.

The agent is scoped to a single named matter, active only for the life of that matter, and operating under the supervision of a named lawyer. It can't drift between engagements or act anonymously, and everything it does is attributable by design.

Before the agent touches a document, its authority is set.

It may:

• read documents within the matter workspace
• extract clauses, obligations, and defined terms
• generate internal summaries and issue lists
• classify risks against an approved taxonomy
• reference internal precedents marked as reference-only

It may not:

• generate client advice or recommendations
• draft outbound communications
• access material outside the matter
• send anything externally
• exceed a defined cost budget

These constraints are not instructions buried in a prompt. They are enforced by the system.

What day-to-day use actually looks like

A junior lawyer uploads the SPA and asks for a summary of key obligations. The agent produces an internal summary, which sits comfortably within its authority.

The junior then asks whether a particular clause exposes the client to post-completion liability. The agent can explain how the clause operates, reference similar provisions from precedent documents, and highlight risk factors, but it can't answer the question in the form of advice.

If the request drifts into a recommendation, the system blocks the response and explains why. There is no hedging, no disclaimer, and no attempt to sound helpful while crossing the line. The boundary is clear, enforced, and visible.

This is the moment most demos avoid and it's really the moment that matters in the scheme of things.

Enforcement, budgets, and audit

When an action is blocked, the system records what was attempted, why it was blocked, which policy applied, and who initiated the request. That record is not overhead, rather it is the governance layer firms should routinely ask for and rarely receive.

Budgets behave in the same way. When the agent reaches its cost cap, it stops and requests authorisation to continue. This mirrors existing professional services controls around time recording and scope management, which is why it feels familiar rather than restrictive.

The mandate, written down

In practical terms, this is the artefact firms should be able to point to:

• a named role for the agent
• a clearly defined scope, usually a single matter
• an explicit list of allowed and blocked actions
• defined data access boundaries
• a fixed budget and escalation path
• a named supervising individual
• full logging of actions and enforcement events

If that artefact does not exist, governance is largely performative.

Why this works better than prompt-based governance

Most current deployments blur a dangerous line by allowing agents to do almost everything while asking them not to. Scope is implied rather than enforced, budgets are soft, and logs focus on outputs rather than authority.

An authority based model reverses that logic. Capability does not imply permission as prompts express intent, while systems enforce control.

This fits professional services because it mirrors how they already operate, with delegated authority, budget discipline, and auditability taking precedence over novelty.

Where firms can get this wrong

Authority alone does not guarantee quality. Overly restrictive mandates can kill off adoption, while vague ones leak risk. Someone must own policy design, and that responsibility sits between legal, risk, and product rather than neatly within IT.

Hard controls still require judgement, but they ensure that judgement is explicit rather than assumed.

The critical change is not technical. Firms need to stop asking AI systems to behave responsibly and start deciding, deliberately and explicitly, what authority they are allowed to exercise.

Once that line is drawn, cost control becomes straightforward, risk discussions become concrete, and adoption improves because people understand the edges.

The firms that get this right will not be the ones with the most impressive demonstrations. They will be the ones who can say, calmly and defensibly, that an AI system was only ever allowed to do a specific set of things, and that the evidence supports it.