Assurance levels

oHallo recognises three fixed assurance levels for a caller. These three levels are the same across every workspace. Every tool the assistant can run is gated against one of them. Understanding the levels helps you set per-tool policy that matches your business risk appetite.

anonymous

At this level the caller is a visitor whose identity is still open. oHallo knows the channel they arrived on, a phone number, an email address, or a chat session, and waits for a verification factor before it links them to a specific contact.

What this level unlocks: public information that applies to any caller: business hours, location, return policy, public product information, common questions. Anything you would show on a website without a login.

Examples by use case

A caller asks “When do you open?”: anonymous is enough.
A caller asks “Is the blue model in stock?”: anonymous is enough.
A caller asks “What’s my order status?”: the tool that returns order status requires identified, so the caller verifies first.

identified

The caller has presented one verification factor, so oHallo links them to a specific contact. That factor is one of these: control of an email address held on the caller’s record (proven by pressing Confirm it’s me on the page a one-time link opens), a call from the number on file or a message from the address on file, on a channel whose Caller ID or Email sender address is set to Identifies the customer, or a completed National eID verification.

Caller ID and the Email sender address count only on a channel where they are set to Identifies the customer. There they reach identified, and they stay there: because a calling number can be faked and a sender address forged, oHallo treats them as corroboration and never as a step toward the highest level. The email sender address identifies the customer on email channels set up to receive mail directly.

What this level unlocks: the caller’s own account data: order history, balance, scheduled deliveries, profile fields. State-changing operations that affect only the caller’s account: changing a delivery address, scheduling a callback, opening a support case.

Examples by use case

A caller asks “When is my order arriving?”: identified is required.
A caller wants to reschedule a delivery: identified is required.
A caller wants a refund on their account: your team classifies that tool as destructive, so high-assurance is required.

high-assurance

The caller has completed a National eID verification, the one method that reaches high-assurance. The identity is government-issued and proven by the scheme itself, where the email link proves control of a mailbox the record names and reaches identified. No combination of the other methods reaches high-assurance. This is oHallo’s strongest assurance.

A National eID verification counts as high-assurance by default. Under Settings, then Verification, the National eID tab’s A verification counts as can set it to identified for the whole workspace. Then no channel reaches high-assurance and every tool that needs it goes to your team. National eID then ties no customer to their own records, so a tool declared A customer’s company stays closed, and a tool declared A customer that reads and is set to identified opens through the methods that tie the customer to their record, described under Customer data below. The Levels table on the Posture tab and the Reachable by column on each MCP hub connection page follow the setting once it is saved.

What this level unlocks: destructive or financially material actions: cancelling a subscription, requesting a refund, resetting a password, deleting an account, changing financial details (IBAN, credit card on file).

Examples by use case

A caller wants a refund on an order: high-assurance is required.
A caller wants to cancel their subscription: high-assurance is required.
A caller wants to remove their saved payment method: high-assurance is required.

Setting tool assurance

You set the per-tool assurance level in MCP hub, then your connection. Each risk classification carries a default: anonymous for read, identified for read (PII), write and write (PII), and high-assurance for destructive. The Assurance list offers all three levels, and two on a tool set to A customer (below). Hover the control to see the default for that tool.

A level at or above the default applies when you choose it. A level below the default opens a confirmation panel that states the change and what it lets a caller do, and the setting applies when you acknowledge it. The row then shows Below default. Two bounds hold whatever you choose: a destructive tool is never anonymous, and a tool set to anonymous below its default needs a declared scope under Settings → Customer records first. A setting below the default is made on the dashboard; the API raises a tool’s level and never lowers it.

A tool set to A customer under Settings → Customer records offers two levels in the Assurance list, identified and high-assurance, since a customer’s own records always need a verified customer. A tool set to A customer’s company shows high-assurance in the Assurance column, with no list: only National eID at high-assurance opens it, whatever level is stored. The stored level returns if you set the tool to another choice.

A tool with no risk classification is declined on every call, so classify each one before you rely on it. A tool with no declaration under Settings → Customer records is declined the same way.

If you change a tool’s risk classification (in the Risk column of the same table), the default for the assurance column changes too. Setting a tool to read (PII) moves its default from anonymous to identified. A reclassification that lowers the level the tool is enforced at opens the same confirmation panel, and so does one that has a call to the tool ask a customer to approve less: a read where it asked for a change, or a change where it asked for something that cannot be undone. A tool set to General information, for anyone under Settings → Customer records keeps the read classification; to classify it otherwise, choose what it returns there first.

How the settings fit together

Three settings decide whether a caller can use a tool, each in one place, and one column shows the result:

Risk gives each tool its default level. You raise or lower the level per tool in MCP hub, on the connection page, as described above. See Guardrails for the risk classes.
Customer data says whose data the tool returns. You set it up for the connection under Settings → Customer records, in Customer data (see Finding your customers). The assistant calls a tool once it is set up there; until then its Customer data cell on the connection page reads Not set up, the header counts it as blocked, and its level cannot be set. On a tool set to What this conversation created, a caller reaches only what their own conversation created. On a tool set to A customer, a caller reaches only their own data once oHallo has matched them to it: by National eID, and on a tool that reads and is set to identified, also by the Email link on live chat and on email channels set up to receive mail directly, where the channel offers it; by the Email sender address on those email channels, and by Caller ID on a voice channel, where the channel sets it to Identifies the customer. A change on such a tool, and a tool set to high-assurance, needs National eID. On a tool set to A customer’s company, a caller reaches only their company’s data once they have verified with National eID, whatever level the tool is set to. By default one National eID approval covers that information in the conversation for as long as it counts, for reading and for changes, and the approval request says so; a company that chooses Reading, with each change approved on its own on the National eID tab has each change approved on its own (see Verifying with a national eID).
Settings → Verification decides which methods reach each level on each channel: an email link, Caller ID or the Email sender address where the channel sets it to Identifies the customer, or National eID. See Setting up identity verification.
The Reachable by column on the connection page brings them together. It lists the methods that reach each tool’s level on your channels, and reads Needs a method when no channel reaches it. The Posture tab shows the same picture per level (see Understanding compliance posture).