Capability and authority are different questions
A model may be capable of drafting a supplier instruction, evaluating an applicant or changing a customer record. That does not mean it should be authorised to send, decide or modify anything without review. Capability describes what a system can achieve. Authority describes what the organisation permits it to do.
This distinction becomes critical when a language model is connected to tools. A conversational error may produce a poor answer. An agentic error can create a record, disclose information, initiate a transaction or trigger another system before anyone sees it.
The control question is not “Can the model do this?” It is “Under which conditions may this system do this on our behalf?”
Map authority as actions, objects and conditions
Broad labels such as “read access” or “human in the loop” are rarely precise enough. Useful authority boundaries describe the verbs an agent may perform, the objects those verbs may affect and the conditions that change the rule.
- Actions: read, draft, recommend, create, update, send, approve, pay or delete.
- Objects: which records, accounts, systems, people or categories of data are in scope.
- Conditions: value thresholds, confidence limits, risk classes, time windows and required approvals.
- Exceptions: situations that must stop, escalate or transfer to a named human role.
Use progressive authority, not a binary launch decision
Autonomy is not one setting. An organisation can expose the same underlying capability through different levels of authority: observation, recommendation, drafted action, supervised execution and bounded autonomous execution.
Starting with limited authority creates evidence under realistic conditions without making the first deployment carry the full operational consequence. Authority can then expand when behaviour, monitoring and intervention paths justify it. It should also be possible to contract authority quickly when the system, vendor or operating environment changes.
Controls must survive the model interface
A written instruction to “ask for approval” is not the same as an enforced approval step. Important limits should be implemented in the surrounding system wherever possible: identity and access controls, tool permissions, transaction limits, deterministic validation, segregated approval and reliable logging.
Prompts remain useful for shaping behaviour, but they should not carry control weight that the technical and organisational environment cannot support.
Evidence completes the control
An authority model is only useful if an organisation can tell whether it operated as intended. That requires records of what the agent was asked to do, the relevant context, the tools it called, the approvals it sought, the actions taken and the version of the system involved.
The purpose is not unlimited logging. It is an evidence trail proportionate to the consequence: enough to investigate behaviour, evaluate controls and explain a decision to the people accountable for it.
- Can we reconstruct a consequential action?
- Can we identify which rule allowed it?
- Can a reviewer see where human judgement entered?
- Can we suspend or narrow authority without rebuilding the system?
- Do we know what change would trigger reassessment?
