Knowing who you are speaking to: identity and verification in autonomous customer operations
For most of the history of customer service, identity was a quiet formality. A human agent asked for an order number, recognised a familiar voice, or simply trusted the email address a message arrived from. The judgement happened in a person’s head, and the consequences of getting it wrong were usually small and slow to surface.
Autonomous agents change that calculation completely. An agent that can read your order book, adjust a delivery, issue a credit, or retrieve a customer’s account history is no longer answering questions. It is acting inside the systems that run your business. The moment a conversation can reach real data and real actions, the question of who is on the other end stops being a courtesy and becomes the single most important control in the entire operation.
This is the part of agentic customer operations that very few providers have solved properly. Connecting an agent to business systems is now well understood. Making sure the agent only ever reveals what the person in front of it is genuinely entitled to, that it can prove the person is who they claim to be, and that sensitive customer data never leaks out through the conversation itself, is a much harder problem. It is the problem oHallo was designed around from the beginning.
The three risks that matter
It helps to name the risks plainly, because they are distinct and each requires a different answer.
The first is impersonation. Someone contacts you claiming to be your customer, or claiming to act on their behalf, and asks for information or an action that should only be available to the real account holder. In a B2B setting this is rarely a clumsy fraudster. It is more often a former employee of a customer, a competitor probing for commercial terms, or a well-intentioned third party who simply is not authorised to receive what they are asking for.
The second is disclosure beyond entitlement. Even when the person is exactly who they say they are, they may not be entitled to everything the underlying systems could return. A contact at a customer might be allowed to check the status of their own orders but not the pricing on another division’s contract. An agent that retrieves a record and reads it back in full, without regard for what the requester is permitted to see, leaks data just as surely as one that was deceived.
The third risk is specific to working with language models, and it is the one that keeps security teams awake. When an agent reasons over a conversation, sensitive data has to be handled somewhere. If account numbers, personal details, and internal identifiers flow freely into the model’s working context, they become part of a system that is probabilistic by nature and difficult to fully constrain through instructions alone. Telling a model to “never reveal field X” is a request, not a guarantee. A determined prompt, an unusual phrasing, or an unforeseen edge case can talk a model into saying more than it should.
These three risks are why identity in an agentic system cannot be a login screen bolted onto the front. It has to be woven into how every action is decided.
What assurance actually means
The foundation of oHallo’s approach is that identity is not a single yes-or-no flag. It is a level of assurance that rises as a conversation earns it, and every sensitive action is gated against a minimum level it requires.
There are three levels, and they mean the same thing on every channel.
Unlocks: The most sensitive data and actions
Unlocks: What that customer is entitled to
Unlocks: Only what is safe for anyone
This structure is not invented. It follows the international reference framework for digital identity, NIST Special Publication 800-63, which separates how confident you are that a real person matches a claimed identity from how confident you are that the right person is present in this particular session. The factor categories follow the long-established vocabulary used in European payment regulation: knowledge (something the person knows), possession (something the person has), and inherence (something the person is). Reaching the highest level requires two factors from two different categories, because two passwords are still only one kind of proof, and an attacker who defeats one kind has often defeated all of that kind at once.
The important design decision is that these levels are channel-agnostic. A customer who reaches the identified level by email has reached the same level, with the same meaning, as one who reaches it by voice or through a chat widget. What differs between channels is only the mechanism used to establish a factor, never the standard the factor has to meet.
How a customer is asked to identify
When a conversation needs more assurance than it currently holds, the agent conducts a verification exchange in natural language, on whatever channel the customer is already using. There is no separate portal to log into and no disruptive hand-off.
On email, the agent can reply with a single-use link sent to the address on file, which the customer opens on their own device, establishing a possession factor. On a voice call, the same link can be sent to the email of record while the call continues, or the agent can ask knowledge-based questions whose answers come from authoritative records in your own systems. In a chat widget, the customer can establish the same factors by typing answers or opening a link in their inbox.
The knowledge-based questions deserve a note, because this is where impersonation is defeated in practice. The questions are not “what is your favourite colour.” They are drawn from records that only the genuine customer would reasonably know, and the standard the design follows requires several to be answered correctly, with a strict cap on how many attempts a single identity is allowed before the channel is locked. This is the same discipline that the NIST identity-proofing guidance prescribes, applied to a conversation rather than a form.
One detail matters more than any other here, and it is the difference between a system that is trustworthy and one that merely appears to be. The agent conducts the verification, but it does not decide whether verification passed. The agent relays the customer’s answer; a separate, deterministic grader checks it against the authoritative record and rules on it. The component that talks to the customer is never the component that judges the customer. A model cannot be persuaded to mark itself correct, because it was never holding the answer key.
The control that cannot be talked past
Establishing assurance is only half of the answer. The other half is making sure assurance is actually enforced on every action, every time, in a way that no conversation can argue its way around.
Inside oHallo, every action an agent takes in a business system passes through a single enforcement point before it executes. This point sits in front of every connected system, and it evaluates each call against a fixed set of checks. It is entirely deterministic. It runs no language model, makes no judgement call, and cannot be influenced by how a request is phrased. It either permits an action or it does not, and the same inputs always produce the same outcome.
The checks run in a strict order, and the first one is absolute: an agent acting for one customer can never reach another customer’s systems. That boundary is the very first thing evaluated and nothing later in the sequence can override it. After that, each action is measured against the assurance level it requires. A request to read public opening hours requires nothing. A request to retrieve an account’s order history requires the customer to be identified. A request to change a payment instruction or release a high-value order can be set to require the highest level. If the conversation has not earned the level an action demands, the action is refused before it ever runs, and the refusal itself is what prompts the agent to begin a verification exchange.
The enforcement point can return one of four outcomes, and together they cover the full range of what a careful operation needs.
It can allow an action to proceed. It can deny it outright, in which case no connection to your system is even opened. It can require human approval, pausing the action and surfacing it to a member of your team with the full context before anything happens, which is how a large or unusual order can be held for a person to confirm. And it can mask a result, letting an action proceed but redacting sensitive fields from what comes back before the agent ever sees them.
an action
system
This is not an abstract setting. For each action a connected system exposes, an operator chooses the risk it carries and the minimum assurance a conversation must reach before it can be taken, and the lower bound for a sensitive action cannot be set beneath its floor.
Because this enforcement is deterministic and sits below the agent rather than inside it, it is the layer that cannot be bypassed by clever wording. Instructions to a model are guidance. This is a gate.
Keeping sensitive data out of the model
Masking is worth dwelling on, because it is the direct answer to the third risk, the one specific to working with language models.
When a connected system returns a record, sensitive fields can be redacted at the enforcement point before the result is handed to the agent. The agent receives the order status it needs to answer the question, while the customer’s full personal details, internal account identifiers, or anything else marked sensitive are replaced with a placeholder. The agent cannot reveal what it never received. As a safety net beneath the fields you configure explicitly, the same layer scans results for recognisable patterns such as email addresses, phone numbers, and long digit sequences, and redacts those too. The complete, unredacted result is retained internally for your own audit and compliance purposes, but it never enters the part of the system that composes the reply.
at the gate
These rules are configured rather than coded. A field can be set to mask on a given action, and an action can be set to pause for human approval when a condition is met, such as a refund above a chosen value.
Two further design choices close the remaining gaps. Every verification factor is bound to a specific customer, which means a factor established for one person can never unlock another person’s data; the enforcement point checks that the factor in hand belongs to the account being accessed. And the credentials that authenticate to your business systems are never placed in the agent’s reasoning context at all. They are resolved at the moment of the call, used to make the connection, and never exposed to the model. The agent can ask a system to do something; it can never read the keys to that system.
The combined effect is that the model operates inside a structure that decides for it what it may reach and what it may say, rather than being trusted to police itself. That is the elegant part. The intelligence sits inside a boundary it does not control.
Where the law sits in all of this
Identity and verification are not only a security concern. They are a legal one, and the design treats the relevant law as a floor that cannot be configured away.
Under the General Data Protection Regulation, a data controller is expected to take reasonable measures to verify the identity of a person exercising their rights, and to make that verification proportionate to what is being requested. A request for a sensitive record should face a higher bar than a general enquiry. The assurance model maps directly onto this expectation: the more sensitive the action, the higher the assurance it requires, and the verification exchange is precisely the lawful channel through which a controller seeks the additional information the regulation permits it to request when there is reasonable doubt about identity. The principle of integrity and confidentiality that runs through the regulation is, in practical terms, what the enforcement point exists to uphold.
The same regulation grants individuals the right to have their data erased. oHallo records the identity-related events of a conversation in a dedicated, append-only ledger so that there is an honest account of how each verification decision was reached, and that ledger is governed by a retention period you set and an erasure path that permanently removes an individual’s records on request, leaving behind only a meta-record that the erasure took place. Data is processed within the European Union, in Frankfurt, and a data processing agreement compliant with the regulation’s processor obligations is available to every customer.
The European Union’s Artificial Intelligence Act adds a further dimension. It requires that people are told when they are interacting with an automated system, and it expects providers of such systems to keep records that make their operation traceable. The identity ledger, together with the broader record of which knowledge and which policies shaped every reply, is built to serve exactly that purpose. Transparency here is not a disclaimer in the footer. It is the ability to reconstruct, for any interaction, who was verified, how, and what they were consequently permitted to reach.
It is worth being precise about what is claimed and what is not. The design follows the NIST framework for assurance levels and identity proofing, and it borrows the factor-category vocabulary from European payment regulation because it is widely understood and well grounded. Where a particular mechanism aligns with a standard’s principles without meeting its strictest letter, that is stated plainly rather than dressed up. Honest conformance is itself a feature, because the alternative is a posture that collapses under audit.
You set the bar, and you can see where it sits
No two businesses carry the same risk. A request that one organisation is comfortable answering for any identified contact is one that another will hold to the highest level of assurance. oHallo treats the assurance required for each action as something you configure, not something imposed on you.
For every connected action, you choose the minimum level a conversation must reach before it can be taken. You decide which results have sensitive fields masked. You decide which actions pause for a person to approve. And as you make those choices, a live compliance indication reflects the posture you have actually configured, in plain language, so there is never a gap between what you believe your settings achieve and what they do. Where you choose to set a bar below the design’s default, that choice is shown rather than hidden.
The one thing you cannot configure away is the legal floor, because that is not a setting; it is the law.
Why this is a commercial decision, not a technical footnote
It is tempting to file identity and verification under engineering detail and move on to the features that demonstrate more obviously in a sales conversation. That would be a mistake, and the leaders who are furthest ahead in this market already understand why.
An autonomous agent is only as valuable as the work you are willing to let it do without supervision. The depth of action you can safely delegate is governed entirely by how confident you are that it will never reveal what it should not, never act for someone it should not, and never let sensitive data escape through the conversation. Weak identity caps the value of everything else, because it forces you to keep a human in the loop for anything that touches real data. Strong identity is what lets you push the boundary outward with confidence, and that boundary is where the return on an autonomous operation is actually found.
It is also, increasingly, what your own customers and your own auditors will ask about first. A procurement team evaluating an agentic provider will want to know how a stranger is prevented from retrieving an account, how sensitive data is kept out of the model, and how a verification decision can be reconstructed months later. Being able to answer those questions with a clear, standards-grounded account rather than a reassuring sentence is a commercial advantage in its own right.
oHallo was built so that the answer to every one of those questions is structural. Identity is not a screen in front of the agent. It is the spine that decides, on every action, what the conversation in front of it is allowed to reach.
Related
Embed oHallo on your website
Three embeddable widgets that let your website visitors find answers, submit requests, and book meetings without sending an email.
31 Mar 2026Why B2B customer operations need autonomy, not automation
Automation replaces steps. Autonomy replaces the need for steps. The difference matters more than most companies realise.