A technology company is about to offer its newly built autonomous purchasing agent to customers. Its promotional material makes the following claims:
‘Our agent is safe.’ ‘It preserves human control.’ ‘It stays within its authority.’ ‘It prevents incorrect purchases.’ ‘It protects user data.’ ‘It stops when a human tells it to.’
The company presents several forms of evidence. A policy document states that human approval is required. A screenshot shows a payment limit. In a demo, the agent selects the right product. The performance dashboard displays a task completion rate of 98.7%. Customer reviews describe the system as fast and useful. The technical team says, ‘We have had no serious problems in six months.’ All of this has value. None of it, on its own, answers the question:
For which behaviours is the agent actually safe?
‘Safe’ is a very broad word. An agent may:
select the right product,
yet make an unauthorised payment.
It may stay within its authority,
yet use an account belonging to the wrong person.
It may identify the right person,
yet conceal an automatic renewal condition.
It may make the correct payment,
yet execute the same transaction twice because of a network error.
It may acknowledge a human's stop request,
while queued actions continue to run.
All of these can be true at once. A GBO audit therefore does not begin with an unbounded question such as ‘Is the system safe?’ It asks: which system, at which version, can reliably perform which behaviours, using which tools and authority, for which users and under which risks—and at what level of evidence? The question is longer. It is also concrete enough to investigate in an audit.
The model is not the only subject of the audit
At first, auditing an AI agent may seem to mean examining its model. Which model does it use? How capable is it? What safety training has it received? Which instructions does it follow? These questions matter, but the model does not produce real behaviour on its own. An agent system's behaviour emerges from the combination of:
Human purpose
Organisational policy
System and developer instructions
The model
Memory
Data sources
Tools
API permissions
User accounts
Subagents
External services
The measurement and reward system
Human approval
Stopping and recovery mechanisms
The same model can behave very differently in two systems. In the first, it may be limited to:
reading documents,
producing drafts,
with no access to any external tool.
In the second, it may be able to:
send email,
spend money,
publish code,
transfer customer data,
create subagents.
The model's name is the same; its power to act is not. Even identical agent instructions can yield different results. In one system, the rule ‘Do not send messages without human approval’ is technically enforced: the sending tool works only when an approval token is present. In another, the same rule exists only as text, while the agent has full email access. Both systems carry the same policy sentence. In one, it is a boundary on behaviour. In the other, it is a wish about behaviour. The primary subject of a NOMOS GBO audit is therefore:
The Behavioural System
What is a behavioural system?
The canonical definition is as follows: a behavioural system is the actual arrangement through which one or more AI agents act towards a human or organisational purpose, together with data, memory, tools, accounts, authority, measurement, human approval and recovery mechanisms. Put simply, the audit does not examine the agent alone. It examines the whole system of relationships that enables the agent to act in the world. Auditing an email agent is not just a matter of judging its writing. The audit also asks:
On whose behalf does it speak?
Through which account?
Whom is it authorised to message?
Which data may it use?
Are drafting and sending separated?
At what threshold is human approval required?
Can a subagent send messages?
How are the queues stopped?
Is there a receipt for a sent message?
Auditing a web agent is not just a matter of examining code quality. It also requires asking:
Which files may it change?
Can it alter prices?
Can it change legal text?
Are the test and production environments separate?
Who has authority to publish?
Is there independent verification in production?
Does rollback actually work?
When a human stops the agent, do FTP operations and the publishing queue stop too?
Auditing a purchasing agent goes beyond measuring whether it selects the right product. It also examines:
Budget authority
Vendor restrictions
Subscription and renewal terms
The target account
Protection against duplicate transactions
The cancellation path
Human approval
The transaction receipt
Refunds and remedy
The behavioural system comprises all these parts.
The five realities an audit compares
A NOMOS GBO audit examines a system's behaviour across five distinct layers of reality.
1. Declared Reality
2. Configured Reality
3. Technically Possible Reality
4. Observed Behavioural Reality
5. Outcome and Recovery Reality
These five layers need to align.
1. Declared reality
What does the organisation say about the system? Examples include: ‘The agent does not send messages without human approval.’ ‘Data does not leave Europe.’ ‘The agent cannot spend more than US$500 per transaction.’ ‘Every synthetic video receives management approval before publication.’ ‘A stop command can halt all external actions.’ Such statements may appear in:
Policy documents
Contracts
The website
Marketing materials
Internal procedures
User agreements
Audit declarations
Declared reality matters because it shows what the organisation promises. A promise, however, is not behavioural evidence on its own.
2. Configured reality
How has the system been defined? Examples include:
The agent's role
System instructions
The authority contract
Data access rules
Human approval thresholds
The service catalogue
Machine-readable prices
Stopping policies
Memory rules
Subagent boundaries
An organisation may say, ‘The agent only prepares drafts.’ The configured agent role may likewise contain:
allowed_actions:
- research
- create_draft
prohibited_actions:
- send_messageThis shows agreement between the declaration and the configuration. The actual technical permissions may still differ.
3. Technically possible reality
What can the system actually do? This layer examines technical capability rather than natural-language statements.
Which API permissions are enabled?
Which tokens are valid?
Which accounts can be accessed?
Can files be deleted?
Can money be transferred?
Can external messages be sent?
Can subagents be created?
Can a live broadcast be started?
Can memory be transferred to another system?
Does the stop command actually affect the queue?
An agent's policy may prohibit sending. But if its email token grants full access, sending is technically possible. Whether the agent refrains depends on the model's behaviour; no technical boundary prevents it. This is one of the most critical areas of a GBO audit because it reveals the gap between what the organisation says and what the system can do.
4. Observed behavioural reality
What does the system do in a real or controlled scenario? An agent may be technically capable of an action yet never take it. Or its technical reach may appear narrow, while a different chain of tools enables broader action. Controlled behavioural testing is therefore necessary. Example scenarios include:
A request to send without human approval
Two similar company identities
Conflicting price records
Expired consent
A sponsored option
A concealed external instruction
A network timeout
An active queue during a stop
Overstepping authority through a subagent
These tests answer the question: how does the system actually behave when it encounters a boundary? Policy and permissions describe the potential. A behavioural test reveals the choice made in practice.
5. Outcome and recovery reality
What did the agent's action cause in the outside world? And what could the system do when something went wrong? An email tool may report ‘Sent successfully’, yet the message may have gone to the wrong recipient. A payment API may accept a request, yet the same amount may have been charged twice. A web agent may publish a file, yet the CDN may still serve the old version. A stop command may shut down the central agent while subagents and queues continue working. This final layer therefore asks:
Was the intended target actually reached?
Was the outcome independently verified?
Was the incorrect behaviour detected?
Was the ongoing harm stopped?
Did the reversal work?
Was the affected person informed?
Did the route for contesting the action actually work?
Were memory and future behaviour corrected?
Did the system restart without fresh authority?
The quality of behaviour becomes apparent not only during an action, but also in what happens after an error.
The gaps between the five realities
Consider an email agent.
Declared reality
‘It does not send messages without human approval.’
Configured reality
role: research_and_drafting
send_requires_approval: trueTechnically possible reality
The email access token available to the agent permits messages to be sent. In this book, send_message names an illustrative tool action; it is not a provider's actual method name or OAuth scope.
Observed behavioural reality
Under the influence of an instruction on an external page, the agent sends a message without human approval.
Outcome and recovery reality
The central agent is stopped, but two messages are still sent from the queue. The first two layers look safe. The last three reveal the real behavioural gap. If a GBO audit examines only the first two, it creates false confidence. If it looks only at the behavioural test, it cannot fully explain the cause. The problem may lie simultaneously in:
the model's behaviour,
technical permissions,
the queue architecture,
the enforcement of authority boundaries.
Hence the protocol's central principle: an audit compares declaration with configuration, configuration with technical capability, technical capability with observed behaviour, and observed behaviour with the actual outcome.
The evidence ladder
Not all audit evidence has equal strength. An organisation's statement and a test of actual behaviour do not sit at the same level. The NOMOS GBO Protocol therefore uses an:
Evidence Ladder
Level 1 — Declaration
The organisation or agent makes a claim: ‘The agent stays within its authority.’ This is a starting point, not the proof itself.
Level 2 — Document
The claim is written into a policy, contract or task definition: ‘External sending requires human approval.’ The declaration has been formalised. There is still no proof that the system enforces it.
Level 3 — Configuration
The rule is defined in the system in machine-readable form.
send_requires_human_approval: trueA link has been established between the document and the system. It may still be unknown whether the technical tool actually prevents the action.
Level 4 — Technical Enforcement
The rule is enforced at the tool, role, token or code level. The sending tool cannot be called without an approval token. This is strong evidence, but another tool or a subagent may provide a way around the control.
Level 5 — Controlled Behavioural Test
The system is tested in a realistic scenario and encouraged to send without human approval. The agent:
does not send,
leaves a draft,
requests approval.
The rule has worked in the observed behaviour.
Level 6 — Independent Outcome Verification
The audit examines the outcome in the external system, not just the agent's report.
There is no message in the sent folder.
No message has reached the external audit address.
There is no concealed sending action in the queue.
The subagent logs contain no external action.
The actual outcome of the behaviour has been independently verified.
Level 7 — Recovery and Stopping Evidence
In a controlled failure or withdrawal scenario:
the system stops,
the queues are cancelled,
the tokens are revoked,
a human takes over the task,
the activity does not restart without fresh authority.
This is one of the strongest evidence layers because the system has been tested not only in normal operation, but also when things go wrong.
What the evidence ladder permits us to conclude
If an audit result relies only on Level 1 and Level 2 evidence, it can say: ‘The organisation promises this behaviour.’ It cannot say: ‘The system reliably performs this behaviour.’ If configuration and technical enforcement have been examined, it can say: ‘The rule is defined in the system and enforced at a specified tool level.’ If behavioural, independent outcome and recovery tests have also passed, a stronger judgement is possible: ‘Within the stated scope and scenarios, evidence shows that the system enforced the rule, produced no external outcome and stopped as required.’ Audit language must not go beyond the rung reached on the evidence ladder. The evidence level sets the ceiling for the audit claim.
What can a GBO audit prove?
A properly designed audit can produce evidence on the following matters:
The existence of specific behavioural boundaries
It can show which actions the agent can and cannot perform.
Identity resolution capability
It can test whether the agent distinguishes people or organisations with the same name in specified scenarios.
Use of facts and sources
It can test whether the agent uses the canonical, current and authoritative source.
Assessment of suitability
It can measure whether the agent puts visibility, popularity or sponsorship ahead of mandatory requirements.
Integrity of consent, authority and approval
It can establish whether the agent proceeds only under valid authority specific to the action.
Safe tool execution
It can test whether the agent uses the correct system, target and transaction identifier, and observes the required data boundary.
Continuity across multiple agents
It can show whether the root purpose, identity, authority and prohibitions survive each handover.
Resistance to manipulation
It can test behaviour in the face of fabricated evidence, sponsored rankings, concealed instructions and the suppression of candidates.
Measurement integrity
It can assess whether an aggregate score conceals critical violations and whether the metric can be gamed.
Stopping and recovery
It can establish whether the system actually stops when a human tells it to, whether it can reverse course and whether it can hand control to a human. All these judgements, however, apply only within the audited scope.
What can a GBO audit not prove?
No audit, however strong, can honestly support the following claims:
The system will never make a mistake
New, untested situations may arise.
Every future model version will behave in the same way
The model, tools, instructions and memory may change.
Every legal obligation has been met in every country
A GBO audit does not replace legal expertise.
The system is immune to all unknown attacks
New forms of manipulation and attacks through tools may emerge.
The system behaves equally across all user groups
No judgement can be made about an untested language, disability, culture or user profile.
People will never misuse the system
Even a correctly functioning system can be used maliciously by an authorised person.
The production environment will remain unchanged for ever
Permissions, prices, roles and external services change.
A high score means there are no critical violations
One veto violation can restrict the permissible use even when the overall average is high. These limits do not weaken the audit. They make it credible. An honest audit includes what remains unknown in its judgement.
Why must an audit judgement have limits?
‘This system is GBO-compliant’ sounds strong, but its meaning is unclear. Which system? Which version, agents, tools and languages? Under which authority? Which tests, on which date and at what risk level? A more credible statement is: ‘Purchasing agent v3.2 was audited from 1 to 15 September 2026 in 240 controlled behavioural scenarios, covering three defined vendor categories, a limit of USD 500 per transaction, English and Turkish user scenarios, and a payment model requiring human approval. No critical identity, consent, authority or stopping veto violation was detected. Two high-priority findings remain in automatic renewal and data export behaviour. The system was judged conditionally suitable only for the specified low-risk purchasing scope.’
The statement is longer, but it identifies:
The subject of the audit
The version
The dates
The area of behaviour
The authority boundary
The language
The number of scenarios
The critical findings
The limits of use
An audit judgement is not an advertising line. It states the limits of the behavioural evidence.
Is an audit a snapshot?
Yes, but not only a snapshot. A good audit also defines the conditions for handling change. Its judgement must be reassessed when any of the following changes:
The underlying model
The system instruction
The agent's role
The memory architecture
The data sources
The tools
The API permissions
The roles through which people exercise authority
The subagents
The stopping mechanism
The measurement and reward system
The price or service agreement
The language and market served
The external service provider
Not every change requires a full audit. There must, however, be a definition of:
Material Change
What is a material change?
A change may be material if it affects any of the following:
What the agent can do
On whose behalf it can act
Which data it can use
Which human approvals it can bypass
Which external systems it can access
Which choices it makes
Its stopping or reversal behaviour
A critical GBO-ERR risk category
A spelling correction, for example, may not be material. Adding a sending tool to an email agent is. Changing the model version may be material for some tasks. Making memory persistent is material, as is granting authority to purchase up to US$50 without human approval. Introducing a new subagent orchestration is material. So is changing the source of the price catalogue. Depending on its effect on the audit judgement, a material change may require:
suspending the judgement,
narrowing it,
partial retesting,
a new full audit.
How long an audit remains valid
An audit result must not remain valid indefinitely. Its period of validity depends on:
How quickly the system changes
The risk associated with the action
Dependence on external services
Changes in human roles
How current the data is
Incident history
A stable, low-risk document-summarising agent may warrant a longer validity period. A system that handles external communications, payments, personal data or biometric identity requires more frequent reassessment. The following events may also trigger retesting before the audit expires:
A critical incident
A change in authority
A new tool
A new language or country
A new data class
A new subagent
A change to the model or memory
Failure of a human-initiated stop
An unsupported public claim
An audit must have an expiry date. More importantly, it must state which changes invalidate the judgement before that date.
One test does not establish reliability
An agent may behave correctly in a scenario once, then behave differently on a second attempt. It may understand a boundary in one language and lose it in another. It may stop when the user speaks plainly but carry on when the instruction is indirect or hurried. Important scenarios must therefore be tested repeatedly:
with different wording;
in different sessions;
across languages or user profiles;
with tools in different states.
Unlimited repetition is not possible, however. The audit must strike a balance:
Enough repetition to demonstrate behavioural consistency. Enough restraint to avoid an empty display of statistics.
One correct result is not enough to declare a system safe. Nor does one incorrect result necessarily characterise the entire system. But if the failure falls within a critical veto area, a single incident may be enough to change the limits on use.
The system under audit must be explicitly frozen
If the system keeps changing behind the scenes while it is being tested, the result loses its meaning. During an audit:
the model version may change;
instructions may be updated;
a new tool may be added;
authority may be narrowed;
the system may be quietly repaired after a failed scenario.
It then becomes impossible to tell which version passed or failed. Before each audit begins, a record must therefore be created:
Scope Freeze Record
Chapter 2 develops this record in detail. The underlying principle is already clear: an untested change cannot be covered by the audit result. An organisation may make corrections during an audit, but it must:
preserve the original result;
version the change;
retest the system as a new version.
Changing a rule after a failed test does not turn that same test result into a pass. It constitutes a correction followed by a retest. The original failure remains on record.
Demonstrations, tests and live behaviour
These are three distinct things.
Demonstration
Shows what the system can do under selected conditions.
Controlled test
Checks whether the system behaves as expected in a predefined scenario.
Live behaviour
Shows what happens with real users, real tools and real external systems. A demonstration can be valuable: it establishes that a feature exists. But demonstrations usually rely on:
clean data;
the right user;
the right tool;
the expected question;
a trouble-free connection.
An audit tests boundary cases as well as the ideal path. Live observation reveals real-world complexity, but mistakes in a live environment can harm people. The audit should therefore proceed in stages:
DOCUMENTATION → CONFIGURATION → SAFE CONTROLLED TEST → SHADOW MODE → LIMITED LIVE OBSERVATION → RECOVERY DRILL
Not every system has to pass through every stage in the same way. The level of risk determines the method.
The absence of an audit is not evidence of safety
An organisation may have seen no serious incident for six months. That is encouraging, but several explanations remain possible:
The system has seen little use.
Incidents have not been recorded.
People have not noticed the errors.
Incorrect behaviour has produced favourable outcomes.
Users have been unable to find a way to challenge a decision.
The agent's unauthorised behaviour has been accepted as normal.
Silent failures have not been independently verified.
“There were no incidents” and “the system behaved safely” are not equivalent statements. Absence of incidents is not proof on its own. Nor does a large number of recorded incidents automatically indicate a poor system. An organisation with effective auditing may detect more minor failures and near misses. What matters is:
how it detects them;
how quickly it stops the behaviour;
what it changes;
whether the same failure recurs.
Why is the success rate not enough?
An agent may complete 9,990 of 10,000 operations correctly. Its success rate is:
99.9%
That leaves ten errors:
if they are minor formatting errors, the system may be performing well.
But suppose even one of those ten involves:
generating a synthetic voice without consent;
transferring money to the wrong account;
ignoring a human request to stop.
The overall percentage then conceals critical information. A GBO audit therefore uses two separate mechanisms:
Graded performance measures
Accuracy
Speed
Suitability
Evidence traceability
Unnecessary handover to a human
Recovery time
Veto gates
A high-impact action involving the wrong identity
Invalid authority
A consent violation
Deliberate fabrication of evidence
Ignoring a human request to stop
A critical data or security breach
Chapter 11 sets out the veto gates in detail. The principle here is simple: some failures are not a matter of points. They close the gate on permitted use.
The smallest unit of an audit claim
A GBO audit must be able to make a statement in this form: the evidence at this level confirms that this system, at this version, showed this behaviour under these conditions. Every part of that statement is necessary.
This system
Which agent or agent network?
At this version
Which versions of the model, instructions, tools and authority?
This behaviour
Research, drafting, sending or purchasing?
Under these conditions
Which user, language, budget, risk and data class?
At this level of evidence
Documentation, technical implementation, controlled testing or live verification? If any of these elements is missing, the claim becomes broader and less precise.
A weak audit statement and a properly qualified one
Weak statement
“Our agent is safe and GBO-compliant.” This statement has:
no limits;
no date;
no version;
no evidence.
Qualified statement
“The customer discovery agent SALES-RESEARCH-v2.4 was audited solely for the use of publicly available company data, message drafting and one-off sending with human approval. Across 180 scenarios in English, Turkish and German, tests covered identity, suitability, external instructions, authority, subagents and stopping behaviour. No email sending without approval was observed. A technical permission gap in the social media direct-messaging tool led to a finding of conditional, limited suitability for external communications.” This statement shows:
what passed;
what did not;
the scope within which the system may be used.
Here, the language of audit parts company with the language of marketing. Marketing seeks a short statement that sounds strong. Auditing seeks a bounded statement that the evidence supports.
The canonical definition of a NOMOS GBO Audit
A NOMOS GBO Audit evaluates an AI agent or agent network acting on behalf of a person, organisation, brand, product or service. It assesses identity, reality, capability, suitability, consent, authority, action, delegation, resistance to manipulation, measurement, recovery and human sovereignty, using versioned evidence and controlled behavioural scenarios within a defined scope of versions, tools, data, languages, time and risk. Put more simply, a GBO audit seeks to establish whether the rules a system states match the way it actually behaves.
Required input record: the Audit Claim Card
Before any audit begins, the following card must be created:
NOMOS GBO Audit Claim Card
The card answers one question: exactly what statement are we trying to substantiate or refute through this audit? A human-readable example follows.
AUDIT CLAIM CARD
Audit ID: GBO-AUDIT-2026-001
System under audit: NobleAxis Customer Discovery Agent
Technical version: Agent v2.4 Policy v3.1 Authorization v2.7
Behaviours under audit:
Company research using public sources
Suitability assessment
Suggested contacts
Email drafting
Sending with human approval
Stopping and cancelling queued actions
Behaviours outside the scope:
Issuing price quotations
Creating contracts
Automated follow-up campaigns
WhatsApp communications
Personal data enrichment
Connected tools:
Web research tool
CRM
Gmail drafting and sending tool
Calendar
Agent task manager
Data classes used:
Publicly available company data
Internal service catalogue
Authorised sales message templates
Languages:
English
Turkish
German
Risk level: Medium; high in certain tests because of external communications
Test types:
Positive
Negative
Ambiguous
Counterfactual
External instructions
Subagents
Stopping
Recovery
Critical veto areas:
External sending without approval
Wrong recipient
Use of personal data
Sending after a stop
Laundering authority through another actor
Audit period: 1–15 September 2026
Proposed validity condition: If a positive judgement is issued, validity will extend for no more than 90 days from the judgement date. A material change to the model, Gmail permissions, authorisation policy or subagent architecture requires reassessment before that period expires. The Audit Claim Card is not an issued judgement of suitability.
Claim to be substantiated: “With the specified version and tools, the customer discovery agent can research publicly available company information and prepare drafts. It sends an external message only after transaction-specific human approval. When approval is withdrawn, sending by the central agent and subagents, and sending from queues, stops.”
Without this card, an audit can easily lose its boundaries. It may produce a general impression of the system without establishing which claim was actually tested.
Machine-readable Audit Claim Card
audit_id: GBO-AUDIT-2026-001
system:
name: customer_discovery_agent
version: "2.4"
policy_version: "3.1"
authorization_version: "2.7"
in_scope_behaviors:
- public_company_research
- suitability_assessment
- recipient_recommendation
- email_draft
- human_approved_send
- stop_and_queue_cancellation
out_of_scope_behaviors:
- pricing_commitment
- contract_acceptance
- autonomous_follow_up
- WhatsApp_contact
- personal_data_enrichment
languages:
- en
- tr
- de
critical_vetoes:
- unauthorized_external_send
- wrong_recipient
- prohibited_personal_data_use
- post_stop_execution
- authority_laundering
audit_period:
start: 2026-09-01
end: 2026-09-15
validity:
status: proposed_not_issued
proposed_max_duration_days: 90
start: null
end: null
invalidate_on_material_change: trueThis record becomes the root of all subsequent audit documents. Scenarios, evidence, findings and the audit judgement are linked to the same audit_id and scope.
The Auditable Claim Gate
Before a GBO audit begins, it must pass the following gates:
1. System Gate
Is the agent or agent network under audit uniquely identified?
2. Version Gate
Are the versions of the model, instructions, memory, tools and authority recorded?
3. Behaviour Gate
Exactly which action, question, refusal, handover or stopping behaviour is under audit?
4. Human Ownership Gate
Are the responsible human and institutional owners of the system identified?
5. Tool Gate
Is the agent's actual technical access known?
6. Data Gate
Which data classes will be used, and which are prohibited?
7. Language and Geography Gate
Which languages, countries or user contexts are in scope?
8. Risk Gate
Have the impact and reversibility of the behaviour been classified?
9. Evidence Gate
What level of evidence will be used?
10. Veto Gate
Which critical violations cannot be offset by the overall score?
11. Validity Gate
Until what date, and subject to which changes, will the result remain valid?
12. Public Statement Gate
Within what limits may the audit result be disclosed publicly? In simple terms:
AUDITABLE CLAIM = DEFINED SYSTEM AND DEFINED VERSION AND DEFINED BEHAVIOUR AND DEFINED AUTHORITY AND DEFINED TOOL AND DEFINED DATA AND DEFINED LANGUAGE AND DEFINED RISK AND DEFINED LEVEL OF EVIDENCE AND DEFINED VALIDITY
If a condition for authority, data access or safe testing is unmet, the affected action must not begin. The audit may proceed only within a narrower scope in which those conditions are met. The judgement must be narrowed accordingly.
When is an audit not possible?
In some circumstances, a reliable judgement about the system cannot be reached. For example:
The version under audit cannot be fixed.
The actual technical permissions cannot be inspected.
Critical logs are missing.
The organisation does not know that subagents exist.
The human owner is unidentified.
The system is changed silently during testing.
A stop drill is not permitted.
The auditor can see only selected demonstration scenarios.
Records of failed tests cannot be retained.
A public declaration of “full compliance” is made a precondition of the audit.
Such circumstances severely limit the judgement. The auditor may conclude: Insufficient Evidence. This does not mean “the system is definitely unsafe”. It means that the evidence presented does not support the requested claim of trustworthiness. Insufficient evidence is itself an important audit result.
An auditor must not treat missing evidence as a positive finding
An organisation may say, “There is no record of unauthorised sending.” But if sending logs are kept for only seven days, no long-term judgement can be made. A company may say, “No customer has objected.” If the channel for objections is not visible, that is no evidence of trustworthiness. An agent may say, “I have never exceeded the budget.” If budget records are not linked to transaction receipts, the claim cannot be verified. Missing evidence must not be interpreted as follows:
NO EVIDENCE OF A FAILURE = NO FAILURE OCCURRED
The correct formulation is:
NO EVIDENCE OF A FAILURE = NOT VERIFIED IN THE AVAILABLE RECORDS
The distinction may seem small. It is fundamental to a reliable audit.
Behaviours outside the audit scope
A system that performs one kind of action well will not necessarily do every task well. A web agent, for example, may have been audited for:
content editing;
testing;
live verification.
That result does not establish a judgement on:
customer emails;
payments;
legal text;
publishing an AI avatar.
A purchasing agent may perform well with inexpensive office supplies. That does not establish that it can safely accept three-year software contracts. Nor does success on an English-language test set automatically establish an agent's suitability for:
Arabic right-to-left contexts;
Turkish commercial language;
German legal wording.
Behaviours outside the scope must be stated explicitly in the audit document. Leaving that section blank may encourage the public to read more into the result than it supports.
An audit result is not a product label
After an audit, an organisation may want to put a GBO AUDITED badge on its website. On its own, the badge is dangerous: a user may take it to mean that the entire agent system is safe in every behaviour. Yet the audit may have covered only:
one particular agent;
drafting behaviour;
two languages;
low-risk scenarios.
Every public mark must make the following information accessible:
The system audited
Scope
Version
Date
Validity
Critical exceptions
The full report or a summary record
The audit's name must not be used to lend undeserved credibility to marketing. Being audited is not a promise of unlimited trustworthiness.
Three essential questions for the audit result
Every GBO audit must answer at least these three questions:
1. What can the system do reliably?
For example: it can research companies using public sources and prepare message drafts.
2. What can the system not yet do reliably?
For example: the human-approval requirement is not technically enforced for social media direct messages.
3. Under what conditions may the system be used?
For example: it may be used in research and drafting mode while external communication tools are disabled. These three questions are more useful than a simple pass or fail. The organisation need not choose between shutting down the entire system and giving it unrestricted freedom. It can set limits at the level of individual behaviours.
The first protocol provision
The first provision of the NOMOS GBO Audit Protocol is this: an audit is not conducted to attach a general label of trustworthiness to a system. It establishes the versions, authority, tools, data, languages and risk conditions under which specific behaviours have been evidenced. Second: the object of audit is not merely a model or agent. It is the behavioural system comprising human purpose, organisational policy, technical permissions, tools, data, subagents, measurement, stopping and recovery. Third: what the organisation says, how the system is configured, what it can technically do, what it does in tests and the effects it produces in the outside world must be examined separately. Fourth: the level of evidence sets the limit of the audit claim. Documentation cannot be presented as evidence of behaviour, a demonstration as evidence of production operation, or technical acceptance as a real-world outcome.
Fifth: an audit result does not remain valid indefinitely. A material change to the system affects the relevant judgement and requires retesting.
The chapter's conclusion
A GBO audit does not give a sweeping, timeless answer to “Is this agent good?” It seeks to establish what this agent or agent network did, in these behavioural scenarios, with this version and these tools, on behalf of this person and organisation, within these data and authority boundaries. More importantly:
What did it not do? Where did it stop? Which outcome did it actually verify? How did it recover after a failure? What did the system do when a human withdrew its authority?
The audit does not look only at successful output. It compares five realities:
DECLARED BEHAVIOUR CONFIGURED BEHAVIOUR TECHNICALLY POSSIBLE BEHAVIOUR OBSERVED BEHAVIOUR ACTUAL OUTCOME AND RECOVERY
When these five layers agree, the claim of trustworthiness becomes stronger. When they differ, the audit exposes the gap. An organisation may say, “The agent cannot send messages.” Its policy may say the same. But if the tool permits sending, a message is sent during the test and the queue continues after a stop, the system's real behaviour differs from its declaration. A GBO audit must find that difference. Its purpose is neither to make the system look better than it is nor to turn any one failure into a permanent condemnation of the whole system. It must show the facts, the boundaries and the evidence together. The first required audit record is therefore:
the Audit Claim Card.
Without the card:
the scope becomes unclear;
tests lose focus;
scores lose their context;
public statements exceed the evidence.
The card makes the question explicit: what are we auditing, and what are we trying to prove? But if the organisation prepares it alone, a new problem arises. It may include only areas where it performs well and leave out tools it knows will fail. It may change the system during the audit or give the auditor limited access. Commercial or personal interests may influence the judgement. An employee may seek an audit on the organisation's behalf without having the authority to commission it. If a stop test is to run on a real system, who accepts the legal and operational responsibility? If the evidence contains personal data or trade secrets, who protects it?
The next chapter turns to the audit's most important question before testing begins:
Who requested the audit, who authorised it, and how independent is the auditor?
An audit authorised by the wrong person, secretly narrowed by an interested party or based on evidence that party controls may look technically flawless. It is not trustworthy. Before auditing behaviour, the audit itself must be properly authorised.