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
Section titled “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
Section titled “identified”The caller has presented one verification factor, so oHallo links them to a specific contact. That factor is one of three things: a correct answer to a security question drawn from the caller’s own record (called knowledge-based verification, or KBV), control of an email address held on the caller’s record (proven by opening a one-time link), or a recognised channel signal such as a caller ID or a sender address that matches the record.
A recognised caller ID or sender address is a supporting signal. On its own it reaches identified, and it stays there: because a phone number or an email header can be spoofed, oHallo treats it as corroboration rather than one of the two factors that compose the highest level. Reaching high-assurance always calls for a genuine verification factor.
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
Section titled “high-assurance”The caller has satisfied two verification factors from different categories, following the strong-customer-authentication principle in PSD2 SCA Article 4, or has completed a National eID approval. On the two-factor path this means a knowledge factor (a KBV answer) together with a possession factor (opening the one-time email link): each reaches identified on its own, and together they reach high-assurance. A completed National eID approval reaches high-assurance on its own, the one method that does. The identity is government-issued and proven by the scheme itself, where questions and the email link prove control of a record’s details and reach identified alone. This is oHallo’s strongest assurance.
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
Section titled “Setting tool assurance”You set the per-tool assurance level in MCP hub, then your connection. The list starts at the floor for that tool’s risk classification, so you can raise the requirement and the floor holds underneath it. Hover the control to see the floor.
A tool with no risk classification is declined on every call, so classify each one before you rely on it.
If you change a tool’s risk classification (in the Risk column of the same table), the floor for the assurance column changes too. Setting a tool to read (PII) raises its floor from anonymous to identified.