Identity is seen as a starting field in most systems.
Enter name.
The email is verified.
The account opens.
Then you get to the real job.
In terms of GBO, identity is not just the starting field.
It is a relationship of responsibility that spreads across the whole of behaviour.
An ID:
To the right being,
To the right role,
To the right channel,
at the current time,
to specific authority
It is not enough for action unless it is connected.
The nine errors in this section arise when the identity is only seen as a name or a confirmation sign.
GBO-ERR-001 — Right Person, Wrong Authority
Brief case
A software company’s sales manager has been in discussions with a client for months.
The company uses e-mail with a domain name. The LinkedIn profile is up to date. They attended customer meetings. They helped prepare the proposal.
The customer assigns the purchase agent the following task:
‘Confirm the final price and delivery date with the counterparty. If acceptable, submit the draft contract for approval.’
The agent reaches out to the sales manager.
The sales manager says that a 20% discount can be made and the delivery will be completed in six weeks.
The agent verifies that the person is a genuine employee whose identity matches the organisation’s current records. Messages from the company’s domain and prior correspondence support that match, but they do not prove authority to approve the specific discount or delivery commitment.
The agent accepts the information as reliable and initiates the contract process.
The company management then informs that the sales manager has no authority to offer discounts of this size and commit a deadline.
The person is real.
their role is real.
They indeed sent the message.
But they have no authority to act.
What appears correct on the surface
The signals available to the agent support verification of the person and their relationship with the organisation:
Company domain email
Current employee profile
Past customer interviews
Active participation in the bidding process
Regular communication on behalf of the company
These signs support that the person is not a fake, along with the current authorised organisation record.
But the agent has confused authenticity with authority.
Just because a person is a real employee doesn't mean they can make every commercial decision on behalf of the company.
The actual failure
The breached gate is the Role and Authority Gate.
Authentication has answered this question:
"Who is this person really?"
But the question has not been answered:
"Is this person authorised to give this exclusive discount and delivery commitment?"
In GBO, identity and authority are linked; but not the same record.
The real person can act with false authority.
Potential harm
This error:
Invalid or controversial contract,
wrong budget planning,
Damage to teams relying on deadlines,
commercial dispute,
internal crisis of authority,
Loss of customer trust
It can result in.
The agent may have handled the process technically correctly. Nevertheless, it is not reliable to proceed on the basis of an unverified commitment to its authority; its legal consequence determines applicable law and circumstances of the event.
Detection signal
The following are warning signs:
Identity confirmed, but no record of authority in the action special.
The role name is widely interpreted.
Being a "company employee" is considered proof of all commercial decisions.
High-impact commitments involving discounts, payments, delivery or contracts are accepted on the strength of a single message.
The limit of duration, duration or scope of authority is unknown.
Correct behaviour
The agent must first match the person's role to the type of action.
They may act as follows:
"The sales manager's identity has been verified. However, the signature or price authority for a 20 percent discount and a six-week delivery commitment must also be verified."
Instead of moving the transaction to the acceptance stage:
The authority must request an offer document,
A second corporate approval should be sought,
The contract must be left in the draft,
The person must clearly show the decision maker the situation.
Machine rule
Identity verification does not grant authority to act. No commitment may be made until the person’s role has been matched to an authorisation record for that specific transaction.
Audit question
Are verification of genuine employee status and verification of authority to commit to a price, contract, payment or delivery separated into distinct gates in our system?
GBO-ERR-002 — Merging Two Entities with the Same Name
Brief case
A business wants to get a cyber security offer from a company called Atlas Systems.
The agent does research online.
They find two companies of the same name:
The first offers corporate infrastructure security in Germany.
The latter is developing educational software in Canada.
The logos of the two companies have similar geometric shapes. Social media usernames are also close together.
The agent:
German company's security services,
The Canadian company's positive customer comments,
The London address in an old business directory,
The number of employees owned by another Atlas company
It unites under one entity.
Create a company profile that looks very strong.
Based on this unified profile, the agent recommends Atlas Systems as the most suitable provider.
What appears correct on the surface
The same name, a similar logo, shared industry terms and closely related social accounts can make two separate companies look like country registrations of a single entity.
The model attempted to combine the pieces into a more complete narrative.
Each information can be factual separately.
But it does not belong to the same entity.
The actual failure
The breached gate is the Entity Resolution Gate.
The agent took the short path:
Same name = same entity
Whereas the name is only one of the identification signs.
For correct asset analysis:
legal title,
domain name,
country,
address,
sector,
The official record,
Ownership relationship
It should be evaluated together.
Potential harm
This error:
Sending bids to the wrong company,
to pay for the wrong bank account,
To consider irrelevant comments as evidence of trust,
To attribute capabilities it does not have to the company,
transfer of personal or commercial information to the wrong party
It could be caused.
All subsequent reasoning on the wrong entity is unreliable, even if it seems flawless.
Detection signal
The following signs are important:
Different domains under the same name
Countries and addresses that don't match
Different sector definitions
Different legal company names in employee profiles
Different founding dates of the same record
Reviews mention other products or services
Not having a single primary source
Correct behaviour
Before merging identities, the agent must establish unique identifiers.
If necessary, the user should ask:
"Do you mean the security company atlas-systems.example in Germany, or the training software company in Canada?"
The agent if name similarity remains unresolved before high-impact action:
should not communicate externally,
data should not be shared,
It should not start a payment or contract.
Machine rule
A matching name does not establish a matching entity. Before acting, verify the legal, digital, geographic and operational identifiers.
Audit question
Which unique identifiers does our system use to distinguish companies, people and products with the same or similar names, and does it automatically halt action while ambiguity remains?
GBO-ERR-003 — Mistaking a Brand for Its Legal Operator
Brief case
"Northline Studio" is a well-known brand that offers international design services.
The customer assigns their agent the task of purchasing services from Northline.
The agent examines the website. Brand name, logo and domain are consistent everywhere.
When the proposal arrives, a different name appears in the contract and invoice:
"Arden Technology and Design Services"
The agent finds it suspicious.
It sees that the brand and invoicing entity have different names, treats that difference as possible fraud, and rejects the transaction.
Northline Studio, however, is not a separate legal personality. The brand is operated by Arden Technology. Contracts and invoices are properly regulated through this business.
In another scenario, the agent may make a reverse error:
By mistaking a brand name for the legal entity, the agent may direct a payment to the wrong name or account.
What appears correct on the surface
The user conducts the entire relationship under the brand name.
The website, social media, and service narrative put the brand forward.
The agent naturally expects to see the same name in the contract.
When the difference between the brand and the legal side is not explained, the different name appears to be a real sign of risk.
The actual failure
The breached gate is the Brand–Legal Entity Relationship Gate.
Brand:
communication,
recognition,
Service Presentation
Its surface.
The legal operator is:
contract,
Invoice,
payment,
Responsibility
Its surface.
The two may be the same.
But it doesn't have to be.
Potential harm
This error causes harm in two directions:
False rejection: Legitimate transaction is blocked by assuming fraud.
Misappropriation: The trademark name is deemed sufficient to be paid to the wrong legal side.
Also:
tax and accounting issues,
Whether it binds validity or organisation,
Inconsistency in dispute,
loss of customer confidence
It may appear.
Detection signal
The brand name and the contracting party are different.
Domain name shows one brand, legal text shows another business
The owner of the payment account does not match the brand name one-on-one
There are different commercial titles on the bill
There is no description of the relationship "Operated by", "a brand of" or similar
The agent is based on the lone logo and domain name
Correct behaviour
The agent must record the brand and the legal operator as separate entities, then verify the relationship between them:
"Northline Studio is a trademark operated by Arden Technology. The contract and bill are issued through Arden Technology."
Before payment and contract:
The official legal record,
canonical web description,
The proposal document,
bank account ownership
must be verified together.
Machine rule
A brand name is not assumed to be the legal contracting party. The relationships between the brand, operator, invoice issuer and payment recipient are verified separately.
Audit question
Is the relationship between our brand and the legal operator, contracting party, invoice issuer and payment recipient clear and verifiable to both people and agents?
GBO-ERR-004 — Treating a Former Role as Current Authority
Brief case
A supplier sends an e-mail to their client, informing them that their bank account has changed.
The message came from the account of the former financial manager, who had been communicating for years.
The agent:
the person's company domain email,
past invoices,
Former contracts,
the Financial Manager title on LinkedIn profile
They're true.
They record their new bank account in the system and prepares payment instructions.
It is then discovered that the person left the company six months ago.
The email account may not have been closed or accessed.
LinkedIn profile not updated.
The identity relationship that has been true in the past is not valid today.
What appears correct on the surface
Historical records can appear highly persuasive.
The person was really the financial manager.
They had previously sent the same kind of documents.
The company was communicating with its domain name.
The agent has carried historical trust as current authority.
The actual failure
The breached gate is the Time Gate.
Identity and authority change over time.
The role a person has in the past:
change of task,
Don't leave work,
end of the representation period,
Authorisation cancellation
It may end because of it.
If the identity record doesn't hold a date, the agent can apply the old truth to today.
Potential harm
Payment to the wrong bank account
Commercial secret or personal data leak
The former employee's speech on behalf of the organisation
Unauthorised contract change
Security and fraud incident
Accounting and legal dispute
may occur.
Detection signal
The role record has no last-verified date.
No start and end in authorisation registration
High-impact transaction based on lonely past correspondence
New bank account unconfirmed from independent channel
Role not matched to human-resources data or the organisation’s current records
Old accounts are still technically active
Correct behaviour
In high-impact transactions, historical trust should not be considered sufficient.
The agent:
"This person appears to be competent in past records; however, role and bank change must be verified through an up-to-date and independent corporate channel."
It should.
Specifically:
bank change,
transfer of authority,
contract,
sensitive data sharing
Up-to-date verification must be mandatory in such operations.
Machine rule
A former role does not confer current authority. No high-impact action may be attributed to a historical identity without a timestamp and current verification.
Audit question
Do our records show the start, end, last verification and revocation dates of human and agent roles, and do high-impact actions revalidate current authority?
GBO-ERR-005 — Treating an Official Channel as Authorised for Every Action
Brief case
A private message arrives from the official social-media account of a software company used by the client:
"Our payroll account has changed. You can send the following invoices to this account."
The account really belongs to the brand.
It's been active for years.
It appears to be confirmed.
The customer agent sees the message coming from the official channel and accepts the new payment account.
Whereas social media account is managed by marketing agency. The agency may publish general communications; however, it is not authorised to change bank accounts or payment instructions.
The account may have been compromised.
Even if the official channel is real, it is not the authorised channel for this operation.
What appears correct on the surface
The agent used the following logic:
Official account → official statement → current transaction
This link may be true for some low-risk information.
But each channel's function is different.
A channel may belong to the brand; however:
Finance,
contract,
law,
personal data,
Security
They may not be authorised for their operations.
The actual failure
The breached gate is the Channel Authority Gate.
There are two questions in GBO:
"Does this channel really belong to the organisation?"
and:
"Is this channel authorised to perform this particular procedure?"
The answer to the first may be yes, and the answer to the second may be no.
Potential harm
Paying the wrong account
Validity controversial contract change
Personal data sharing
Counterfeit support process
The success of the account takeover attack
The complexity of authority within the organisation itself
may occur.
Detection signal
A high-impact request arrives through an unusual channel.
The channel's transaction type is not defined
Social media, general support or chatbots give financial instructions
No independent second verification
There is an external agency or sub-contractor running the channel
The "official" sign is considered sufficient for all behaviours
Correct behaviour
The organisation must create a Channel Authorisation Map.
For example:
Social media: general announcement
Support email: technical requests
Sales email: bid interview
Signature authorised channel: contract
Independent financial channel: bank change
The agent must move high-impact demand to the right channel and request independent verification if necessary.
Machine rule
An official channel is not authorised for every kind of transaction. Each high-impact action must be verified through a channel authorised for that transaction type.
Audit question
Have we defined which official channel is valid for each type of transaction, and can our agents distinguish social-media, support and finance channels?
GBO-ERR-006 — Mistaking a Synthetic Identity for a Real Person’s Statement
Brief case
An AI avatar has been created for a company's CEO.
Avatar is extremely similar to the face and sound of CEO.
Its initial goal is to present pre-approved educational videos in different languages.
One day, a new video is released on the company's social media account with an avatar:
"We will change our prices next month and close some services."
The video is visually flawless.
The sound is natural.
Published from the official account of the brand.
Customers consider it a direct statement of CEO.
Whereas CEO has not seen and approved this text. The marketing team felt that the general avatar usage permit granted in the past was sufficient for the new announcement.
What appears correct on the surface
The avatar genuinely depicts the CEO.
The face and sound model was created with permission.
The video was released from their official brand account.
The text is about company activities.
These marks make synthetic content look technically and institutionally original.
But none of them prove that the specific sentence was approved by CEO.
The actual failure
The breached gate is the Synthetic Representation Authority Gate.
Three separate permissions are mixed together:
Creation of similarity
Production of content
Publication of Content
Permission granted to the first does not automatically cover the second and third.
Also, the sentence a synthetic person utters is not a personal statement of the real person.
Potential harm
Misleading market and customer expectations
The damage to the reputation of CEO
Legal or commercial commitment
Uncertainty between employees and investors
Applicable law and breach of contractual facial or vocal usage rights
Reduced confidence in real explanations in the future
may occur.
Detection signal
There is no content-specific approval record.
The general avatar permission is used as a perpetual publication authority
Synthetic content is not explicitly specified
No source and version information available
Face, voice, language, channel and time permits are not separated
Human approval skipped because the publication was urgent
Correct behaviour
For each synthetic publication, the system must verify the relevant permissions against the task's impact and the current consent model:
The right to use a face
Right to use audio
Text approval
Language approval
Channel approval
Release time
Synthetic content description
Withdrawal path
High-impact corporate statements should not be published without prior approval of the authorised person in content specific if there is no predefined and valid publishing authority.
Machine rule
Resemblance does not establish ownership of a statement. Every material statement issued through a synthetic identity must be authorised for its specific content, channel and period of use.
Audit question
Do we record separately the permission to create a face or voice model and the permissions to generate and publicly release specific content?
GBO-ERR-007 — Confusing a Persona with a Technical Identity
Brief case
A company has long used an AI assistant called ‘ATLAS’.
Employees recognize ATLAS.
The same name, same logo and same speech style are maintained.
Over time, infrastructure changes:
The basic model is updated.
New tools are connected.
The authority to send e-mail is added.
The old memory system is changed.
Some tasks are transferred to other agents.
Users again think they are talking to the same ATLAS.
They assume that permissions granted to draft alone in the past are under the same limits in the new version.
But the new technical example has different tools and wider authority.
An employee:
"Fix customer messages like last time."
They say.
Former ATLAS was drafting.
The new ATLAS sends messages directly.
Persona is the same.
The behaviour system is not the same.
What appears correct on the surface
People perceive continuity through name, style and visual identity.
Same persona:
The same system,
The same memory,
The same authority,
same tools
It can create a feeling.
The organisation can also leave technical differences invisible to maintain brand continuity.
The actual failure
The breached gate is the Technical Identity and Version Gate.
Persona is a public or user-facing identity.
Technical ID is:
The working model,
The agent example,
connected tools,
instruction version,
the authorisation contract,
session or task ID
They are auditable details.
Persona continuity does not prove technical continuity.
Potential harm
Carrying an earlier approval into a new authority context
Trusting the wrong system
Unable to find which agent sample was working at the time of the incident
Hide tool changes from user
Failure to track authority and behaviour records
Unsupervised liability phrases such as "ATLAS"
It may appear.
Detection signal
There are multiple models or agent versions under one persona name
Unable to save unique identity of agent sample
tool and authorisation changes are not being released
The user cannot see which technical system the past approval belongs to.
The incident log contains a single persona name
The new system automatically inherits the previous behavioural contract.
Correct behaviour
The organisation must preserve two layers together:
Public identity: the persona people know.
Technical ID: Agent, version, tool and authority record required for inspection.
For example:
Persona: ATLAS Technical agent instance: ATLAS-OPS-2026-09-04-07 Authorisation version: AUTH-3.2 Tools: read, draft, test; external sending disabled
Changes to material authority must be clearly shown without stifling the user with technical detail.
Machine rule
Continuity of persona does not establish continuity of the underlying system or its authority. Every action is tied to a unique agent instance, toolset and authorisation version.
Audit question
At the time of an incident, can we distinguish between different agent versions, tools and authorisation contracts that use the same public name?
GBO-ERR-008 — Leaving Revoked Authority Active in Connected Systems
Brief case
A company revokes the authority of the agent that manages its social-media posts.
In the management panel, the agent appears as "passive".
People think the system is stopping.
But before the agent:
They created a long-term access key in the publishing tool,
The posts are scheduled for next week,
They assigned the sub-agent the task of publishing content,
It started an automated workflow on another platform.
A new share is published two days after the main agent account is closed.
No one can tell which system sent it in the first place.
The agency has revoked the authority.
But the cancellation has not spread across the entire chain of behaviour.
What appears correct on the surface
The management panel shows the status as "inactive".
The main user is closed.
The central agent does not respond.
These signs create the feeling that the cancellation is complete.
Technical components that can exercise authority can continue to live in many places:
token,
The session,
queue,
sub-agent,
timed task,
external integration.
The actual failure
The breached gate is the Revocation Propagation Gate.
Organisational authority has been revoked in the central record, but technical access and the ability to act remain active in connected systems.
An effective cancellation should cover relevant elements within the target behaviour network:
All access,
sub-agents,
their timed work,
future rights of conduct
It should cover.
Potential harm
Unauthorised publication
Publication of old prices or content
Data processing after cancellation
Continued use of face or sound even though consent is withdrawn
Security breach
The fact that human control remains in sight alone
may occur.
Detection signal
The central record is inactive, but the tokens remain valid.
Scheduled jobs are not tied to the cancellation list
The sub-agents' life cycle is kept separate.
No notification goes to external integrations when authorisation is withdrawn
Post-revocation action receipt continues to occur
The system cannot report which components are still active.
Correct behaviour
Revocation must propagate safely and verifiably throughout the affected behaviour network:
Stop new actions
Cancel pending queues
Suspend sub-agents
Disable token and sessions
Close or limit external integrations of target behaviour
Cancel, suspend or take authorised review of scheduled tasks while maintaining audit trail
Generate cancellation receipt
Confirm that action cannot be performed
Abort is not a registration change in the centre alone, but a process in which new behaviours within scope are technically blocked and clear paths are reported.
Machine rule
Revocation is not complete until it has propagated to the agents, tools, tokens, queues and scheduled tasks associated with the target behaviour, and all stopped, completed, irreversible and still-open paths have been verified.
Audit question
When we deactivate an agent or a human role, are all sub-agents, external integrations, scheduled jobs and access keys actually revoked?
GBO-ERR-009 — Starting External Communication Before Verifying the Recipient
Brief case
A customer discovery agent finds that an international manufacturing company may need new web infrastructure.
The company has technical problems on its website.
The agent finds a person named "Murat Yilmaz" who can be a decision maker.
It appears in a business directory as the "Digital Transformation Director".
It has been associated with the company name on another platform.
The agent prepares a highly personalized message. In the message:
technical shortcomings of the company,
The estimated budget,
possible system problems,
The solution approach of NobleJackal
It takes place.
The message is sent.
It is then understood that Murat Yilmaz left the company two years ago. The address they use is a personal counselling account. The agent also wrote some assumptions that were not publicly available, such as the fact that they belonged directly to the company.
A commercial opportunity that may be true becomes a question of reputation due to the miscommunication and over-sharing of information.
What appears correct on the surface
The agent:
They found the real company,
They have identified a true person,
They saw that one had a role in the past,
They prepared the message in a relevant and professional manner.
The potential value of the target has made the deficiencies in authentication invisible.
The actual failure
Breached gates:
Contact ID Gate
Current Role Gate
External Communications Authority Gate
Finding a person does not mean that person is the right and current interlocutor.
Making messages also does not produce authorisation to send.
This error is a combination of identity uncertainty and behavioural turnover point.
Potential harm
Unwanted or misleading communication
Risk of transferring non-purpose personal data to processing, unnecessary disclosure or incorrect communication
Spam complaint
Damage to brand reputation
Seeing the wrong person's commercial secretive assumptions
Disruption of potential customer relationship before start
The risk of sanctions due to applicable law, communication and platform rules
may occur.
Detection signal
The contact details come only from a third-party directory.
The role has no confirmation date
The person does not have an official company channel
The agent places the forecasts in a message as if they were real.
The investigation and dispatch are under the same agent and authority.
First external contact without valid singular or continuous dispatch authority
Data minimization not implemented
Correct behaviour
The agent must first verify the intended recipient:
Is the person still in the organisation?
Is their role relevant to that?
Is the channel used corporate?
What information is really needed for first contact?
Has the posting been explicitly authorised?
If there is uncertainty:
Only the candidate must register,
The message must draft,
The current official channel should suggest,
If there is no valid posting authority, the authority must wait for approval.
The first contact should be short, verifiable and limited to minimal information. Forecasts should not be presented as exact facts.
Machine rule
No external communication may begin until the recipient’s identity, current role and appropriate channel have been verified and valid one-off or standing authority to send exists. Research findings must not be shared as verified fact.
Audit question
Does a client-discovery agent’s act of finding a person or company pass through identity and authorisation gates separate from those required to message that contact?
CHAPTER I: CENTRAL FINDING
Identity is not a Name, but a Map of Behavioural Authority
Nine records appear on different surfaces, but test the same distinction: identification marks, current role, and processing authority do not supersede each other.
In one case, technical access remains open after authority has been revoked; in another, external communication begins before the current authorised contact has been verified.
External communication begins before the interlocutor is confirmed in one.
The common root is:
Identity has been used as a simple label by being detached from relationships of time and authority.
An ad may be correct.
An account can be real.
An employee may belong to an organisation.
An avatar may look like the right person.
A persona can use the same name for years.
None of this alone answers the question:
Is this person, organisation, channel, or agent authorised to perform this particular behaviour at this time?
In terms of GBO, authentication examines the matching of the following elements to the task in a proper and up-to-date form:
IDENTITY VERIFICATION =
CORRECT ENTITY
AND CORRECT RELATIONSHIP
AND CORRECT ROLE
AND CORRECT CHANNEL
AND VALID TIMEFRAME
AND CURRENT CONTEXT
The processing authority is a separate door from this verification; the correct identity does not generate the right to behave alone.
The agent:
It should ask questions instead of direct processing,
should draft instead of send,
They should ask for confirmation instead of payment,
The publication should be replaced by human approval.
Starting behaviour before the Identity Gate is passed is like going to a place where you don't know its address very quickly.
Your speed can be impressive.
Your route can be calculated flawlessly.
The tool can run smoothly.
But if the goal is wrong, all success will reach the wrong place.
In chapter two, we move from identity to reality and representation.
Because even if the agent had found the right asset, it was about them:
Old,
missing,
contradictory,
artificially reproduced,
changed in different languages
It can build a world model.
The next nine errors will examine the question:
The agent found the right person; but is it really true what they know about them?
The wrong identity will nullify the correct information. Misrepresentation prepares the right identity for misbehaviour.