Skip to content

Assurance levels

The platform recognises three discrete assurance levels for a caller. Every tool the AI can run is gated against one of them. Understanding the levels helps you set per-tool policy that matches your business risk appetite.

The caller has not been linked to a specific contact. The platform knows what channel they came in on (a phone number, an email address, a chat session) but has not verified that the person on the other end is the genuine account holder.

What this level unlocks — public information that isn’t tied to a specific customer: business hours, location, return policy, public product information, FAQs. 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?” — anonymous is not enough; the tool that returns order status requires identified.

The caller has successfully exchanged a verification factor with the platform. They have answered KBV (Knowledge-Based Verification) questions correctly, or they have proven possession of an email account on file by clicking a one-time magic-link, or both. The platform now considers them linked to a specific contact.

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 to add a credit to their account — destructive change; high-assurance is required.

The caller has satisfied two verification factors of different categories per PSD2 SCA Article 4. For most callers this means one knowledge factor (KBV) plus one possession factor (the magic-link). This is the platform’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.

You set the per-tool assurance level in Settings — MCP Hub — (your connection). The dropdown shows the platform floor — the minimum the platform will allow for a given risk classification. You can raise the level above the floor (require high-assurance for a tool the platform would gate at identified) but never lower 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 (returns personal data)” raises its floor from anonymous to identified.