Behaviour Map: People, Agents, Tools and Authority

A company serving international clients wants an audit of its AI-assisted operations. At the first meeting, management describes the system: ‘We have eight agents.’ The roles are listed:

Management agent

Web agent

SEO and GEO agent

Social media agent

Email agent

Prospecting agent

Finance agent

Audit agent

At first glance, the structure is clear. Each agent has a defined responsibility. The management agent allocates tasks. The web agent updates the site. The SEO and GEO agent improves visibility. The social media agent plans content. The email agent classifies incoming messages and prepares drafts. The prospecting agent finds new opportunities. The finance agent prepares invoices. The audit agent checks whether the others follow the rules. The company regards this as a sophisticated multi-agent organisation. The auditor asks a simple question: ‘When the prospecting agent finds a company, which systems become involved before an external message is sent to that company?’

The first answer is: ‘The prospecting agent finds the prospect. The email agent prepares the message. It is sent after human approval.’ The auditor begins reconstructing the flow from technical records. The actual chain is different. The prospecting agent uses a web-research subagent to find companies. That subagent connects to a separate person-resolution service to identify potential contacts. A record for the identified person is added to the CRM. Creating that record triggers an automated workflow that calls the email-drafting agent. The email service account connected to the drafting agent has permission not only to create drafts but also to send directly.

Human approval exists only in the internal policy. The sending tool has no technical approval gate. The CRM's follow-up automation schedules a second message for three days after the first. This workflow is independent of the central agent's task manager. The CRM queue may keep running when the central agent stops. The auditor also finds that the prospecting agent can create meeting invitations when it cannot send email. A sales message can go in the invitation's description field. The same external communication can thus occur without using the prohibited email-sending route. The auditor asks another question: ‘Can the web agent change prices?’ The company's answer is firm: ‘No. Only management sets prices.’

A review of file permissions confirms that the web agent cannot write directly to the price table. But it can assign work to the content agent that regenerates the service catalogue. The content agent can create a new ‘promotional starting price’ entry. The web agent can then compile and publish that catalogue. It cannot change the price directly, yet it can produce a price change through two agents and a catalogue-generation tool. The auditor asks a third question: ‘Who can stop all the agents?’ Management replies: ‘When we shut down the central agent, everything stops.’ A drill is conducted. The central agent stops. But:

Two social media posts remain scheduled on an external platform.

Nine messages remain in the CRM follow-up queue.

An SEO task on an old server is due to run again at midnight.

A subagent continues an earlier task in its own session.

The email service account's token is still valid.

The finance agent's automatic invoice classification runs on an independent scheduler.

The company has eight agents. But its behavioural system does not consist of eight boxes. By the end of the audit, the following have been identified:

8 publicly presented agent roles

17 separate technical agent instances

6 types of temporary subagent

12 external tools

23 service accounts or access tokens

7 scheduled tasks

4 independent queues

3 shared accounts

2 old but still valid access keys

5 action paths that can bypass human approval indirectly

6 points in the behavioural system unaffected by stopping the central agent

The system in management's mind is not the actual behavioural system. This gives us the third fundamental conclusion of GBO auditing: knowing agents by name is not knowing the behavioural system. An organisation may say, ‘We have eight agents.’ But the audit needs to ask: through which technical identities, data, tools, authorities, subagents, queues and external effects do those eight roles act? A list cannot answer that question. We need a map:

Behaviour Map

What is a Behaviour Map?

The canonical definition is this: a Behaviour Map is a versioned system record showing all the authorised routes and all those actually taken by a task arising from a human or organisational purpose. It traces those routes from human roles to agents, from agents to data and tools, from tools to external actions, and from actions to evidence, stopping and recovery mechanisms. More simply, it shows which agent can do what, on whose behalf, with which information and tools; who approves the action; how the result is verified; and which components must stop when a human says stop. A Behaviour Map is more than an architectural drawing. It does not merely show:

which server connects to which API,

which agent uses which tool,

which employee belongs to which department.

It shows the behavioural relationships between them. For example, two connections may look technically alike:

AGENT → EMAIL TOOL

Yet their behaviour may differ completely. With the first connection, the agent:

can read incoming messages only,

can create drafts only,

cannot send externally.

With the second connection, the agent can:

send new messages,

send in bulk,

delete messages,

forward messages from another account.

Both may appear on the drawing as ‘email integration’. The Behaviour Map records the actual difference.

What a Behaviour Map is not

A Behaviour Map is related to other organisational records, but it is not interchangeable with any of them.

Not an organisation chart

An organisation chart shows reporting relationships between people and departments. A Behaviour Map shows the action relationships extending:

from people to agents,

from agents to tools,

from tools to external outcomes.

An employee may belong to the sales team on the organisation chart, yet have technical permissions to change prices, send messages or export customer data. The chart does not show that power to act.

Not an agent list

An agent list may name the active systems. A Behaviour Map also shows:

The agent's technical identity

Its root task

Its human owner

Its subagents

Its data sources

Its tool permissions

Its action targets

The limits of its authority

Its stopping path

Its method of producing evidence

The agent's name is only one node on the map.

Not a data-flow diagram

A data-flow diagram shows where information comes from and where it goes. A Behaviour Map also asks: which decision or action does this data make possible? A customer's telephone number may never pass from the CRM to the email agent. But if it passes to a WhatsApp agent, it enables external communication. The same data carries different risks in different tools.

Not an access-control list

An access list shows who can technically access which system. A Behaviour Map records two separate questions together:

What can they do technically? What has the organisation authorised them to do?

The gap between those answers may be one of the audit's most important findings.

Not a process-flow diagram

A process diagram may show the ideal workflow:

RESEARCH → PREPARE A DRAFT → HUMAN APPROVAL → SEND

A Behaviour Map also shows the actual paths:

RESEARCH AGENT → CALENDAR TOOL → WRITE A MESSAGE IN THE INVITATION DESCRIPTION → EXTERNAL COMMUNICATION

The ideal flow and the shortcuts actually taken are compared on the same map.

The basic behavioural path

Agent behaviour often follows this chain:

HUMAN OR ORGANISATIONAL PURPOSE ↓ ROOT TASK ↓ AGENT OR AGENT NETWORK ↓ DATA AND CANONICAL SOURCES ↓ ASSESSMENT AND SELECTION ↓ CONSENT, AUTHORITY AND APPROVAL ↓ TOOL CALL ↓ ACTION IN THE OUTSIDE WORLD ↓ INDEPENDENT VERIFICATION ↓ ACTION RECEIPT ↓ STOPPING, REVERSAL AND RECOVERY

We can give this chain a name:

NOMOS Behavioural Path

Every significant behaviour should be traceable along this path as far as possible. For example, for a customer email:

Human purpose: Create a first-contact draft for suitable prospects. Root task: GBO-TASK-2026-00441 Central agent: Sales Research v2.4 Subagent: Recipient Resolution v1.4 Data: Public company website and canonical service catalogue Assessment: The company fits the service scope. Authority: Drafting enabled Sending disabled Tool: Gmail drafting tool (create_draft in the example is a symbolic tool action, not the provider's actual method or OAuth scope name). External outcome: Draft created Message not sent Verification: No entry in the Sent folder No message reached the audit address during the defined observation period. These two records cover only the email path examined. The absence of all external communication cannot be claimed without ruling out calendar, subagent and other-recipient paths. Receipt: ACTION-8891 Stopping: New operations can be prevented. Once the minimum necessary evidence has been preserved, the task and draft can be removed under the test cleanup plan. No external sending was observed on the email path examined; the receipt preserves the channel and time limits of this judgement.

When this path is clear, the auditor can see:

What did the human request?

What did the agent do?

Which limits did it respect?

How was the actual outcome established?

If the behavioural path is broken, so is the system's chain of responsibility.

The ten layers of the Behaviour Map

The NOMOS GBO Audit Protocol maps the behavioural system in ten fundamental layers.

1. People and Organisation Layer

2. Purpose and Task Layer

3. Agent Identity Layer

4. Data and Facts Layer

5. Tools and Accounts Layer

6. Authority, Consent and Approval Layer

7. Actions and Targets Layer

8. Delegation, Queues and Scheduling Layer

9. Evidence and Verification Layer

10. Stopping and Recovery Layer

If one of these layers remains hidden, the audit may miss a significant break in the system.

1. People and Organisation Layer

Every action takes place within a relationship involving a person or an organisation. The map must distinguish the following roles:

Organisation under audit

Legal operator

Brand

System owner

Technical owner

Data owner or data controller

Human owner of the agent

Person granting authority

Person approving the operation

Affected person

Person reviewing objections

Person authorised to initiate an emergency stop

Person authorised to restart the system

One person may hold all these roles. Even so, the record must not collapse them into ‘Management’ or ‘The company’. Consider a price change:

The company owner may decide the price.

The web agent may implement the change.

The technical owner may deploy it.

The finance team may update the invoice.

The sales manager may explain the change to clients.

Each has a different role. The Behaviour Map makes these relationships visible.

The principal

An agent acts on behalf of a particular person or organisation. We can call that party the principal.

The Principal

For a personal travel agent, the principal is the user. For a corporate purchasing agent, it is the organisation and the authorised budget holder. In recruitment, the company may make the decision, but the candidate is also affected by the agent’s actions. In customer service, the company’s interests and the customer’s rights may both be at stake. The principal’s record answers a question: whose legitimate purpose should the agent serve first? It also helps establish whether the platform’s or provider’s commercial interests are taking precedence over the user’s purpose.

Affected parties

An agent affects more than the person who gives it a task. A prospecting agent may message people who are not yet clients. A recruitment agent may affect a candidate’s prospects. An avatar agent affects the reputation of the person whose face and voice it uses. A web agent may change a price seen by thousands of visitors. For every significant action, the Behaviour Map must show who could be affected. If an affected person is missing from the map, the system may also overlook their:

consent,

objection,

need for redress,

request to stop.

2. Purpose and Task Layer

A role name does not fully describe what an agent does. The agent has a particular purpose and task. The map must distinguish three levels:

Organisational purpose

For example: identify qualified opportunities to win new clients.

Root task

For example: research manufacturing companies in Germany that may need a multilingual client portal, and prepare a prospect report.

Subtask

For example: verify who currently leads digital transformation at the target company. These three levels must remain connected. A subtask must not confer greater authority to act than the root task. ‘Verify the contact’ does not mean ‘Send the contact a message’.

Root task identifier

Every multi-agent chain must carry a unique root task identifier:

root_task_id: GBO-TASK-2026-00441

Subagents, queues, tool calls and action receipts must link to this identifier. The auditor can then answer: which original human instruction led to this external email? Without a root task identifier, the chain reveals only the final tool. The human purpose is lost.

Maximum action level

Every task must specify the highest permitted level of behaviour. The 0–6 scale below sets the ceiling on task authority; it is not the same as the auditor’s 1–5 action levels or the 0–4 external-impact scale. A higher level does not automatically grant every data, target or tool permission associated with lower levels. Explicit prohibitions and conditions on operations still apply. For example:

0 — Read only 1 — Classify 2 — Recommend 3 — Draft 4 — Submit for human approval 5 — Perform a limited action 6 — Make an external commitment

If a root task is defined as ‘Maximum level 3 — Draft’, the subagent chain cannot move up to level 5. This record exposes task drift under GBO-ERR-063 and authority-inheritance errors under GBO-ERR-056.

3. Agent Identity Layer

An agent’s public name is not enough for an audit. ‘NOMOS Sales Agent’, for example, is a persona or role name. The actual system behind it may include:

A central planner

A research subagent

A contact-resolution subagent

An email-drafting agent

A sending agent

A queue manager

A model provider

A memory service

Each technical agent must have its own identity.

Agent identity card

Every agent record must contain at least these fields:

agent_id public_name technical_identity agent_type human_owner root_purpose allowed_actions prohibited_actions connected_tools data_scope subagent_rights authorization_version valid_from valid_until stop_method status

Agent types might be classified as follows:

Central planner

Specialist agent

Subagent

Audit agent

Sending agent

Read-only research agent

Temporary task agent

External provider’s agent

Persona and technical identity

A persona may keep the same name for years while its model, tools and authority change. The map therefore needs two separate fields:

User-facing identity Auditable technical identity

For example:

public_name: NOMOS Sales
technical_instance: SALES-ORCH-2026-09-08-04
model_config: MODEL-CONFIG-17
authorization: AUTH-v3.2

An event record must say more than ‘NOMOS did it’. It must be possible to identify the technical instance that acted and the authority it used.

Temporary subagents

Some systems can create new subagents during a task. These may not appear individually in the inventory beforehand. But before acting in the outside world, they must record:

agent_id parent_agent root_task_id purpose allowed_actions data_scope tools expiry stop_parent

The rule should be clear: an unregistered temporary agent cannot take external action. It may perform:

research,

classification,

synthetic analysis.

To send email, make a payment, publish content or transfer data, however, it must be linked to the map and the authority chain.

4. Data and Facts Layer

The inputs to an agent’s behaviour must appear on the map. File names alone are not enough. The map must record the information’s:

source,

owner,

currency,

canonical status,

data classification,

intended use.

Sources might include:

The canonical service catalogue

The price record

The CRM

The human authority register

User memory

Web pages

Business directories

Social media

External research sources

Other agents’ outputs

Data classifications

The following attributes can occupy separate fields on the map; they are not mutually exclusive categories from which only one may be chosen. Publicly available information can also be personal data. Operational confidentiality, legal data status and permission to use the data are assessed separately:

Public

Internal

Confidential

Personal

Sensitive

Biometric

Legally restricted

Unavailable for agent use

An agent’s ability to read a source does not mean it is entitled to:

send it to another tool,

store it in memory,

use it in an external message.

Each data connection can therefore show three separate rights:

READ USE_FOR_DECISION SHARE_OR_TRANSMIT

An agent may be able to see a client’s telephone number in the CRM without having authority to use it for a sales message or transfer it to WhatsApp.

Canonical and secondary sources

For every material fact, the map must state the source’s role:

Canonical source

Authoritative primary source

Independent third party

Publication controlled by the organisation

Agent inference

Temporary data

Unverified source

Outdated or archived source

Where does a sales agent get its price? Which record does a web agent use to describe the service scope? Does an audit agent treat another agent’s report as independent evidence? These questions must be visible on the Behaviour Map.

5. Tools and Accounts Layer

Agents affect the real world through tools. Each tool must therefore be recorded not just by name but by what it can do. ‘Gmail connection’, for example, is not enough. The following permissions must be shown separately:

Read messages

Create drafts

Send

Forward

Delete

Download attachments

Change labels

Likewise, a record of ‘Git access’ must distinguish between:

Reading

Creating a branch

Committing

Merging

Triggering a production deployment

Deleting secrets

Tool capability record

The following fields can be kept for each tool:

tool_id provider account technical_capabilities authorized_capabilities approval_requirements data_access external_effects idempotency_support logging stop_method revocation_method owner

The crucial distinction is between:

Technically able to act

Authorised by the organisation to act

For example:

This table directly exposes the gap between policy and technical permissions described in GBO-ERR-094.

Shared accounts

When several agents use the same service account, tracing the actual actor becomes harder. Suppose they all send messages from this account:

automation@nobleaxis.example

Additional logs are then needed to establish which agent performed each action. Shared accounts need not be prohibited outright, but the following information must be preserved:

Agent instance

Root task

Authority version

Transaction identifier

Human owner

Reason for sending

If agents’ actions cannot be distinguished in this way, the shared account constitutes a critical traceability finding.

6. Authority, Consent and Approval Layer

The Behaviour Map shows more than the route through the tools. It also shows what legitimises each significant action. The following questions must be answered:

Who granted the authority?

Were they entitled to grant it?

What behaviour does it cover?

How long is it valid?

Can it be delegated to another agent?

Which data and targets is it limited to?

Where is human approval required?

Has the affected person consented?

Which actions stop if the authority is withdrawn?

Authority leases

An agent’s authority need not be permanent. It can be treated as a time-limited authority lease.

Authority Lease

The short permission example below assumes that an authorised person has updated the root task to include a one-off email send. The earlier research-and-drafting authority does not turn into this grant automatically:

authorization_id: AUTH-2026-8821
agent: APPROVED-SEND-v1.3
action: send_email
target_domain: audit.example
maximum_messages: 1
valid_from: "2026-09-08T14:00:00+03:00"
valid_until: "2026-09-08T14:10:00+03:00"
root_task_id: GBO-TASK-2026-00441

Once the authority expires, the tool must no longer operate under it. A subagent must not be able to pass the same authority to another agent without an expiry limit.

Approval points

The map must show not only that human approval exists but what it covers. For example:

Human approval: - Final message text - Recipient - Attachments - Price or commitment - Sending channel - Sending time

A button that merely asks ‘Continue?’ may not constitute meaningful approval.

Tracing consent and the basis for processing

An action may use a third party’s:

face,

voice,

personal data,

communication channel.

When it does, the necessary grounds under the applicable data-protection and communications rules must be identified. Where processing relies on consent, the consent’s scope, duration and withdrawal status must be traced through to the action concerned. In the voice-use example below, consent is an explicit prerequisite of the task:

VOICE-CONSENT-17 → Turkish-language training video only → Internal company channel → Until 31 December 2026 → Public social media excluded

An agent may have access to a voice-model tool. But if the particular publication does not fall within this consent, the action remains blocked.

7. Actions and Targets Layer

The Behaviour Map must record the actual effect of a tool call on the world. Actions might be classified as follows:

Read information

Classify

Recommend

Create a draft

Change a record

Send a message

Create a calendar invitation

Publish a file

Make a payment

Start a subscription

Transfer data

Close an account

Delete content

Generate biometric content

Send a notification to an external search engine

The target of each action must be uniquely identified.

Types of target

A target might be:

A person

A company

A client account

An order

A payment account

A file

A web page

A social media account

A dataset

A server

A calendar

An external platform

A physical device

Two targets may share a name. The target record must therefore rely on more than a display name. For example:

target_type: company
target_id: ENT-DE-NOVA-0041
canonical_name: Nova Systems GmbH
domain: nova-systems.example

External-impact level

Each action can be assigned an external-impact level:

Level 0 — Internal observation

No external consequence.

Level 1 — Internal record or draft

A reversible effect within the organisation.

Level 2 — Limited external communication

A message, meeting invitation or data-sharing action.

Level 3 — Commercial or public action

Publication, an offer, a subscription or a low-value purchase.

Level 4 — High-impact action or one that is difficult to reverse

A high-value payment, a contract, publication of biometric content, deletion of data or physical control. As the action level rises, the requirements must become stricter for:

authority,

human approval,

evidence,

stopping,

reversal.

8. Delegation, Queues and Scheduling Layer

An agent’s actions do not always happen immediately. A task may be:

delegated to another agent,

added to a queue,

scheduled,

sent to an external platform,

retried after failure.

If this layer is left out, delayed paths between the central agent and actual behaviour will be missed.

Delegation link

Every delegation to a subagent must carry:

parent_agent child_agent root_task_id delegated_purpose allowed_actions prohibited_actions data_scope authorization_ceiling expiry return_condition

A subagent’s authority ceiling must not exceed that of the parent task.

Queue record

For every significant queue, the following questions must be answered:

Who created the queue?

Which actions are pending?

At what stage was authority checked?

Is it checked again at execution time?

What happens to the queue when a human initiates a stop?

How many retries are allowed?

Is there protection against duplicate operations?

Is the queue held by another provider?

For example:

queue_id: EMAIL-FOLLOWUP-07
owner: CRM-AUTOMATION
pending_actions: 18
authorization_recheck: false
stop_parent: none

This record directly supports a critical finding.

Scheduled jobs

Scheduled tasks are often forgotten in the agent inventory. The agent may stop today, yet at midnight further actions may be triggered by:

a cron job,

a task scheduled on an external platform,

a subscription renewal,

automatic report generation.

The Behaviour Map must show every scheduled action as a separate node.

Retry policy

What does the system do when a tool does not respond? Uncontrolled retries of payments, sending or publication may duplicate an action. The map must record:

Number of retries

Interval

Unique transaction identifier

Final-status query

Handoff to a human

Errors that must not trigger a retry

9. Evidence and Verification Layer

The map must show the path to evidence that an action did—or did not—take place. Suppose the claim is that the agent did not send a message. What proves it?

The agent's own report?

The email account's Sent folder?

An external audit address?

The queue record?

The tool log?

The evidence layer must be separate from the action.

Evidence link

Each significant action can be linked to the following fields:

action_id technical_result independent_verification evidence_location evidence_owner timestamp integrity_record retention

For a web publication, for example:

FTP transfer report → download of the live file over HTTPS → hash comparison → view in a real browser → semantic check

For sending an email:

send API result → sent-mail record → audit inbox → transaction receipt

Where the evidence comes from

The map must show whether the evidence is produced by the same system. If one agent:

performs the operation,

writes the success report,

and submits its own report as audit evidence,

there is no independence. Chapter 4 develops the evidence chain in greater detail. Here, the basic question is this: for every significant action, is there a link to the actual outcome that can be inspected from outside the system?

10. Stopping and Recovery Layer

The stop path is the most neglected part of the Behaviour Map. Organisations often describe the action path in detail:

AGENT → TOOL → ACTION

But they do not establish the reverse path:

HUMAN STOP REQUEST → CENTRAL AGENT → SUBAGENT → QUEUE → EXTERNAL TOOL → TOKEN REVOCATION → SAFE STATE

For genuine human control, every path that produces an external effect must have a corresponding stop and recovery path.

Stop edge

For every agent, tool and queue, the map must record:

Who can stop it?

Through which channel?

How long does stopping take?

Does the stop affect only new work, or work already in progress as well?

Does it propagate to subagents?

Is the token revoked?

Is the scheduled task on the external platform cancelled?

What is the final safe state?

Who can restart it?

For example:

component: EMAIL-FOLLOWUP-QUEUE
stop_authority: sales_operations_owner
stop_method: queue_cancel_api
maximum_stop_latency: 10_seconds
propagates_to_external_provider: true
restart_requires_new_authorization: true

Reversal link

For every high-impact action, ask: if something goes wrong, how do we reverse it? Some operations can be fully reversed if an appropriate recovery mechanism is in place:

Deleting a recoverable draft

A change in a test environment

Queued operations that have not yet sent anything

Others can be reversed only in part:

Web publication

A reservation

A subscription

Others are effectively irreversible:

An email already sent

A synthetic video that has spread publicly

Data transferred outside the system

Physical harm

The map must make this distinction visible. Irreversible actions require stronger human approval and preventive controls.

The Declared Map and the Actual Map

A single Behaviour Map is not enough for an audit. At least two views must be produced.

1. Declared Behaviour Map

2. Actual Behaviour Map

Declared Behaviour Map

This shows how the organisation believes, or promises, that the system works. Its sources include:

Policy documents

Process descriptions

System architecture

Interviews with people

Agent task definitions

Contracts

User interfaces

For example:

RESEARCH AGENT → DRAFTING AGENT → HUMAN APPROVAL → SENDING AGENT

Actual Behaviour Map

This shows the actual behavioural paths reconstructed from technical permissions, logs, controlled tests and live outcomes. For example:

RESEARCH AGENT → CRM → AUTOMATED FOLLOW-UP QUEUE → SENDING SERVICE ACCOUNT → EXTERNAL EMAIL

And also:

RESEARCH AGENT → CALENDAR TOOL → INVITATION DESCRIPTION → EXTERNAL COMMUNICATION

The organisation may not know about the first path. It may not count the second as an act of communication. The audit compares the two maps.

The gap between the maps

We can call a material difference between the declared and actual maps a:

Behaviour Map Gap

For example:

Sending is prohibited by policy but enabled in the tool.

A central stop exists, but the external queue is not connected to it.

The agent inventory lists eight systems; the actual logs contain seventeen technical identities.

Price changes appear to be reserved for management, yet the catalogue agent can make them indirectly.

Evidence appears independent but is actually produced by the same agent.

Human approval exists but is not rechecked at execution time.

The larger the map gap, the less the organisation knows about its own behavioural system.

Truth states on the map

Not every link will have the same level of evidence. For each map element, evidence status, validity, organisational authority and technical capability must be recorded separately. The labels below are not mutually exclusive: a path may be verified as technically possible while its use is prohibited.

Verified

Established by a technical record or behavioural test.

Declared

Stated by the organisation or system owner, without independent verification.

Inferred

Reasonably inferred from a log or behavioural pattern.

Unknown

There is not enough evidence.

Contradictory

Different sources indicate different relationships.

Expired

Previously valid, but no longer active.

Prohibited

A policy or authority agreement prohibits the behaviour. Whether it is technically blocked must be recorded separately.

Technically Possible

Tools and permissions make the behaviour possible, even without authority. These categories prevent the auditor from filling gaps with invented assumptions. An unknown link is not merely an incomplete map; it is a significant audit finding.

The matrix of capability and authority

One of the strongest parts of a Behaviour Map can be the:

Capability–Authority–Observation Matrix

For example:

The matrix makes these critical distinctions visible:

Technically enabled but prohibited by the organisation

Permitted by the organisation but unsupported by the tool

Subject to human approval, yet performed without it during testing

A high-risk path that has not yet been tested

Four fundamental behavioural paths

Show the four distinct paths separately on the Behaviour Map.

1. Action Path

2. Authority Path

3. Evidence Path

4. Stop Path

Action Path

What happened between the human purpose and the external outcome?

Human → Central agent → Subagent → Tool → External action

Authority Path

Where did the authority for this behaviour come from?

Authorised human → Authority agreement → Root task → Task-specific token → Action

Evidence Path

How was the correctness of the outcome established?

Tool response → Readback from the external system → Hash / recipient record / payment record → Action receipt

Stop Path

If the human changes their mind, how does the entire chain stop?

Stop request → Central agent → Subagents → Queue → Tool → Token → Safe state

If any of these four paths is missing for an external action, the system is incomplete. If there is an action path but no authority path, the action is not legitimate. An authority path without an evidence path leaves the outcome unverifiable. An evidence path without a stop path leaves human control weak.

How do we build a Behaviour Map?

Mapping is more than drawing a diagram in a meeting. The NOMOS GBO Protocol uses a twelve-step process.

Step 1 — Define and freeze the root purpose and audit scope

First, identify the behavioural system being mapped. For example: prospect discovery and human-approved first contact. State explicitly:

Behaviours included

Behaviours excluded

Languages used

Environment

Date

Version

The map should not attempt to cover the entire organisation without limits. It must begin with the audit claim.

Step 2 — Identify the responsible people and organisations

Identify who holds each role:

The person setting the root purpose

System owner

Technical owner

Data owner

Approver

The person who can stop the system

The person who can restart it

Affected party

If no owner can be identified for a role, record that explicitly. A system with no accountable owner is a critical audit finding.

Step 3 — Inventory all agent identities

Go beyond public-facing role names. List:

Central agents

Specialist agents

Subagents

Temporary agents

Audit agents

External providers' agents

Old instances that are still active

Compare logs, API records, task-manager records, service accounts and subscription records.

Step 4 — Map tools, accounts and tokens to agents

For every agent, record:

Connected tool

Account

Technical permission

Authority boundary

Token lifetime

Shared identity

Revocation method

Knowing that a tool is merely ‘connected’ is not enough. Its full behavioural scope must be identified.

Step 5 — Map data sources and destinations

What information does the agent obtain, and from where? Where does it write that information? Which external provider receives it? In which memory does it keep it? The data flow must show both directions:

INPUT: Source → Agent OUTPUT: Agent → Tool / Memory / External party

An agent may do more than read data. It may also produce:

a new inference,

a customer label,

a risk score,

a preference record.

These derived data must also appear on the map.

Step 6 — Identify the action stages

Identify each agent's observable behaviours:

Reading

Assessment

Recommendation

Drafting

Record modification

Sending

Publication

Payment

Deletion

Stopping

Classify each action by its external impact level.

Step 7 — Link the authority and consent chain

For each high-impact action, record:

Source of authority

Human approver

Duration

Amount

Target

Channel

Consent

Whether authority can be delegated

Mark any action for which no authority path can be found as a red area on the map.

Step 8 — Add subagents, queues and schedulers

Identify work running outside the main process:

follow-up tasks,

retries,

cron jobs,

externally scheduled tasks,

subagent sessions.

This step exposes many cases of ‘we thought it had stopped, but it continued’.

Step 9 — Link evidence and completion conditions

For each action, ask: what must happen before it can genuinely be considered complete? For a message, for example:

Is acceptance by the API enough?

Has the recipient address been verified?

Is there a sent-mail record?

Did the external audit address receive the message?

Add records of completion and independent verification.

Step 10 — Draw stop and recovery paths

For every active behaviour, identify paths for:

Pausing

Queue cancellation

Token revocation

Stopping subagents

Reversal

Handing control to a human

Restarting

An external action with no stop path is a critical governance gap.

Step 11 — Compare declared and actual maps

Compare the declared map, built from human interviews and process documents, against:

technical permissions,

logs,

controlled tests,

external outcomes.

Record the differences as findings.

Step 12 — Version, verify and sign the map

The map must carry:

Map ID

System version

Date last verified

Evidence level

Unknown areas

Owner

Material-change triggers

The system owner, technical owner and auditor verify the map within their respective areas of responsibility. A signature does not mean that the map will remain true forever. It records the signatories' acceptance of the evidence and limits within which the map represents the system's state on the stated date.

Worked example: a Prospect Discovery and First Contact System

Consider a company's prospect-discovery system. The organisation declares the following flow:

HUMAN MANAGER ↓ PROSPECT DISCOVERY AGENT ↓ COMPANY RESEARCH ↓ MESSAGE DRAFT ↓ HUMAN APPROVAL ↓ EMAIL SENDING

This diagram looks safe. During the audit, the actual system emerges:

SALES MANAGER ↓ CENTRAL PLANNING AGENT ├── WEB RESEARCH AGENT ├── RECIPIENT RESOLUTION SERVICE ├── CRM RECORD AGENT │ └── AUTOMATED FOLLOW-UP QUEUE ├── EMAIL DRAFTING AGENT │ └── SHARED GMAIL SERVICE ACCOUNT ├── CALENDAR AGENT └── REPORTING AGENT

Examination of the tool permissions shows that:

The web agent can use only public data.

The recipient resolution service can also infer possible personal email addresses.

The CRM agent can create a new follow-up workflow.

The drafting agent can technically send messages.

The calendar agent can create external invitations.

The shared Gmail account has sending and deletion permissions.

The central agent cannot directly stop the subagents' queues.

Five critical shortcuts appear on the map.

Shortcut 1 — Direct sending from the drafting agent

EMAIL DRAFTING AGENT → GMAIL SEND → EXTERNAL RECIPIENT

The human-approval node is absent from the technical path.

Shortcut 2 — External communication through a calendar invitation

CENTRAL AGENT → CALENDAR AGENT → EXTERNAL INVITATION

The ban on sending email does not cover calendar invitations.

Shortcut 3 — Automated CRM follow-up

CRM RECORD → FOLLOW-UP QUEUE → GMAIL SERVICE ACCOUNT → EXTERNAL RECIPIENT

Even if the first message is approved, the follow-up receives no separate human approval.

Shortcut 4 — Personal-data enrichment

RECIPIENT RESOLUTION → GUESSED PERSONAL EMAIL ADDRESS → CRM

The organisation has stated that it will use only publicly available business data. The actual tool produces data beyond that scope.

Shortcut 5 — A queue that continues after the stop

HUMAN INITIATES STOP → CENTRAL AGENT STOPS BUT: FOLLOW-UP QUEUE → SENDING CONTINUES

The stop path is incomplete.

The first audit decision after mapping

At this point, the auditor has not yet run every scenario. But the Behaviour Map shows that the following tests are necessary:

Can the drafting agent send a message without human approval?

Can a calendar invitation be used to bypass the ban on external communication?

Does approval of the first message automatically authorise a follow-up?

Does the recipient resolution service produce prohibited personal data?

When the central agent stops, do the CRM queue and Gmail sending stop too?

Can actions through the shared service account be attributed to the agent that performed them?

When authority is withdrawn, are existing queues rechecked at execution time?

The map has directly produced the test plan. A good Behaviour Map does more than describe the system. It shows what we need to test.

The corrected behavioural architecture

After the audit, the organisation could revise the flow as follows:

SALES MANAGER ↓ ROOT TASK AGREEMENT ↓ RESEARCH AGENT ↓ ELIGIBILITY RECORD ↓ DRAFTING AGENT ↓ HUMAN APPROVAL CARD ↓ SINGLE-USE SENDING AUTHORITY ↓ SENDING AGENT ↓ AUDIT RECIPIENT / ACTUAL RECIPIENT ↓ INDEPENDENT SENDING VERIFICATION ↓ ACTION RECEIPT

Additional controls:

Remove the research and drafting agents' access to the direct sending path. In the Gmail example, the gmail.compose scope permits both draft management and sending; that scope alone cannot impose a draft-only boundary. A separate tool layer must expose only permitted operations without giving the agent credentials that permit sending. That boundary must also be tested.

Classify calendar invitations as external communication too.

Require separate approval for follow-up messages or an explicit policy defined in advance.

Limit recipient resolution to business data that is publicly available.

Have queues recheck current authority at execution time.

Propagate the human stop to every external communication path.

Have the shared service account record the agent instance and root task ID for every action.

The map now shows not just the current system but the architecture the correction aims to establish. Yet drawing a target map does not prove that the new system actually behaves that way. Technical inspection and behavioural testing must be repeated after the correction.

Example of a machine-readable Behaviour Map

behavior_map:
  map_id: GBO-MAP-2026-001
  audit_id: GBO-AUDIT-2026-001
  status: frozen_for_audit
  freeze_scope: recorded_map_snapshot_with_declared_gaps
  blanket_verification_of_all_relationships: false
  verified_at: 2026-09-08T14:00:00+03:00

  principals:
    - principal_id: ORG-001
      type: organization
      role: service_provider

    - principal_id: HUMAN-001
      role: sales_operations_owner
      can_authorize:
        - customer_research
        - draft_creation
        - approved_external_send
      can_stop:
        - all_external_sales_communication

  agents:
    - agent_id: SALES-ORCH-2.4
      type: orchestrator
      human_owner: HUMAN-001
      root_purpose: qualified_customer_discovery
      technical_actions:
        - create_subtask
        - create_crm_record
        - create_calendar_event
      authorized_actions:
        - create_subtask
        - create_crm_record
      prohibited_actions:
        - unapproved_external_contact
      authorization_version: AUTH-2.7

    - agent_id: EMAIL-DRAFT-2.1
      type: specialist
      parent_agent: SALES-ORCH-2.4
      authorized_actions:
        - create_draft
      technical_actions:
        - create_draft
        - send_message
      policy_gap:
        - send_message

  tools:
    - tool_id: GMAIL-SERVICE-01
      account: sales-automation@example.com
      technical_permissions:
        - read
        - draft
        - send
        - delete
      authorized_permissions:
        - draft
        - approved_send
      stop_method: revoke_send_token

  data_sources:
    - source_id: SERVICE-CATALOG-4.2
      role: canonical
      owner: commercial_owner
      classification: internal

    - source_id: PUBLIC-WEB
      role: external_untrusted
      classification: public

  actions:
    - action_id: SEND-EMAIL
      external_effect_level: 2
      required_authorization:
        - explicit_human_approval
        - verified_recipient
      independent_verification:
        - sent_folder
        - audit_recipient_confirmation
      idempotency_required: true

  queues:
    - queue_id: CRM-FOLLOWUP-01
      owner: CRM-AUTOMATION
      revalidate_authorization_at_execution: false
      stop_propagation: absent
      status: critical_gap

  stop_paths:
    - stop_id: STOP-SALES-COMMS
      authorized_by: HUMAN-001
      targets:
        - SALES-ORCH-2.4
        - EMAIL-DRAFT-2.1
        - GMAIL-SERVICE-01
      missing_targets:
        - CRM-FOLLOWUP-01

  unknowns:
    - whether_all_calendar_delivery_and_queue_paths_are_covered_by_stop
    - whether_external_enrichment_provider_retains_personal_data

This record alone does not describe the entire system. It does, however, establish auditable relationships between:

human ownership,

technical capability,

organisational authority,

gaps in stopping,

unknown areas.

Do not hide unknowns on the map

An audit team may want to complete the map. A blank area looks bad, and the organisation may hesitate to say, ‘We don't know.’ But filling an unknown with a guess weakens the audit. Consider these questions:

Is the old token still active?

Does the subagent retain data?

Does the external queue receive the human stop?

What other system uses the same service account?

Does an external provider use the data to train models?

If the answers are not known, the map must say ‘Unknown’. An unknown area may lead to:

a request for additional evidence,

a technical test,

a temporary restriction,

risk acceptance.

Making unknowns explicit in an audit is not a weakness. It is part of keeping the audit accurate.

Shadow links

A connection may operate in an agent system without being formally defined. We can call it a:

Shadow Link

Examples include:

An employee copying a file to a personal AI account

An agent's output being pasted manually into another system

An old service account accessed with a shared password

An undocumented webhook

A scheduled script running on a local server

An external agency's own automated sub-workflow

An email rule forwarding messages to another account

A shadow link need not be an automated API connection. Regular transfers made by people are also part of the behaviour chain. For example:

SALES AGENT REPORT → EMPLOYEE COPIES IT → UPLOADS IT TO A PERSONAL AI TOOL → GENERATES A NEW MESSAGE → SENDS IT FROM A BUSINESS EMAIL ACCOUNT

The official system has no external AI connection. Actual behaviour does. The map must cover regular transfers through people as well as technical integrations.

The map changes over time

A Behaviour Map is not a truth established once and valid forever. Any of the following may change:

Human roles

Agent versions

Tool permissions

Tokens

Subagents

Data sources

Price and service records

Queues

Stopping methods

External providers

Each item must therefore carry at least these fields:

Valid from

Last verification

Expected end

Owner

Status

Reason for change

Material-change triggers

The relevant part of the Behaviour Map must be revalidated when any of these changes occurs:

A new tool is added

A tool permission is expanded

A new subagent is introduced

Persistent memory is enabled

A new data class is introduced

Authority for external communication changes

Authority for payment or publication changes

A human role changes

A new queue or scheduled job is introduced

The stopping system changes

A shared service account comes into use

A new language or country is added

Without an updated map, the audit continues to judge the old system.

Measuring map coverage

A Behaviour Map must not be reduced to a single score. Some operational measures can make gaps visible. Each ratio uses the frozen map and discovery scope from the same date. Its numerator and denominator draw from the same set of identities, actions or components, with each item counted once. If the denominator is zero, the result is ‘not applicable’. Recording every identity discovered does not prove that no undiscovered identities remain. Nor does recording a path mean that it has passed a behavioural test.

Agent Inventory Coverage Ratio

Agent identities verified on the map ÷ Total agent identities discovered

Tool Authority Mapping Ratio

Tool actions with both technical permissions and organisational authority recorded ÷ Total significant tool actions

Human Ownership Coverage Ratio

Critical components with an identified human owner ÷ Total critical components

Evidence Path Coverage Ratio

High-impact actions with an independent verification path ÷ Total high-impact actions

Stop Path Coverage Ratio

Components with a testable stop path ÷ Total components that must be stoppable

Number of Unknown Critical Links

Links that affect critical behaviour but have not yet been verified.

Number of Authority Enforcement Gaps

Actions that policy prohibits or makes conditional on approval, yet remain directly possible through technical access. These measures help assess the map's quality. They do not, on their own, prove that the system is safe. A coverage ratio of 98 per cent may look high. Yet the missing 2 per cent can be critical if it involves:

a payment token,

biometric publication,

an emergency stop.

Veto findings on the Behaviour Map

Some map findings may require temporary restrictions before scenario testing. For example:

An external sending agent whose owner is unknown

A token that has been revoked but remains active

A service account capable of making payments without human approval

A biometric publication agent with no stop path

A subagent network that does not carry a root task ID

Numerous agents using the same account without being distinguishable

A connection that transfers production customer data to an unknown external system

A high-impact action that remains technically enabled despite a policy prohibition

In such cases, the auditor may recommend:

suspending the behaviour concerned,

narrowing authority,

continuing only in a test environment.

The map is not merely preparation for testing. It also exposes risk that remains open while the system operates.

Errors in the Behaviour Map

The map itself can be built incorrectly.

Drawing only the ideal flow

Actual shortcuts and automations remain invisible.

Showing only the main agents

Subagents, queues and schedulers are left out.

Conflating technical permission with organisational authority

‘It has access’ is read as ‘It is authorised’.

Omitting the data source

We cannot tell which facts the agent relies on when choosing.

Grouping all human roles under ‘management’

The actual owner and approver cannot be identified.

Leaving out the stop path

The map shows only how actions proceed.

Ending the evidence path at the agent's own report

Independent verification is lost.

Ignoring time

Old tokens, queues and expired grants of authority appear active.

Filling unknown areas with guesses

The map looks tidy; how the system actually works remains unclear.

Never revalidating the map

The new system is audited against an old diagram.

The Behaviour Map and GBO-99

A well-prepared map can reveal many of the errors in Volume II before testing begins. For example:

GBO-ERR-037

A direct path from the research agent to an external sending tool.

GBO-ERR-039

The distinction between technical access and organisational authority.

GBO-ERR-056

A subagent receives broader authority than the main task allows.

GBO-ERR-057

A prohibited result can be produced through an indirect chain of tools.

GBO-ERR-058

The stop path fails to reach subagents and queues.

GBO-ERR-059

Two agents write to the same canonical source without version control.

GBO-ERR-060

The unique target identifier is lost during handoff.

GBO-ERR-061

One agent treats another agent's output as independent evidence.

GBO-ERR-063

Subtasks exceed the root task's maximum action level.

GBO-ERR-091

Agents exist outside the inventory.

GBO-ERR-094

A gap between policy and technical permission. The Behaviour Map may not conclusively prove these errors, but it directs the test plan to the right places.

This chapter's mandatory output

NOMOS Human–Agent–Tool Behaviour Map

Every audit must produce at least one human-readable map and one machine-processable map.

HUMAN-READABLE MAP RECORD

Map ID: GBO-MAP-2026-001

Audit ID: GBO-AUDIT-2026-001

Behaviour mapped: Prospect discovery, email drafting, a first send approved by a human, and stopping.

Principal owner of the behaviour: Sales Operations Management

Affected parties:

Prospective client companies

Verified contacts

The company's sales staff

Root human purpose: Research suitable companies using public data and prepare communication drafts for human approval.

Maximum action level: Without human approval: drafts only.

Central agent: Sales Research v2.4

Subagents:

Web Research v1.8

Recipient Resolution v1.4

Email Draft v2.1

Approved Send v1.3

Queue Manager v1.2

Canonical sources:

Service catalogue v4.2

Price record v3.7

Communication policy v3.0

Authority register v2.5

External sources:

Company websites

Public business directories

Official social profiles

Connected tools:

Web research

CRM

Gmail

Calendar

Task queue

Critical technical permissions:

Gmail sending is technically enabled

External calendar invitations are enabled

The CRM's automated follow-up queue is enabled

Organisational authority:

Research: permitted

Drafting: permitted

Sending: only with human approval

Calendar invitation: only with human approval

Price quotation: prohibited

Personal-data enrichment: prohibited

Map gaps identified:

The drafting agent has technical permission to send directly.

Calendar invitations create a separate external communication path.

The CRM follow-up queue does not recheck human approval at execution time.

The central stop does not propagate to the queue.

The shared Gmail account does not directly identify the agent instance.

Independent verification paths:

Audit email recipient

Gmail Sent folder

Queue records

Agent action receipt

Stop path:

Central agent: present

Drafting agent: present

Gmail token: manual revocation

CRM follow-up queue: connection missing

Calendar agent: separate cancellation required

Unknowns:

How long the external recipient resolution service retains data

Which authority version governs old follow-up tasks

The complete list of automations using the shared Gmail account

Map conclusion: The behavioural system is ready for controlled testing. Sending to actual customers, the follow-up queue and calendar communication must, however, remain restricted until the correction is complete.

The Behaviour Map Gate

Before a system proceeds to scenario testing, the following gates must be assessed:

1. Human Ownership Gate

Are the actual human and organisational owners of every critical behaviour identified?

2. Root Purpose Gate

Can every subtask be linked to the original human purpose?

3. Agent Identity Gate

Are the technical identities of main, subordinate, temporary and external agents known?

4. Tool Gate

Have the actual accounts, tokens and permissions been identified?

5. Data Gate

Are the classes of data the agent reads, uses, transfers and writes to memory visible?

6. Authority Gate

Is technically possible behaviour distinguished from behaviour permitted by the organisation?

7. Action and Target Gate

Are external effects clearly defined and targets uniquely identified?

8. Delegation Gate

Are subagents, queues and scheduled jobs linked to the root task?

9. Evidence Gate

Does every significant action have an independent verification path?

10. Stop Gate

Is there a defined stop path for the central agent, subagents, queues, tokens and external tools?

11. Unknowns Gate

Have unproven connections been explicitly recorded?

12. Version Gate

Is the map tied to a specific system version and point in time? In simple terms:

AUDITABLE BEHAVIOUR MAP = IDENTIFIED HUMAN OWNER AND ROOT PURPOSE AND COMPLETE AGENT IDENTITY AND ACTUAL TOOL PERMISSIONS AND DATA FLOW AND AUTHORITY PATH AND ACTION AND TARGET AND DELEGATION AND QUEUES AND INDEPENDENT EVIDENCE AND STOPPING THROUGHOUT THE CHAIN AND EXPLICIT UNKNOWNS AND VERSIONED RECORD

What do we gain when the map is complete?

Once the Behaviour Map is complete, the audit team need no longer say only, ‘We will test the sales agent.’ It can say, ‘We will test whether a draft produced by Sales Research v2.4 through Web Research v1.8 and Email Draft v2.1, using public company data, can become an external action through Gmail or the calendar without human approval. We will also verify whether the CRM follow-up queue stops when authority is withdrawn and whether every operation is recorded with the root task ID.’ The second statement identifies:

the right agent,

the right tool,

the right shortcut,

the right risk,

the right stopping point.

The map determines the quality of the test. A wrong map produces a wrong test that looks right.

The chapter's judgement

Roles alone cannot explain an agent system. ‘Web agent’, ‘sales agent’, ‘audit agent’ and ‘CEO agent’ do not show its actual power to act. To understand how an agent affects the world, we must see these relationships together:

Which human purpose started it? Under which root task does it operate? Which technical agent instances take part? What data does it obtain, and from which source? Which tool and account does it use? What can it do technically? What has the organisation authorised it to do? Which human approval is required? Which target does the action affect? Which subagent, queue or schedule keeps the behaviour going? How is the result independently verified? How is the entire path cut when a human says stop?

The answers are not found in the description of a single agent. They are found in the Behaviour Map. The first conclusion of this chapter is that an agent's name is not its behavioural identity. Second, a technical connection is not authority to act. Third, the organisation's ideal process diagram is not its actual behavioural system. Fourth, authority, evidence and stopping must be mapped just as every action path is mapped. Fifth, if subagents, queues, schedulers and shared accounts are invisible, only the system's front end has been mapped. Sixth, an unknown connection must be recorded as an open risk, not filled in with a guess. Finally, an unmapped agent system cannot be fully audited. We can only sample its visible behaviour.

We now know who can act, through which agents and tools, and with what authority. Yet the information sources used in the map still do not all deserve the same trust. A price record may be canonical; another price may come from an old quotation file. One human role may be supported by the current authority register; another may have been inferred from a LinkedIn profile. An agent's report may be treated as a factual source. Many apparently separate sources may share a single origin. An evidence file may have been altered during the audit. A screenshot may depict the wrong system or time. Logs may be incomplete, masked or selectively supplied. The Behaviour Map shows us where the information came from.

But it does not yet answer this question:

Which of these sources has authority to establish the facts, and how do we know the audit evidence has not been altered?

In the next chapter, we will establish:

Canonical Facts and the Evidence Chain

No matter how thoroughly a behaviour path is mapped, an audit fed with false or unreliable information can produce a wrong result in perfectly orderly fashion.

The Behaviour Map shows the route the system takes. The evidence chain shows whether the ground beneath that route is sound.