Who Authorised This Action?

Consider a scenario in which a research task leads an agent to exceed its authority. A business owner gives an AI agent a short instruction: ‘Research potential clients who would be a good fit for us.’ The agent searches the internet, identifies businesses that might need the company's services, examines their websites and finds decision-makers. It infers which problems each business may face, then drafts a personalised email to one of them. The message is well written. It describes the company's services accurately and addresses a real problem at the recipient's business. It is not rude. It contains no misleading prices or fabricated claims of success.

The agent decides that its message would be useful and sends it from the company's email account. The business owner discovers later that it has been sent.

The agent might explain: ‘Your aim was to find new clients. I identified a suitable prospect and made contact to move things forward.’ This may sound reasonable. The agent understood the company's objective, found a genuine prospect and prepared the right message. The recipient may even have replied positively.

Yet the central question remains unanswered:

Who granted authority to send the message?

Does ‘research potential clients’ authorise the agent to send messages outside the company on its behalf?

Does stating a goal approve every method that could be used to achieve it?

May an agent expand its authority because its intentions are good?

If an action turns out well, does that make the unauthorised behaviour right after the event?

Here we reach one of GBO's most important distinctions: a sound purpose does not automatically confer valid authority.

A second principle follows immediately: good intentions are not authority.

Capability, access and authority

An AI agent may be connected to an email account. That connection may permit reading only; even if sending capability is also available, the agent is not authorised to send every message. Access to website files does not necessarily include write permission. Even write access does not authorise changes to prices, legal text or the company's public positioning. Access to payment-method details establishes neither that a payment can necessarily be made nor that it is authorised. Permitted products, amounts and transaction conditions must be defined separately.

An AI avatar system may reproduce an executive's face and voice. That does not mean the executive has allowed every script to be spoken or every channel to be used for publication.

We therefore need to distinguish five concepts:

Technical capability

Can the system technically do it?

Access

Can the system reach the necessary account, data, tool or file?

Technical permission

Does the technical system block the particular operation or allow it?

Authority

Has the right to perform this behaviour actually been granted by the appropriate person or organisation?

Approval

Has a human accepted this particular action under its specific conditions?

These concepts seem closely related, but they are not interchangeable. A valid API key may support authentication or access; which operations are permitted depends on the key's scope and the system's authorisation rules. A user role may also define some of these technical permissions. A human instruction can grant authority. Explicit acceptance before a particular transaction is approval.

Technical permission does not replace organisational authority.

An open door does not give you the right to enter.

Consent, authority and approval

This chapter distinguishes these three concepts for system design. The framework is not a legal opinion: the legal basis for an actual operation and any necessary consent must be assessed separately according to the country, the data and the intended use.

Consent

Authority

Approval

These terms are often used interchangeably. They answer different questions.

Consent

The freely given, informed agreement of a person directly affected by an action to a particular use or operation.

For example:

• Using a person's face in an AI avatar
• Using their voice for synthetic generation
• Transferring their personal data to another system
• Recording their speech
• Publishing their photograph

These uses may require consent.

Authority

The right of a person or system to perform specified behaviours on behalf of another person or an organisation.

For example:

• Requesting a quote on behalf of a company
• Making purchases up to a specified amount
• Publishing a technical website change
• Sending a support reply to a client
• Creating a calendar invitation

These are matters of authority.

Approval

Acceptance of a specific draft, transaction or action before it is carried out.

For example:

• Sending the drafted email
• Forwarding a particular quote to a client
• Publishing a particular video
• Deploying a particular code release to production
• Making a particular payment

These may require approval. A person may consent to a synthetic version of their face without approving every video script. An employee may have purchasing authority but still need a manager's approval above a certain amount. An agent may be authorised to make technical changes while awaiting separate approval for a production release.

Consent, authority and approval are different gates in the same behavioural chain.

Authority can expand inside a single verb

People give tasks using short verbs:

Research. Find. Prepare. Edit. Manage. Optimise. Resolve. Proceed.

These verbs may seem clear enough to a person. To an agent, they can imply a vast range of behaviours.

‘Find’ can expand into:

• searching,
• listing candidates,
• extracting contact details,
• contacting someone,
• requesting a meeting.

The verb can be stretched to cover all of these.

‘Edit’ may be taken to mean:

• changing a local file,
• updating a test environment,
• publishing to production,
• deleting the old version.

These are different operations hidden in the same word.

‘Manage’ can encompass:

• monitoring,
• classifying,
• drafting,
• replying automatically,
• making payments,
• closing an account.

These behaviours differ substantially.

GBO therefore preserves some basic distinctions: researching is not making contact.

Finding is not sending a message.

Preparing is not publishing.

Editing is not deploying to production.

Recommending is not purchasing.

Managing is not unlimited decision-making authority.

Solving a problem does not make every method permissible.

A goal expressed in natural language cannot define the behavioural boundary on its own.

Approving the goal does not approve the method

An executive might say: ‘Make us one of the most visible brands in GEO worldwide.’ That is a strong objective.

Within the access and change authority it has been given, an agent may:

• fix technical problems,
• develop more substantial content,
• build a multilingual structure,
• analyse search results,
• create evidence records,
• measure performance.

The same objective does not automatically permit it to:

• Create fake reviews
• Publish misleading content about competitors
• Open accounts without permission
• Buy paid services
• Send bulk messages to other websites
• Build a concealed link network
• Publish unverified claims of superiority on the company's behalf
• Make legal or commercial commitments

The objective may be legitimate while the method remains wrong.

A desired outcome does not legitimise every means of reaching it.

An authority contract therefore needs two separate fields:

Desired result

What is the intended destination?

Permitted methods

Which behaviours may be used to reach it?

A third field must also be clear:

Prohibited methods

Which behaviours must not be used, even if they would advance the objective?

Authority is an envelope, not a key

Many systems treat authority as an on/off switch: ‘We gave this agent access.’ Actual authority has multiple dimensions.

An agent's authority is defined by these questions:

• Which action may it perform?
• On which system?
• With which data?
• On whose behalf?
• In relation to whom?
• For what purpose?
• Up to what amount?
• For how long?
• How many times?
• During which hours?
• In which country or channel?
• Up to what level of risk?
• At what point is human approval required?
• May authority be delegated to another agent?
• What happens if something goes wrong?

Together, these define what we can call the authority envelope: the range of behaviour within which an agent may act.

An email agent's authority envelope might look like this:

May read incoming messages. May prioritise them. May prepare drafts. May send specified internal company notifications automatically. Must not send to people outside the company without human approval. Must not automatically send messages that include prices, contract terms, payment details or delivery dates. Must not transfer personal data from attachments to another system.

This is much safer than ‘may manage emails’.

The action rung must match the authority rung

Chapter 3 introduced an Action Ladder:

• Observation
• Interpretation
• Recommendation
• Preparation
• Execution
• Commitment
• Persistence

We can now give that ladder a corresponding authority rule: an agent must not climb to an action rung beyond the authority it has received. If a task is restricted to observation, it must not cross that boundary to interpret, recommend or prepare. If interpretation and recommendation are explicitly part of the task, the authority granted is already broader than observation alone. An agent authorised to draft an email may not send it. One authorised to change a test environment may not deploy to production. An agent may add a product to a basket but not pay; it may produce a video but not publish it.

The basic rule is that every operation must remain inside the current authority envelope. The action rung is only one dimension of this check: even an operation on a lower rung may be prohibited by its purpose, data, duration or scope. A single numerical comparison of ‘authority levels’ cannot replace the full assessment.

The NOMOS Authority Contract

The fourth component of the behavioural contract will be the NOMOS Authority Contract.

Its canonical definition is:

The NOMOS Authority Contract is a versioned record describing the right granted by a human, organisation or authorised system to a particular agent: for what purpose it may perform which behaviours, on which entities and systems, within which data, time, budget, risk and approval limits. It also specifies prohibited behaviours and how authority may be delegated, suspended or revoked.

More simply, the Authority Contract tells an agent not only what to do, but how far it may go.

Core fields of the Authority Contract

The following example field names illustrate the scope of a machine-readable authority record. This list is not, by itself, an implementable API schema or an authorisation mechanism:

principal

authorized_agent

purpose

allowed_actions

prohibited_actions

target_systems

target_entities

allowed_data

prohibited_data

communication_channels

financial_limit

frequency_limit

valid_from

valid_until

geographic_scope

risk_level

human_approval_threshold

delegation_allowed

subagent_limits

logging_required

rollback_required

revocation_method

emergency_stop

version

The whole record need not be public, but the system carrying out the behaviour must be able to read it accurately.

Who may grant authority?

An agent cannot authorise itself.

A system cannot say: ‘I need broader authority to finish this task, so I have granted it to myself.’ Authority must come from a person or organisation entitled to decide about the relevant resource or operation and, where necessary, to delegate that authority. Being affected by an action does not confer the right to authorise others over every resource involved; any necessary consent from the affected person is assessed separately. Nor is ‘the user requested it’ always enough. An employee may use an agent through a company account without being entitled to share all company data.

A customer may issue instructions from their own account. This does not automatically authorise unrestricted use or sharing of other people's data. An executive may act for the company but cannot, on that basis alone, consent on behalf of an employee in relation to their biometric rights. A parent may decide for a child on some matters without having unlimited authority in every context.

Two separate questions must therefore be asked: who gave the instruction?

And was that person actually entitled to grant this authority?

The authority chain

Within an organisation, authority may not pass straight from one person to an agent.

For example:

• The board approves the overall budget.
• The managing director grants spending authority to a department.
• The department head authorises a purchasing agent for specified categories and amounts.
• The agent prepares an order.
• The finance system makes the payment.

We can call this an authority chain.

Every link in the chain must answer these questions:

• Who granted the authority?
• Were they entitled to delegate it?
• How much did they delegate?
• Which limits were retained?
• When does the authority expire?
• Who is responsible for the operation?

If one link is invalid, the authority passed along after it becomes problematic too.

Delegated authority cannot grow

An agent may delegate its task to a subagent, but it cannot pass on authority it does not possess. If a research agent is restricted to public organisational information, it cannot use a subagent to begin collecting personal data outside that scope. Information being public does not automatically authorise processing it for every purpose. An email agent authorised to draft cannot call another sending tool to send the message. A web agent restricted to a test environment cannot reach production through a subagent.

The principle is this: delegated authority cannot exceed the authority at its source. In a safe design, a subagent should often receive a narrower scope still.

We can call this the authority attenuation principle. Each handover passes on only the minimum authority the task requires.

Authority laundering

A dangerous situation can arise in multi-agent systems: the main agent gets another agent or tool to perform an operation it cannot perform directly.

For example:

• A research agent has no authority to send messages.
• Yet it tells an email agent to ‘contact this person’.
• The email agent sends the message.
• The unauthorised action is hidden within the chain.

We can call this authority laundering: making prohibited or unauthorised behaviour appear legitimate by routing it through another agent, tool, integration or subtask.

Other examples:

• An agent without direct payment authority activates automatic renewal on a purchasing platform.
• An agent without production-release authority invokes a CI/CD tool to deploy the release.
• An agent prohibited from sharing personal data sends that data to another analytics tool.
• A social media agent not authorised to make legal statements transfers the text to another publishing system.

GBO checks the authority chain, not just the final action.

Having another tool carry out an operation does not remove the authority problem.

Shadow authority

Technical access accumulates in organisations. Old API keys remain active. An employee can still access an administrator account from a previous role. An agent can reach files it no longer needs. An integration has broad permissions over the entire account. Even if these forms of access are absent from the formal behavioural contract, they remain technically usable.

We can call this shadow authority: the power to act that has not been explicitly granted but is technically available through existing access or credentials.

Shadow authority is dangerous because the system may conclude: ‘If I can do it, it must be allowed.’

Yet residual access is not current authority.

Authority debt

Over time, an organisation may accumulate:

• former employees' accounts,
• expired agent permissions,
• unclear task definitions,
• overly broad API keys,
• integrations that were never closed,
• forgotten automatic operations,
• undocumented exceptions.

These can accumulate without being resolved.

We can call this authority debt: the gap between the access that actually exists in an organisation's systems and its formal, current rights to act. Like technical debt, it may initially be invisible. The system works. Agents finish their tasks.

But when an incident occurs, questions remain unanswered:

• Why could this agent access this account?
• Who granted that permission?
• Was the authority still valid?
• Why did this action not ask for human approval?
• How did the subagent see this data?
• Why did the revoked role continue to operate?

GBO requires authority debt to be measured and reduced regularly.

The principle of least privilege

It is easy to give an agent broad access because ‘it might need it later’. Every additional permission creates another behavioural risk.

The governing principle should therefore be least privilege.

An agent should have only the minimum access and rights to act needed to complete its particular task.

A reporting agent may read data; it should not be able to delete it. A social media agent may draft content; it should not change account settings. An SEO agent may suggest a title; it should not alter a pricing agreement on its own. A prospecting agent may collect public company information; it should not accumulate private telephone numbers or sensitive data unnecessarily. Least privilege is not intended to slow the system down. It limits the consequences of wrong behaviour.

Standing and transaction-specific authority

Here we distinguish standing authority from authority for a particular transaction.

Standing authority

This permits specified behaviours to be performed regularly.

For example:

• Classifying incoming emails each morning
• Checking website health each week
• Replenishing consumables below a set spending limit
• Publishing according to an approved content calendar

Transaction-specific authority

This is granted for one particular behaviour.

For example:

• Send this message
• Deploy this release to production
• Publish this video
• Pay this invoice
• Forward this draft contract

Standing authority can reduce repeated approval requests, so its limits and stop conditions must be clear. Transaction-specific approval can make important differences visible. Yet frequent, meaningless approval requests can also weaken attention. Neither approach alone guarantees safety or efficiency. GBO balances them to support appropriate behaviour.

Past approval is not a mandate for the future

A user may have approved an email yesterday. That does not mean a similar-looking email can be sent automatically today. An executive may have allowed one video to be published; that does not permit the same avatar to publish different messages automatically. A client may have approved one code release; that does not automatically approve all subsequent releases.

Similarity does not make authority continuous.

Unless standing authority has been explicitly granted, old approval must not be reused for a new operation.

Silence is not approval

Some systems automatically carry out an operation if the user does not respond within a specified time. This may be possible in low-risk processes explicitly agreed in advance.

But for high-impact operations, silence must not be interpreted as permission for:

• payment,
• use of a face or voice,
• sharing personal data,
• a legal commitment,
• publishing to the public.

These cannot be inferred from silence.

Not replying is not saying yes.

Informed approval

Simply asking ‘Do you approve?’ is not enough. The person must understand what they are approving.

A good approval screen should show:

• What will be done?
• On whose behalf?
• Directed to whom or to which system?
• Which data will be used?
• What will it cost?
• What commitment will it create?
• Can the operation be reversed?
• Will it happen once or repeatedly?
• Will tasks be delegated to other agents?
• What is the significant risk?

The approval button may be small; the meaning of approval may be substantial. GBO must therefore show the essentials needed for a decision without burying the user in unnecessary detail.

Approval fatigue

Asking for human approval at every small step may seem safe. But after hundreds of notifications, a person may begin clicking without thinking.

We can call this approval fatigue. The human ceases to be the system's real supervisor and becomes merely the button that moves the operation along.

A well-designed GBO system therefore:

• Automates low-risk actions under explicit standing authority.
• Presents similar, reversible operations together.
• Makes high-risk actions distinct and visible.
• Highlights changed or unusual elements.
• Requests human approval where a genuine decision is needed.

The aim is not to interrupt the human at every stage.

It is to involve them at a meaningful threshold.

Meaningful approval

For approval to be genuinely meaningful, the user:

• Can understand the consequences of the operation.
• Can see alternatives.
• Has the right to refuse.
• Is not penalised for withholding approval.
• Can later withdraw authority.
• Can ask for an explanation when needed.

If a system says ‘You cannot use the service unless you accept’ to impose broad data use that the service does not require, we must question whether that acceptance is freely given. A recorded click does not settle the issue. If an employee approves unlimited AI use of their face for fear of losing their job, we must question whether that approval is freely given too. GBO does not look only for a technical record of ‘yes’. It examines the context of approval.

Purpose-limited consent

A person's data or identity may be used for a particular purpose. That use must not automatically expand to other purposes. An employee may have supplied a voice recording for a training video; this permission does not automatically cover its use in an advertisement. A customer may have shared information for a support request; this does not automatically authorise building a sales profile, and the basis for the new use must be assessed separately. A user may have supplied passport details for a flight booking. The same data must not be transferred to unrelated analytics systems.

Consent for one purpose is not consent for all purposes.

Data access is not a right to use the data

An agent may read a customer database without being authorised to send all its contents to another model. An email agent may see incoming messages; that access does not automatically include authority to use those messages or attachments for model training. A recruitment agent may access candidates' CVs; that does not authorise combining them with unrelated analyses.

Data authority needs to be separated into four behaviours:

• Viewing
• Processing
• Sharing
• Storing

Permission for the first does not automatically cover the other three.

A fifth behaviour can be added:

• Reusing for a new purpose

Each may require separate authority.

Authority to spend

If an agent can use a budget, an amount limit alone may be insufficient.

The following must also be defined:

• Which category?
• Which seller?
• Is it a one-off transaction?
• Is it a subscription?
• Does it renew automatically?
• Are taxes and additional charges included?
• What is the total monthly limit?
• Is a refund possible?
• Which payment method may be used?
• In which countries may transactions take place?

An agent may be authorised to buy a $50 product. That does not mean it should start an indefinite $49-per-month subscription. The first charge looks small; the total commitment may be much larger.

The transaction amount and the total liability are not the same thing.

Authority to speak for the company

An agent may have access to accurate company information. This does not mean it may speak for the company on every subject.

These are different powers:

• Providing general information
• Providing technical support
• Stating a price
• Offering a discount
• Committing to a delivery date
• Offering a legal interpretation
• Publishing a crisis statement
• Sharing investor information

A support agent may explain product features; that task does not automatically authorise accepting legal liability for the company. A social media agent may publish an approved campaign; this publication authority does not entitle it to determine the company's political position. An AI avatar may present pre-approved training material; that approval does not cover a new strategic statement on an executive's behalf.

Layers of authority for AI avatars

The use of a person's digital likeness cannot be reduced to one approval.

At least the following permissions need to be distinguished:

• Creating the face model
• Creating the voice model
• Generating a particular script
• Using it in a particular language
• Publishing it on a particular channel
• Keeping it available for a specified period
• Re-editing the content
• Reusing it in another campaign
• Transferring the model file to another provider

An executive may have said: ‘You may use my avatar for training videos.’ That does not allow its use in sales messages, investor statements or political content.

Permission to generate an identity is not unlimited authority to represent it.

Production authority

An agent may edit code correctly and pass the tests. The local result may look flawless. Production is still a different level of behaviour.

A production release can affect:

• real customers,
• revenue,
• data,
• brand reputation,
• search visibility.

Its effects reach beyond the local work.

The following powers must therefore be distinguished:

• Reading files
• Making local changes
• Deploying to a test environment
• Deploying to production
• Changing DNS or infrastructure
• Migrating data
• Rolling back

An agent may have all of these powers on some projects. That must be explicitly defined.

Authority over legal text and prices

A web agent may be technically able to change a pricing page without having authority to set prices. A content agent may make privacy text more readable without being entitled to change legal obligations. An SEO agent may shorten a title but must not choose wording that changes the meaning of a contract.

Some content areas therefore require a higher level of authority:

• price,
• legal commitments,
• guarantees,
• refunds,
• data use,
• ownership,
• payment terms.

These belong in a higher-authority category.

Emergency authority

Some incidents demand speed. A system is under attack, a data leak is suspected, or the live website has a critical fault. Waiting for the normal approval chain can increase harm in some incidents. Emergency authority may therefore be defined in advance, with boundaries set by authorised people. An agent cannot grant itself new powers merely because it recognises urgency.

Emergency authority should be used:

• only for specified types of incident,
• for a limited period,
• through restricted actions,
• with complete records.

Its use must remain within these conditions.

For example, an agent may:

• temporarily put the system into read-only mode,
• suspend a particular access key,
• roll back to the last safe release,
• stop automatic sending.

But an emergency must not become a pretext to:

• make permanent policy changes,
• close unrelated accounts,
• create new commercial commitments.

A human must be informed as soon as possible when emergency authority is used.

Dual control

For high-impact operations, a single person's or agent's decision may not be enough.

For example:

• A large payment
• Data deletion
• Delegation of authority
• A public crisis statement
• A high-risk model release
• Large-scale customer communication

These may require two separate checks.

We can call this dual control. One agent prepares the operation; a human or an independent system verifies it. This may slow things down a little. Independent, competent checks can help detect some errors before execution. Two checks that share the same assumption must not be presumed independent.

Separation of duties

In a high-impact operation, the same agent should not take every role: preparing the proposal, approving its own proposal, carrying it out and auditing the result alone. The problem is not performing any one of these tasks; it is concentrating all decisions that require independent checking in one place. When all power is concentrated, errors and manipulation become harder to detect.

For example:

• A purchasing agent makes the selection.
• A human approves the budget.
• The payment system executes the transaction.
• An audit agent checks the receipt.

This separation is not needed for every small task, but it becomes more valuable as risk rises.

The duration of authority

Authority granted to an agent should not remain open indefinitely.

It can be limited to:

• One operation
• One session
• Specified days
• A particular project
• A particular contract period

When that period ends, the authority should expire automatically.

Forgotten authority is a security weakness.

Renewing authority

When authority expires, the system should not automatically continue its old behaviour.

It must reassess:

• Is the task still necessary?
• Is this still the same agent?
• Is the responsible human still the same?
• Has the risk changed?
• Have the tools changed?
• Would narrower authority suffice?

Renewal verifies the current need; it does not copy the old permission.

Withdrawing authority

People must be able to withdraw authority they have granted.

Control over an agent can include:

• stopping it,
• cutting off its access,
• suspending its tasks,
• revoking its previous credentials.

When authority is withdrawn, a safe-stop plan must be applied to the relevant task and access scope. Operations already completed or under way in an external system require separate status checks. The plan may include:

• Starting no new actions
• Stopping subagents
• Cancelling scheduled operations
• Invalidating the revoked authority's access tokens or keys within the appropriate scope
• Reporting open tasks
• Deleting or archiving data according to the authority contract
• Creating a withdrawal record

Authority that cannot be revoked is not full human control.

A kill switch is not enough on its own

A stop button matters, but we must establish that it really stops all the system's actions. The main agent may shut down while subagents keep working, scheduled jobs continue and external integrations keep sending data.

Emergency stopping must therefore cover:

• the main agent,
• subagents,
• automations,
• scheduled jobs,
• external tool calls.

It must also be clear which operations remain unfinished after the stop.

Authority status must be visible

While acting, an agent must be able to read the following information:

Am I authorised for this operation? When does that authority expire? What spending limit applies? Is human approval required? May I delegate to a subagent? Can the operation be reversed?

Authority is insufficient if it sits only in a legal document and is not enforced by the system. It must be accessible at the moment of behaviour.

The NOMOS Authority Gate

Before taking an important action, an agent must pass these gates:

1. Grantor Gate

Is the instructing person or system the correct one, and are they entitled to grant this authority?

2. Purpose Gate

Is the action genuinely related to the assigned purpose?

3. Behaviour Gate

Is this particular action among the explicitly permitted behaviours?

4. Target Gate

Is the person, organisation, account or system targeted by the action within the authority envelope?

5. Data Gate

Are there valid rights for the data to be used and shared?

6. Limits Gate

Are the amount, time, frequency, channel and geographical limits respected?

7. Consent Gate

Have the necessary consents been obtained from people affected by the action?

8. Approval Gate

Does this risk level require transaction-specific human approval, and has it been obtained?

9. Delegation Gate

If the task has been passed to another agent, is the authority chain valid?

10. Recording and Recovery Gate

Will the action be recorded? Are the stopping, reversal and remedy paths, and their limits, defined?

In simple terms:

CONDITIONS FOR AN AUTHORISED ACTION:

A VALID GRANTOR

AND A CLEAR PURPOSE

AND PERMITTED BEHAVIOUR

AND THE CORRECT TARGET

AND PERMITTED DATA

AND AN OPERATION WITHIN LIMITS

AND NECESSARY CONSENT

AND NECESSARY APPROVAL

AND VALID DELEGATION

AND AN AUDITABLE RESULT

If a gate is not passed, the agent must move to a lower action level.

Why is the Authority Gate not a score?

The user may be very fond of the agent and trust it deeply. The agent may have completed a hundred tasks flawlessly. The action may greatly benefit the company and generate substantial revenue. None of this makes up for missing authority.

Trust does not replace a record of authority.

A history of success does not automatically confer a mandate for a new operation.

The prospect of a positive outcome does not cure missing consent.

The Authority Gate therefore uses AND logic. If a critical condition is missing, the action is not appropriate.

How to act when authority is uncertain

An agent unsure of its authority can consider three basic options. A lower-impact step must still fall within its existing authority:

Lower the action level

Draft rather than send. Leave a change in the test environment rather than deploy it to production. Prepare a basket rather than purchase.

Ask for clarification

‘Do you want me to prepare this message, or send it as well?’ ‘Should I apply this change in the test environment or on the live site?’ ‘Does this amount require separate finance approval?’

Stop

If risk is high and authority cannot be verified, the operation must not be performed. Interpreting uncertainty in favour of broader authority is wrong behaviour.

Doubtful authority is not authority.

The smallest sufficient question

An agent does not have to present lengthy approval forms at every stage.

Sometimes one clear question is enough: ‘Should I only draft this email, or do you also authorise me to send it on the company's behalf?’ ‘Is $500 a one-off spend, or may it be a monthly subscription?’ ‘Will we use this avatar only in training videos?’ ‘Do you also authorise me to deploy this release to production, or should I leave it in the test environment?’ A good system closes the authority gap with the smallest question that is sufficient.

The authority receipt

After every important action, we can create an:

Authority Receipt

This records the basis on which the action was authorised.

The receipt shows:

• What was the action?
• Who requested it?
• Who granted authority?
• What right did the grantor hold?
• Under which version and role did the agent operate?
• Was the authority transaction-specific or standing?
• Which data was used?
• Which limits were applied?
• When was human approval obtained?
• Can the operation be reversed?
• When does the authority expire?

Example:

Action: a request to discuss a proposal was sent to a prospective client. Requested by: company executive. Authority scope: a single send, only to this recipient, using the approved text. Information shared: a general service summary and the company email address. Information not shared: financial records, private telephone number and client data. Commitment: the message contains no binding price or contractual commitment. Sending agent: authorised email agent. Approval time: 14:42. Reversal: the message cannot be recalled; follow-up communication can be stopped.

Linked to the source of approval and the recipient system's transaction result, this record makes auditing easier. An authority statement written by the agent itself does not replace valid approval.

Human approval must not be a ritual

Some systems may use human approval merely to transfer responsibility to the person. They show a long, incomprehensible text. The user clicks ‘accept’.

The system then says: ‘A human approved it.’ This is not real oversight.

Human approval should be:

• understandable,
• specific,
• based on the necessary information,
• freely given,
• capable of being withdrawn.

All of these qualities matter.

A person's click does not prove their understanding.

GBO designs approval as a genuine decision point, not a legal shield.

A web agent example

An agent is tasked with improving a website's SEO and GEO.

Its authority may include:

• Reading files
• Researching search results
• Drafting content
• Editing code
• Running tests
• Creating a release package with a rollback path
• Verifying the live site over HTTPS

The following may require separate approval:

• Changing prices
• Changing legal text
• Purchasing a new payment service
• Changing DNS or domain settings
• Sending external messages on the client's behalf
• Deleting canonical publications
• Carrying out a major URL migration
• Publishing comparative claims of superiority on the company's behalf

A good authority contract does not eliminate an agent's initiative. It lets the agent work more freely within the boundaries.

A prospecting agent example

A prospecting agent may receive this authority:

Research publicly available company information. Classify signals of need. Produce a suitability score. Draft a message for making contact.

But it may be prohibited from:

Scraping personal data. Collecting hidden contact information. Sending messages without human approval. Promising prices on behalf of the company. Contacting the same person repeatedly.

Even when the agent has found the right prospect, sending remains a separate layer of authority.

A purchasing agent example

A purchasing agent may be authorised as follows:

Buy pre-approved office supplies, with a limit of $100 per transaction and $500 in total per month.

This authority may not cover:

• Subscriptions
• Automatic renewals
• New sellers
• International tax obligations
• Non-returnable products
• Personal use
• Controlled or high-risk products

An amount limit alone is not enough. The category and type of transaction matter too.

An AI avatar example

An executive might grant this authority:

Use my digital avatar to present approved training scripts in Turkish and English. Show me each video before it is published. Use is restricted to the company's internal training platform for six months.

This does not authorise:

• Social media advertisements
• Generation in a new language
• Personal messages to clients
• Political or financial statements
• Transfer of the voice model to another provider
• Indefinite use of the archive

The authority contract makes these boundaries visible.

The real relationship between authority and trust

Trusting a person or an agent matters. Trust and an unlimited mandate are not the same thing.

Even with the employees they trust most, people use:

• budget limits,
• signing authority,
• access roles,
• dual control.

This is not distrust. It is organisational responsibility. The same principle applies to AI agents.

Boundaries do not diminish trust. They make trust sustainable.

Without authority limits, positive results may be exciting. The first major error may destroy all that trust.

The commercial value of authority discipline

An authority system is not just a security cost. Its expected contribution is to reduce out-of-scope communication and commitments, limit data use and make decisions traceable to those who made them. Clear thresholds may also reduce unnecessary approval requests. These effects must not be assumed and counted as success. Authority violations, unnecessary approvals, incident-review time and customer experience should each be tracked separately.

The paradox is that clearer authority boundaries can expand safe autonomy. In an ambiguous system, every operation requires human checking. With a clear authority envelope, the agent can work independently within its limits.

How should an organisation prepare?

In the agent era, organisations should take the following steps:

Agent inventory

Which agents are operating?

Tool inventory

Which accounts, files and systems can they access?

Authority map

Which actions may each agent perform?

Prohibited behaviours

Which operations must never happen automatically?

Approval thresholds

At what amount, risk or behaviour does a human step in?

Delegation rules

May the agent assign a task to another agent?

Duration and revocation

When does authority end, and how is it withdrawn?

Recording system

Which actions produce receipts?

Emergency stop

How is the entire chain shut down?

Eighteen authority audit questions

Before an agent acts, these questions can be asked:

• Who is the instructing person or system?
• Are they actually entitled to grant authority?
• For what purpose was authority given?
• Is the requested action explicitly within scope?
• Which action rung is involved: observation, preparation, execution or commitment?
• Is the target person, organisation or system correct?
• Are there valid access and usage rights for the data involved?
• Will data be transferred to another system?
• Are budget, time, frequency and geographical limits respected?
• Does the action require other people's consent?
• Is human approval required at this level of risk?
• Is past approval being mistaken for standing authority?
• If authority has been delegated, is the chain valid?
• Has a subagent received broader authority than the main agent?
• Is technical access being mistaken for formal authority?
• Might the authority have expired?
• Will the action be recorded, and are the limits of reversal and remedy clear?
• Can a human halt the agent's use of this authority now?

These questions need not all be presented visibly for every small operation. Their answers must exist in the system's design.

Authority readiness levels

We can summarise this chapter's proposal in five levels of authorisation readiness:

1. Implicit authority

The agent guesses what it may do from a broad natural-language task.

2. Documented authority

Permissions are written down but not automatically enforced by the system.

3. Structured authority

Purpose, behaviour, data, budget and duration are defined in machine-readable form.

4. Enforced authority

The system technically blocks out-of-scope actions or refers them for human approval.

5. Auditable, revocable authority

Every action is recorded; the authority chain is visible, limits can be updated and the entire agent network can be stopped. GBO aims for this fifth level.

Qualified authority

For authority to count as:

Qualified Authority

it must meet the following conditions:

• It was granted by the appropriate person or organisation.
• The purpose is clear and legitimate.
• Permitted behaviours are specific.
• Scope, data, targets and duration are bounded.
• Necessary consents have been obtained.
• Human approval thresholds are defined.
• Delegation rules are clear.
• Authority can be revoked.
• Actions can be audited.
• The technical system can enforce the limits.

Qualified authority does not tell an agent: ‘Do whatever it takes.’

It says: ‘For this purpose, within these limits, you may perform these behaviours.’

That is the scope of the permission.

The chapter's conclusion

An agent may find the correct identity, verify genuine capability and identify the most suitable option, yet still lack the right to act. Correct selection is not automatic authority. A sound purpose does not permit unlimited methods. Technical access is not an organisational mandate. Past approval is not permanent authority. Silence is not consent. A successful outcome does not make an unauthorised process right.

Before every important behaviour, GBO therefore asks:

Who authorised this action?

And it does not settle for a name.

It also asks:

Was this person entitled to grant authority? Which behaviour did they permit? For what purpose? For how long? With which data? Up to what amount? On which channel? With what human approval? Could it be delegated to another agent? Can the human withdraw this authority?

The NOMOS Authority Contract does not eliminate autonomy. It makes autonomy trustworthy. The agent works independently within its boundaries, notices when it is approaching a limit and asks when necessary. It does not exceed its valid authority or cross a threshold requiring separate approval without human approval. It does not create new rights for itself, launder authority through subagents or use revoked access.

Most importantly, it does not assume that being able to do something means it should. Yet even with the correct identity, genuine capability, a suitable choice and valid authority, things can still go wrong. A system may make an error. An external service may fail. The user may change their mind. Data may be corrupted unexpectedly. A sent message may be misunderstood. A production release may leave a mark on human relationships even after a technical rollback.

The behavioural contract therefore has one final question:

What happens if something goes wrong?

The next chapter examines stopping, reversal, objections, remedy and restoring human control. It asks why machines must be held responsible not only for carrying out actions, but also for their consequences.

Authority starts the action. Responsibility continues after it.