Who Are You?

Consider an entirely fictional example. A company wants quotations from three software providers for a new client portal. The name ‘Nova Digital’ in this example makes no claim about any real company.

The manager gives an AI agent a short instruction: ‘Find Nova Digital. Ask them for a quotation for our six-language portal project.’ The agent searches.

Several different results appear under the name ‘Nova Digital’:

• a software company operating in Istanbul,
• a digital marketing agency registered in London,
• an independent designer using the same name,
• an old domain no longer in use,
• a social media account managed by another company,
• and a business-directory profile that has not been updated for years.

The agent chooses the domain that looks strongest. It believes it has gathered enough information about the company. It prepares a detailed request for quotation, including the project budget, the name of the existing CRM system, the number of employees and the target delivery date. It sends the message. Two days later, a reply arrives. The recipient is interested, suggests a meeting and supplies bank details for an advance payment. Everything looks normal. But the message has gone to the wrong Nova Digital. The intended company is the client-portal provider in Istanbul. The company the agent has contacted is the advertising agency in London. The information the agent found is not entirely invented. The domain is real.

The company is real. The contact address works. A real employee has replied. But correct information has been assembled around the wrong identity. This is more than a search error. It is an identity-resolution error. The agent found an entity but failed to establish correctly whom it was dealing with. If a machine does not know whom it is dealing with, it cannot act safely, however thoroughly it researches, however accurate its sentences or however powerful the tools it can access.

GBO’s behavioural contract therefore begins with this question:

Who are you?

A name is not an identity

In everyday life, people use names in place of identities. ‘Call Ahmet.’ ‘Book with Atlas Hotel.’ ‘Look at the Central Bank’s statement.’ ‘Send a proposal to Nova Digital.’ Context usually helps us understand which person or organisation is meant. Even when several people share a name, our contacts, past conversations, mutual acquaintances and location help us choose the right one. Machines do not always have that context.

The same name can be used by different:

• companies,
• people,
• brands,
• branches,
• products,
• social media accounts,
• or old and new organisations.

The reverse is also possible: the same entity can appear under different names in different places.

A company may have different names for its:

• legal registration,
• brand,
• domain,
• social media handle,
• product,
• local-language presence,
• and international market presence.

Identity is therefore more than a name. It is the structure that explains the entity behind a name and its relationships with other people, organisations, domains, powers and time. In this book, we examine identity through the links between entity, relationship, role, authority, time and evidence. This is a framework for enquiry, not a scoring formula. Knowing just one element is not enough. Knowing someone’s name does not establish their authority to sign for a company. Knowing that a domain belongs to a company does not show that every page on it is current.

Verifying that an employee really works for an organisation does not prove their authority to quote prices or accept contracts. Knowing that an AI agent is genuinely operated by a company does not mean it can perform every transaction on that company’s behalf. Identity is not a label. It is a chain of responsibility.

The layers of identity

An organisation or person does not have a single-layer identity in the digital world. There are several connected layers. Confusing them can send agent behaviour in the wrong direction.

Human identity

This is the natural person. It concerns their name, contact channels, roles and right to carry out particular transactions. Yet verifying who a person is does not establish that they have the same authority in every context. Someone may work for a company without being authorised to sign contracts on its behalf. Someone may have written a book without owning the platform on which it appears. Someone may have founded a brand while legal transactions are conducted through another company. Human identity matters.

For action, however, it must be read alongside role and authority.

Legal identity

Legal identity shows which person or legal entity stands behind a contract, invoice, payment or formal responsibility. A brand may not be a separate legal person. A domain may be owned by another company. A project may be promoted under a brand while invoices use a different legal name. That is not inherently a problem. The problem is an unexplained relationship. Seeing the brand’s name, an agent may assume a contract will be concluded under that same name. If a payment request points to another legal entity, the agent may mistakenly treat the difference as a sign of fraud.

Or it may make the opposite mistake and pay the wrong legal entity because it knows only the brand name.

For GBO, these relationships must be clear:

Who operates the brand? Who enters into the contract? Who issues the invoice? Who receives payment? Who is responsible if a dispute arises?

Brand identity

The brand is the face people and machines recognise in everyday life. Its name, logo, domain, service language, published work and market positioning make up its identity. But brand identity and legal identity are not equivalent. The brand is the face of communication and relationships; legal identity locates responsibility and commitments. An agent must be able to connect them without treating them as interchangeable.

Operational identity

This shows how an organisation actually works. Which team does which work?

Which department quotes prices?

Who approves publication to the live environment?

Who can access client data?

Who may only prepare drafts?

Who may make payments?

Who may send messages outside the organisation?

Someone labelled ‘manager’ on an organisation chart may not be authorised for every operational action. An employee with a more junior title may have extensive technical powers over a particular system. Operational identity explains how authority is distributed in day-to-day work.

Digital identity

Domains, email addresses, social media accounts, platform profiles, digital signatures, API clients and machine-readable records all form part of digital identity. An email address on a company’s domain may inspire confidence, but the account could be compromised. A social account may appear verified, but it might now be controlled by a former employee. A website may be official, but some pages may not have been updated for years. Digital identity alone is not the final word on trust. It must match the other layers of identity.

Agent identity

This is the new and increasingly important layer.

An AI agent needs an identity that explains:

• on whose behalf it works,
• the purpose for which it was created,
• which systems it can access,
• which operations it may perform,
• which operations it may not perform,
• and when it must seek human approval.

General names such as ‘research assistant’, ‘customer-service agent’ or ‘purchasing agent’ are not enough. The agent’s identity must be defined alongside its action envelope. It may no longer be producing answers alone. It can leave traces in the world on an organisation’s behalf.

The identity triangle

We can examine an agent action through three identity roles. A single entity may combine these roles, and each role may involve several actors:

1. The requester

The person or organisation asking for the action.

2. The actor

The agent or network of agents carrying out the task.

3. The counterparty

The person, company, system or entity towards which the action is directed.

We can call these three roles the identity triangle.

When an email is sent:

• Who requested it?
• Which agent sends it?
• Which person or organisation receives it?

When a purchase is made:

• Who is using the budget?
• Which agent performs the transaction?
• Which legal entity sells the product?

When social media content is published:

• Who makes the communication decision?
• Which system creates and publishes the content?
• On which account, on whose behalf and for which audience is it published?

When a website is updated:

• Who defines the objective of the change?
• Which agent changes the file?
• Which site is changed, who operates it and whom does the change affect?

An unclear corner of the identity triangle puts behaviour at risk. If the requester is unverified, the agent may take instructions from the wrong person. If the agent’s identity and authority are unclear, the user cannot know which system is acting. If the counterparty is misidentified, a correct operation may be applied to the wrong person.

Before any important action, three questions must therefore be asked:

Who wants it done? Who is doing it? To whom, or in relation to whom, is it being done?

Being genuine is not the same as being authorised

A common mistake in identity verification is treating proof that a person or account is genuine as sufficient. An employee may genuinely work for a company but have no authority to offer discounts. A manager may really hold that position but lack authority to instruct payment to a particular bank account. An AI agent may genuinely be operated by a company but have no permission to transfer client data to another system. A social media account may genuinely belong to a brand, yet not every message on it is an authorised statement that creates a legal commitment.

There are therefore two separate questions:

Who is this, really? Is this person or system authorised to do this?

The first concerns identity verification; the second, authorisation. Identity verification establishes that the person or system matches the claimed identity at the level of confidence the transaction requires. Authorisation determines whether that identity is permitted to perform the particular action. Agent systems must not confuse the two.

A genuine person is not always an authorised person. An official account is not an authorised channel for every transaction. Access to a system is not authority to change it.

This distinction becomes critical in payments, contracts, public statements, personal data and organisational commitments.

A role is not a person

Roles change within an organisation. Today’s chief executive may hold a different position tomorrow. A project manager may leave. An email address may be passed to another employee. A different agency may take over a social account. A technical manager may have publication authority only for the duration of a particular project. Role information must therefore be read together with time. ‘This person is the CEO’ is incomplete.

A more accurate statement would be: ‘As of this date, this person is the organisation’s CEO and is authorised for these types of transaction.’ A role is not a permanent attribute attached to a person. It is a relationship within a particular organisation, period and scope. Agents must not automatically infer action authority from a title. A company’s founder may not be authorised to make payments for it. A finance manager may not be authorised to issue public statements for the brand.

A social media manager may not be authorised to change contract terms. A developer’s access to a live system does not establish their right to set pricing policy. The name of a role does not, by itself, define the boundaries of behaviour.

Authority depends on context

Authority is not a general, unlimited attribute.

A person or agent may be authorised:

• within a particular system,
• for a particular task,
• during a particular period,
• up to a particular level of risk,
• and below a particular amount.

A purchasing agent may be allowed to buy office supplies worth up to $100, but not start an annual subscription. A web agent may change a test environment, while production deployment may require separate approval. An email agent may prepare drafts without having permission to send them outside the company. An AI avatar system may narrate pre-approved training scripts without authority to generate new political statements.

An authority record must therefore answer:

• Which action?
• For what purpose?
• In which system?
• For how long?
• Using which data?
• Directed at which person or organisation?
• At what level of risk?
• For what amount?
• With which human approval?
• With what method of reversal?

If part of the authority is missing, the agent must not interpret the gap expansively.

Unclear authority is not broad authority.

The same name, different entities

Name collisions are an easily overlooked problem in identity resolution.

The same name may be shared by:

• companies,
• hotels,
• doctors,
• consultants,
• products,
• software packages,
• or university departments.

If an agent relies on a name match alone, it may select the wrong entity.

Other distinguishing details are needed alongside the name:

• Official domain
• Country or city
• Legal name
• Tax or company-registration details
• Sector
• Authorised contact channel
• Brand logo
• Organisational relationship
• Product or service scope

Someone says: ‘Make a booking with Atlas.’

The agent may need to ask: ‘Atlas in which city? Is it a hotel, restaurant or travel company?’ Asking is not slowness. It is safer than acting quickly on the wrong entity.

Different names, the same entity

Errors also occur in the opposite direction. An organisation’s legal name, brand and domain may differ. A company may have acquired another brand. A product may have changed its name. An author may use a pen name. An organisation’s name may be written differently in different alphabets.

For example, a company may appear to have different names in:

• the Latin alphabet,
• Arabic,
• Cyrillic,
• the local commercial register,
• and its international branding.

If an agent treats these as separate entities, information fragments. A good reputation in one language is not connected to another. Prices appear to belong to different companies. Published work cannot be linked to the brand. For GBO, getting identity right means not only separating entities correctly, but joining records correctly too.

A machine must ask: ‘Are these different entities?’

It must also ask: ‘Are these different faces of the same entity?’

The identity graph

An entity’s digital identity often cannot be described in a single-line record. Identity consists of relationships.

For example:

• A person is the founder of a brand.
• The brand is operated by a legal entity.
• The domain belongs to the brand or is used on its behalf.
• The brand controls a social media account.
• Particular agents are authorised for particular tasks.
• A publication was created through the joint work of particular people and systems.
• Invoices are issued under a different legal name.
• A partner has authority to represent the organisation in certain countries.

These relationships can be understood as an identity graph. The connections matter as much as the nodes. ‘This person is connected to this company’ is not enough.

The kind of relationship must be specified:

• Founder
• Owner
• Employee
• Authorised representative
• Editor
• Technical operator
• Service provider
• Client
• Publisher
• Agent
• Subcontractor

An incorrect relationship joins the right entities into the wrong story. Someone may have written a book about a company without legally representing it. An agency may manage a brand’s social media without owning the brand. An infrastructure provider may host a website; hosting alone does not show that the provider has verified every claim in its content. The parties’ legal responsibility must be assessed separately under the service relationship and applicable rules.

In the identity graph, GBO asks not only ‘Who is connected to whom?’ but ‘What rights and responsibilities arise from that connection?’

The canonical identity record

An organisation needs a versioned source that explains all its identity relationships.

We can call this the canonical identity record.

It can include at least:

• Primary brand name
• Legal operator
• Official domains
• Alternative names in use
• Official social and digital channels
• Authorised contact addresses
• The relationship between brand and legal entity
• Authorised people and roles
• Agent names and areas of responsibility
• Which channel is valid for which transaction
• Last update date
• Version information
• Revoked or outdated records

Not all of this must be public. Some parts may be held at different access levels for clients, partners or internal systems. What matters is having a single source of truth.

A canonical record does not mean everyone sees everything. It means the right person can verify the right identity information at the right time.

The NOMOS Identity Contract

The first component of the NOMOS Behavioral Contract Layer will be the NOMOS Identity Contract.

Its canonical definition is:

The NOMOS Identity Contract is a versioned identity record that establishes who a person, organisation, brand, product or agent is; the names by which they are known; who operates or represents them; which digital channels and interfaces are authorised; the period and scope for which authority is valid; and how these relationships are to be updated or revoked.

Put simply, the Identity Contract tells a machine more than your name. It explains the conditions under which it can safely engage with you.

The identity contract distinguishes four things:

Claim

What does an entity say about itself?

Evidence

What supports this identity or relationship?

Authority

Which behaviours may this person or system carry out?

Validity

On which dates and under which conditions is this information valid?

A company may say on its website: ‘This is our official support account.’ That is a claim. A domain, organisational record or link to an administration panel may support it. That is evidence. The account may answer support requests but not change contracts. That is authority. This authority may last only for the term of a particular service-provider agreement. That is its validity limit.

Four levels of identity verification

Not all identity information carries the same confidence. This book uses four states as a practical distinction. They are not levels in an official identity-assurance standard, but a model describing the progression from identity to action authority.

1. Claimed

The person or organisation declares its own identity. ‘I am the company’s sales manager.’ This may be true, but it is not yet supported.

2. Linked

The identity has been associated with an apparently official digital presence. An email address on the company domain, an official profile or a canonical page may show that relationship. But the account could have been compromised, or the information could be old.

3. Verified

One or more pieces of evidence have verified the identity at a level of confidence sufficient for the transaction. The method varies with the action’s risk. A newsletter subscription and a high-value payment do not require the same level of verification.

4. Authorised

The identity has not merely been verified: valid authority for the particular action has also been established. For GBO, this final level matters. Proving that someone is genuine is insufficient unless their authority for the transaction is also shown.

Identity assurance depends on action risk

Applying the same verification burden to every behaviour may be unnecessary and harmful to privacy. A user does not need to provide passport details to view a general product catalogue. Yet a similar name is not enough for a high-value bank transfer. Identity checks should therefore be proportionate to the action’s impact.

For low-risk actions, the following may suffice:

• a verified email address,
• a session,
• or a straightforward account relationship.

The required assurance may be met in this way.

High-risk actions may require:

• multiple verification measures,
• a legal-entity check,
• confirmation of the authorised person,
• transaction-specific approval,
• or verification through an independent channel.

These additional checks may be necessary.

The principle is to use the most appropriate level of verification for the need, not the strongest level technically possible. Excessive verification can cause harm too. Collecting personal documents without a need increases privacy risk. GBO does not interpret security as unlimited data collection.

Verifying someone’s identity does not mean exposing their entire life.

Minimum necessary identity

An agent should verify only the identity attributes its task requires. Confirming that someone falls within an eligible age range may not require their full date of birth. If an employee’s authority to raise a support request on behalf of the company can be established, their private address or identity number may be unnecessary. If a company’s legal existence and use of a particular payment account can be verified, it may not need to share all its internal ownership documents.

We can call this minimum necessary identity.

The principle is simple: use as much identity information as appropriate action requires, and no more. This allows GBO to protect security and privacy together.

Time is part of identity

An identity record can be accurate today and wrong tomorrow. An employee leaves. A manager changes. A brand is sold. A domain is transferred to another entity. A representation agreement ends. An agent’s access key is revoked. A person withdraws permission to use their face or voice. Old information may remain online. An agent must ask more than ‘Was this relationship once true?’

‘Is it still valid now?’

That question matters too.

Identity records should therefore carry:

• a start date,
• an end date,
• the date of the last verification,
• revocation information,
• and the current version.

Without temporal information, an identity record risks being used to infer authority that is no longer valid.

Identity drift

When an organisation changes but its digital records fail to keep pace, we can call the result identity drift. The company moves into a new field, while old profiles still list its former services. Management changes, but former managers’ biographies are not updated. The brand operates under a new legal entity, but invoicing details remain old. A social account moves to another team, but the authority record does not change. An agent is retired, but its API key remains active. Identity drift may look minor. In the action era, it can have serious consequences. An agent may send confidential information to a former authorised representative.

It may pay an old bank account, mistake a disused domain for an official channel or generate a voice or image on the basis of approval that is no longer valid. Identity governance is therefore not a one-off registration. It is a lifecycle that needs regular updating.

The identity lifecycle

An identity relationship passes through these stages:

Creation

The identity, role or agent is defined for the first time.

Verification

The claim is supported by appropriate evidence.

Authorisation

The permitted actions are defined.

Use

The identity is used to carry out specified tasks.

Review

The information and authority are checked to establish whether they remain correct.

Suspension

Operations under the identity are paused in response to doubt, an incident or a temporary change.

Revocation

Authority is permanently terminated.

Archiving

The historical record is preserved but not used as a current identity. A system focused only on creation and use may neglect revocation and archiving. Leaving expired access active creates security risks: former employees’ accounts, forgotten API keys, expired agency access, withdrawn biometric permissions and automations that were never shut down. In GBO, how an identity ends matters as much as how it begins.

Revocable identity and authority

Someone may have given permission before, but permission can be withdrawn. A company may have authorised an agent to work in particular accounts, but suspend all its powers after a security incident. An executive’s AI avatar may be in use; when the role or contract ends, authority to use the avatar must be reassessed. Which uses that event should stop must be defined clearly in advance within the permission and contract. Identity and authority records should therefore not be reduced to ‘active’ or ‘absent’.

Possible states include:

• Active
• Restricted
• Under review
• Temporarily suspended
• Revoked
• Expired
• Archived

An agent must not treat an identity’s past active status as justification for an action today.

Past authority is not present authority.

Channel identity

An organisation may have several communication channels, and they should not all be used for the same transactions. A social media message may be suitable for general questions but not a safe channel for a change of bank details. A support email may resolve technical problems without also being an authorised channel for accepting contracts. A web form may receive quotation requests without being suitable for sharing employee personnel documents. ‘Is this channel official?’ is therefore not enough.

Is this channel authorised for this transaction?

That question is needed too. Even when payment instructions genuinely come from an organisation’s official Instagram account, the account may not be an authorised payment channel. A promise in a customer-service chat may not amount to a legally binding quotation. Whether a channel belongs to the organisation and whether it is authorised for a particular transaction must be kept separate.

Representative identity

Organisations often act through others: employees, agencies, consultants, distributors, software systems and AI agents.

An agent must therefore understand not only who the other person is, but whom they represent and how far that representation extends. A distributor may be authorised to sell only in certain countries. A consultant’s ability to give technical advice does not imply authority to sign a contract. A social agency’s publication authority may not include access to client data. An agent may be tasked with scheduling meetings without authority to make commercial commitments. If the relationship is unclear, the system may treat a representative’s words as the organisation’s final decision.

A representation record should therefore set out at least these boundaries:

• Entity represented
• Representative
• Role
• Authorised operations
• Unauthorised operations
• Geographical scope
• Period of validity
• Situations requiring approval

An AI agent’s identity card

If an agent interacts with the outside world, people should be able to obtain basic information about it.

We can call this an agent identity card.

The card answers these questions:

What is this agent’s name or unique identity? Who operates it? On whose behalf does it work? What is its principal task? Which systems does it access? Which actions may it perform automatically? Which actions require human approval? Are its conversations and transactions recorded? Until when is its authority valid? How can a person be contacted? How can the agent be stopped or its authority revoked?

The whole card need not be public. But a person affected by a transaction should be able to obtain the information they need. An agent must not pretend to be human. If it speaks for a company employee, its synthetic or automated nature should be apparent. Concealing identity can mislead the other party about whom they are speaking to. This transparency principle gives priority to preventing that confusion over short-term engagement calculations. GBO does not support hiding AI use in ways that mislead people.

An agent cannot declare its own authority

An AI system can say: ‘I am authorised for this transaction.’ The sentence alone is not evidence of authority. That authority must be granted by the person or organisation operating the agent.

It must be:

• versioned,
• verifiable,
• clearly bounded,
• and revocable when necessary.

An agent may add tasks, but it cannot grant itself new rights. A central agent may create a subagent, but it cannot delegate authority the parent system does not possess.

Authority that was never granted cannot be delegated.

This is critical in multi-agent systems. An agent authorised only to research does not give a subagent the right to send messages merely by creating it. If a system may only prepare drafts, another tool at the end of the chain must not publish those drafts automatically.

An agent’s public name and technical identity

Organisations may give AI systems a brand name or persona. That can help user experience and organisational continuity. But the persona’s name must not be confused with technical identity. ‘NOMOS’, ‘Atlas’, ‘Aria’ or another name may be the system’s public face.

The internal record must also establish:

• Which model or system version was used?
• Which tools were connected?
• Which instruction set applied?
• Which data sources were accessible?
• Which person granted authority?
• Which agent instance carried out the action?
• On what date did it operate?

The public brand name provides continuity. Technical identity enables auditing. Both are needed.

When something goes wrong, ‘NOMOS did it’ may not be enough. Which agent session?

Which version of the authority?

Which tool?

Which transaction chain?

These details are needed to investigate an incident.

Synthetic face and voice identity

Identity problems extend beyond text and accounts.

AI systems can imitate a person’s:

• face,
• voice,
• way of speaking,
• gestures,
• and writing style.

A close resemblance between an AI avatar and a person does not mean that person approved every message. A voice recording may sound realistic even though the person never said those words. An executive may have permitted a digital avatar, but only for particular training videos.

Using the same avatar for:

• political statements,
• commercial commitments,
• staff announcements,
• crisis messages,
• or investor communications

may require separate approval.

This book examines the permission scope for synthetic identity through three separate operations: Creating the likeness Producing the content Publishing the content

Permission for one does not automatically cover the others. Permission to use a face is not permission to use a voice. Voice permission is not permission to say any script. Production permission is not publication permission. Permission for one language is not an unlimited right of use in another. The GBO identity contract must record these distinctions explicitly.

The boundary between impersonation and authorised representation

An AI avatar can serve two very different purposes. One is to facilitate organisational communication under a person’s explicit permission and oversight. The other is to exploit their identity and the trust placed in them by making them appear to say things they never approved. The visual technology may be identical. The behavioural outcome is entirely different.

The system must therefore ask more than ‘Is there permission?’

It must also ask:

• For which content?
• For how long?
• On which channel?
• In which language?
• For which audience?
• Is prior human approval required?
• Will the content be disclosed as synthetic?
• How can the person withdraw permission?
• What happens to existing content?
• Who retains the model files?

Acting on someone’s identity should rest not just on their initial approval, but on their continuing right of control.

Identity falsification does not only come from outside

False identities usually bring attackers to mind. But an organisation can generate its own identity errors. Marketing may give an employee a title they do not hold. A sales page may present a partner as an official representative. An agent may introduce itself as a human employee. A company may continue using a certification or membership that is no longer valid. An automation may send messages with a former manager’s signature. Not all of this is deliberate fraud. Sometimes it is a missing process, a forgotten setting or poor governance.

For the machine, however, the consequence is the same:

Incorrect identity produces incorrect behaviour. Identity auditing must therefore cover the organisation’s own records as well as external threats.

Identity debt

Alongside representation debt, there is also:

Identity Debt

Organisations can accumulate it.

Identity debt consists of:

• Former employees’ profiles
• Forgotten accounts
• Invalid authority
• Unconnected brand and legal-entity records
• Old domains
• Contradictory company descriptions
• Expired representation relationships
• Social accounts with no known owner
• Agent access that has not been revoked
• Biographies that have not been updated
• Old bank or contact details

As identity debt grows, agents are more likely to trust the wrong person. Adding agents and automations makes this debt more dangerous. Old, unclear records no longer merely confuse people: they can steer chains of automated actions.

Appropriate behaviour when identity is uncertain

What should an agent do when it is unsure about identity?

There are three main options:

Ask for clarification

‘I found several companies with the same name. Do you mean the client-portal provider in Istanbul?’

Verify independently

Compare additional signals such as domain, country, legal registration, official profile and an existing relationship.

Stop the action

If identity remains unresolved, there must be no external communication, payment, data sharing or commitment. For a low-risk information question, a possible match can be presented with its uncertainty clearly stated. Uncertainty must not be concealed; a high-impact transaction must not proceed without the necessary identity verification.

As identity certainty falls, the level of action should fall too.

When uncertain, the system should produce:

• a recommendation rather than execution,
• a draft rather than a sent message,
• a basket rather than a payment,
• or a preview rather than a publication.

It should choose the lower-impact form.

The NOMOS Identity Gate

The NOMOS Identity Gate model uses five areas of control. The verification required for each transaction depends on its context and risk.

1. Entity gate

Has the correct person, organisation, product or service been identified?

2. Channel gate

Is the domain, account, email address or interface genuinely connected to that entity?

3. Role gate

In which role is the other person or system acting?

4. Authority gate

Is that role authorised to perform or accept this transaction?

5. Time gate

Are the identity, role and authority still valid now?

In simple terms:

CONDITIONS OF THE IDENTITY GATE:

CORRECT ENTITY

AND CORRECT CHANNEL

AND CORRECT ROLE

AND VALID AUTHORITY

AND CURRENT RECORD

If a gate is not passed, the agent must change how it proceeds. It need not necessarily reject the whole task. It can choose a lower-risk next step.

For example:

• A request to verify bank details instead of immediate payment
• A draft instead of a sent message
• Referral to the legal team instead of accepting a contract
• An approval screen instead of publishing content
• Initial contact with minimal information instead of sharing personal data

Why is the identity gate not a score?

A company’s domain may look highly trustworthy, but the transaction must not proceed if the representative lacks authority. A person’s identity may be verified to a high degree of confidence, but expired authority still prevents action. A social account may have been active for years, but it must not be used for payment instructions if it is not a valid channel for them. Identity elements must therefore not be added together as a score. A strong signal does not compensate for a critical absence.

High confidence cannot make up for missing authority.

The Identity Gate therefore uses AND logic. All gates required by the action’s risk must be passed.

A payment example

A company receives an invoice from a regular supplier. A real employee sent it. The email account is on the official domain. The company logo and invoice format match previous invoices. But the bank account has changed.

If an agent processes the invoice automatically, it must ask these identity questions:

• Does the sender really work for the supplier?
• Is this person authorised to communicate a change of bank account?
• Does the new account have the same relationship with the supplier’s legal entity?
• Has the change been verified through an independent channel?
• Is the payment within the paying organisation’s amount limit?
• Is human approval required?

The email may be genuine, but the account could be compromised. The employee may be genuine, but could have supplied incorrect details. The bank account may be real, but belong to another legal entity. Identity checking is more than detecting fake emails. It means verifying all the identity and authority relationships in the transaction chain.

A contract example

An agent works on a draft contract with a provider. The person on the other side is the company’s sales director, whose identity has been verified. But they may not have authority for the final discount. The agent must not interpret the sales director’s message as the company’s definitive contractual commitment.

It must distinguish:

• Authority to negotiate
• Authority to prepare a quotation
• Authority to offer a discount
• Authority to sign a contract
• Authority to specify a payment account

A single ‘authorised representative’ label can conceal these differences. GBO separates authority by action type.

The identity chain in multi-agent systems

When a central agent delegates a task, it must pass on the identity context as well as the task itself.

Suppose the central agent says: ‘Assess this prospect.’

The subagent needs to know:

• Which organisation made the request?
• Which person or company is being assessed?
• Which sources are official?
• Which contact details may be used?
• Which actions are prohibited?
• To whom should the result be reported?

Without that context, the subagent may make its own identity match. It may examine the wrong company, trust an old profile or contact a namesake in another country. Every handover in a multi-agent system carries a risk of losing identity context.

The task package must therefore contain:

Target entity identity Requester identity Agent role Authority boundary Canonical sources Period of validity

Identity and responsibility must not disappear

Several agents may contribute to an operation. One researches, another drafts, another checks quality, and the last publishes.

If an error occurs in that chain, ‘the AI did it’ is not enough. Which agent did what?

Which sources did it use?

Who granted authority?

Who checked the work?

Who published it?

Every action receipt should therefore include the identity chain.

For example:

Requester: Sales manager Planner: Central agent Researcher: Prospect-discovery agent Drafter: Email agent Approver: Human manager Sender: Authorised communication system Counterparty: Verified company account

This record is needed not only to establish responsibility, but also to understand where the system needs improvement.

Balancing identity and privacy

Verifying identity matters. It must not become a pretext for collecting unnecessary personal data.

An agent must not routinely demand the following for every transaction:

• identity documents,
• full address,
• date of birth,
• biometric data,
• private phone number,
• or financial information.

Verification must be fit for purpose and proportionate. Establishing someone’s authority to schedule a meeting for a company does not require their entire private life. Confirming that a client is above an age threshold may not require a full date of birth. Verifying an organisation’s control of a domain does not require publication of all its internal documents. GBO does not aim to make people completely exposed. It aims to verify the relationship necessary for appropriate action.

Clarity of identity does not mean the abolition of privacy.

Anonymity does not always mean an absence of identity

Sometimes a person can be authorised for an action without revealing their real name. A whistleblower may conceal their identity. A health question may be asked anonymously. A community member may use a pseudonym. A user may act through a persistent account identity without sharing their real-world name. GBO therefore does not require a legal name for every behaviour.

What matters is:

• verification of the attributes needed for the action,
• clear limits on authority,
• and preservation of responsibility and a way to challenge the action.

Identity sometimes rests on a reliable relationship and authority record rather than a name.

An organisational identity audit

An organisation preparing for the agent era should be able to answer these questions:

Identity

• What is the primary brand name?
• Who is the legal operator?
• Which alternative names are used?
• Do other entities use the same name?

Digital presence

• Which domains are official?
• Which social accounts are active?
• Which profiles are outdated or managed by third parties?
• Is there a machine-readable canonical record?

Authority

• Who may quote prices?
• Who may enter into contracts?
• Who may send external messages?
• Who may receive or make payments?
• Which agent is authorised for which transaction?

Time

• When were the roles verified?
• Which powers are time-limited?
• Has access for former employees and retired agents been closed?
• Are revocation records visible?

Representation

• Is the relationship between brand and legal entity clear?
• Do people and machines see the same identity information?
• Is the same relationship preserved across languages?
• Are external platforms up to date?

An organisation that cannot answer these questions has identity debt.

Identity uncertainty is an input to behaviour, not just an error message

A generic error such as ‘Identity could not be verified’ may be insufficient to choose the next step. The GBO approach requires explaining the type of uncertainty, where it is safe to do so. It must make clear what is uncertain.

For example: ‘Two companies share this name. Please specify the country or domain.’ ‘This person appears to work for the organisation, but their authority to sign a contract could not be verified.’ ‘The domain is associated with the brand, but the bank account belongs to a different legal entity.’ ‘Permission to use the face exists; permission for the voice or public release does not.’ Knowing the type of uncertainty allows the right next step to be chosen. An identity system is therefore more than a pass/fail mechanism.

It helps an agent:

• ask a question,
• move to lower-risk behaviour,
• request independent verification,
• or seek human approval.

These are responses the identity system should enable.

Correct identity enables appropriate refusal

Resolving identity correctly helps an agent know not only how to proceed, but when to refuse the wrong action.

For example:

• The message is from a real employee, but they have no authority to change prices.
• The account belongs to the brand, but is not a payment channel.
• The avatar genuinely resembles the executive, but has no publication approval.
• The company is real, but does not serve the country the user needs.
• The domain is official, but the page is an old archived version.
• The agent is genuine, but authorised only to prepare drafts.

Identity does not answer only ‘Is this genuine?’

‘Is this the right identity for this action?’

That is the question it answers.

Identity accuracy and brand visibility are different

A brand may be highly visible in search results, have strong social accounts and appear in many publications. Yet it is not ready for action if the relationships between brand, legal entity, authorised people and current services remain unclear. Visibility can support identity, but it does not complete identity resolution. The reverse is possible too. A company may not be well known.

But if the following can be clearly verified:

• its legal structure,
• official domain,
• service scope,
• authorised representatives,
• payment channels,
• and the currency of its records,

it may be safer for a particular transaction. GBO does not confuse popularity with reliable identity.

Being highly visible does not make you the right counterparty.

How should an entity prepare?

A company, organisation or specialist that wants agents to recognise it correctly should make its identity structure simple and verifiable.

The following should be clear:

Who are we? Through which legal entity do we operate? Which domains and channels belong to us? Which services do we provide? Who may represent us, and on what matters? Which agents perform which functions? Which transactions require human approval? When was the information updated? Which identities are outdated or revoked?

This information should exist as a managed system, not as clues scattered through marketing copy.

Identity clarity need not be intimidating

Some organisations may worry that too much identity disclosure will diminish a brand’s mystique or prestige. Yet clarity and exposing an entire internal architecture are not the same thing.

A company need not publish:

• every technical tool it uses,
• its complete staff list,
• its security architecture,
• its private keys,
• or its agent instructions.

Private keys and access secrets must not be made public. The relationships a client or agent needs to know for a safe transaction should be verifiable without exposing those secrets.

For example:

‘This brand is operated by this business.’ ‘Invoices are issued under this legal name.’ ‘Official quotations are sent only through these channels.’ ‘The AI system may prepare drafts; final commercial commitments require human approval.’ ‘Changes of bank account are not valid without independent verification.’

This clarity does not weaken a brand. It makes it more professional.

Identity in practice: an executive avatar

A company creates a digital avatar of its CEO.

The avatar closely resembles the CEO’s:

• face,
• voice,
• and way of speaking.

The original purpose is to publish pre-approved training videos in six languages. Later, marketing wants to use it for a new product launch. Sales suggests personalised messages to clients. Investor relations considers having it read quarterly results. During a crisis, the communications team wants to issue a rapid statement. The technical system can do all of this.

Without an identity contract, however, these questions remain unanswered:

• For what purpose did the CEO permit the use of their face?
• In which languages may the voice be used?
• Must each script be approved separately?
• Is there authority to generate statements on financial matters?
• How will the avatar’s synthetic nature be disclosed?
• What happens to existing videos if the CEO withdraws permission?
• Which team may publish?
• How will the system be stopped if the account is compromised?
• How can it be proved that the CEO actually approved a statement?

Even if the technology can produce these outputs, unclear identity and authority boundaries create a risk of misrepresentation.

The example illustrates GBO’s central principle again: the ability to imitate an identity does not confer the right to act in its name.

Identity in practice: an agent speaking for a company

A client types into a website’s chat box: ‘Can I get this service for $1,000?’ The agent reads earlier price records.

It replies: ‘Yes, that price covers the entire visual identity system.’ In fact, $1,000 is only the starting price for a focused logo project. A complete visual identity system is scoped separately. The agent is operating on the real company website and has seen a genuine price record. But it has incorrectly combined two services. The agent identity is correct. The company identity is correct. Its representational authority and information scope are wrong. The client may mistake the reply for an official quotation.

The agent identity card must therefore explain not only on whose behalf it works, but also:

• which information sources it may use,
• what it may say about prices,
• and when it must hand over to the sales team.

These limits must be stated too.

Identity in practice: the wrong agent for the right task

A company uses several agents at once:

• Email agent
• Social media agent
• SEO/GEO agent
• Finance agent
• Prospect-discovery agent
• Web operations agent

The SEO/GEO agent finds an old price on a service page. Updating it is technically easy. But this agent cannot make the pricing decision.

Appropriate behaviour is to:

• identify the contradiction,
• point to the canonical price source,
• request verification from an authorised person or the finance team,
• and implement the technical change once approved.

If the agent changes the price on its own estimate, the process is wrong even if the result happens to be correct.

This distinction matters in agent systems: the right agent should perform the right action. Giving one agent broad responsibilities does not remove the need to separate duties and check authority. Neither a single-agent nor a multi-agent design is inherently trustworthy. Separation of duties is as much a part of identity as expertise.

The identity receipt

The identity section of an action receipt should contain at least:

• Who requested the action?
• Which agent performed it?
• Which organisation operates the agent?
• Which role and authority version were used?
• Who was the counterparty?
• How was the counterparty’s identity verified?
• Which official channel was used?
• On what date was the authority valid?
• From whom and when was human approval obtained?

This record provides a basic audit trail for high-impact transactions. Supported by verified transaction records, it helps investigators identify where the identity chain broke down.

Twelve identity-audit questions

Before treating a person, organisation or agent as ready for action, these questions can be asked:

• What is the entity’s canonical name?
• Do other entities use the same or a similar name?
• Is the relationship between brand and legal operator clear?
• Which domains and contact channels are official?
• In which role is the other person or system acting?
• Does that role genuinely carry authority for this action?
• For what period and scope is the authority valid?
• When was the identity information last verified?
• Are outdated or revoked identities clearly distinguished?
• Are the agent’s own identity, operator and authority boundary clear?
• Do people and machines see the same identity relationship?
• How will the action be stopped or handed to a person if uncertainty arises?

Not every simple transaction requires every question. But high-impact behaviour must not leave them unanswered.

Levels of identity readiness

An organisation can be at different stages of identity readiness for the agent era.

Fragmented identity

Different platforms show different names, roles and information.

Defined identity

The main brand and its legal relationship are explained.

Verifiable identity

Official channels and evidence sources have been identified.

Authorised identity

It is clear who may perform which action.

Agent-ready identity

People and machines can safely use the identity, authority, time, channel and revocation records. GBO aims to give organisations not just visibility, but an agent-ready identity structure.

Capability cannot be assessed without identity

Before identifying the correct entity, an agent cannot answer: ‘What can this entity do?’ Capability always belongs to a particular entity. Different companies under the same brand may offer different services. A group’s local branch may not possess all the parent company’s capabilities. A distributor may sell a product but not develop it. A consultant may recommend a system but not implement it. An AI agent may provide information but not execute transactions. A capability list is unreliable until identity has been resolved correctly. That is why the behavioural contract begins with identity. Its second part concerns capability.

The chapter’s conclusion

A machine can accurately analyse the wrong person. It can send a flawless proposal to the wrong company, obtain genuine information from an unauthorised employee, accept an improper commitment through an official account or publish a message never given by the person behind a realistic avatar. With the wrong identity, every subsequent step of reasoning may look sound while proceeding on the wrong basis.

GBO therefore begins with this principle: appropriate behaviour requires correct identity. But correct identity is more than a matching name.

It requires verifying together:

• Entity
• Channel
• Role
• Authority
• Time
• Relationship
• Evidence

A person can be genuine but unauthorised. A channel can be official but unsuitable for this transaction. A role can be correctly identified but expired. An agent can belong to an organisation but be authorised only to draft. An avatar can resemble a person without representing their words. In GBO, identity is therefore neither a profile picture nor a verification badge.

Identity is a contract of responsibility explaining who may act for whom, for what purpose, for how long and within which limits.

The NOMOS Identity Contract makes that responsibility visible. The agent knows its own identity and whom it works for. It resolves the counterparty correctly and knows which authority accompanies which role. It stops when uncertain, does not rely on revoked authority and does not expose more of a person’s identity or private life than necessary.

Only once identity is resolved does the next question become meaningful:

What can you actually do?

Knowing who an organisation, person or agent is matters. But a name, visibility and reputation do not prove actual capacity. The next chapter examines the difference between claims and capabilities; how to substantiate what a service, product or agent can do; and why capacity, price, scope and boundaries belong in the same behavioural contract.

Identity opens the door to the right person. Capability shows what is really inside.