Trust tiers control how much authority THEO has to act on behalf of a person making a request. The higher the tier, the more THEO can do without routing to a human for approval. This article explains each tier, how THEO assigns them, and how identity verification works.
The Four Trust Tiers
Guest
Guest applies to unauthenticated or unverified callers — someone who contacts THEO through a public channel before logging in, or a caller whose identity cannot be confirmed.
At the Guest tier, THEO is heavily restricted. It can answer general questions, collect information for a request, and escalate to a technician, but it will not take any action that touches live systems or data.
User
User applies to authenticated HCP (client portal) users — people who have logged into the client portal with a verified account. At this tier, THEO can:
- Answer questions about the user's own IT environment
- Submit requests on the user's behalf
- Show status on the user's own tickets
THEO enforces contact scope at this tier: a User can only see and act on data tied to their own contact record. They cannot see other contacts at their organization or data from other clients.
Elevated
Elevated applies to MSP staff — technicians, members, and viewers — who are authenticated with a valid platform session.
At this tier, THEO can use domain tools (PSA, RMM, security, GitHub, web) according to the person's role:
- Viewer — read-only access; can search and retrieve but cannot create, update, or send
- Member — read and write; can create tickets, add notes, and send client messages
- Admin — full access to tools and settings for their org
Admin
Admin applies to org admins and platform owners. At this tier, THEO has broadest access — including settings changes, sensitive tools, and org-level operations.
Platform owners (The One Stack's own org accounts) bypass billing and entitlement gates entirely.
How THEO Verifies Identity
Session-Based Verification
For most MSP staff interactions, trust is established by the authenticated platform session. If you are logged in to the portal or desktop app with a valid session, THEO reads your role from the session token and assigns the corresponding tier.
Identity Challenges
For actions that require higher assurance — particularly in end-user self-service flows — THEO can issue a challenge to verify identity before proceeding. Four challenge methods are available:
| Method | How it works |
|---|---|
| PIN | User enters a numeric PIN they previously set via THEO → Trust → Set PIN |
| Push notification | A confirmation is sent to the user's registered mobile device; user taps to approve |
| Magic link | A one-time link is emailed to the user's verified address; user clicks to confirm |
| WebAuthn | Hardware security key or biometric authenticator registered to the user's account |
If the user passes the challenge, THEO proceeds with the elevated trust context for that session. If the challenge fails or times out, THEO routes the request to a human technician.
How This Affects Runbook Execution
Each runbook action has an associated minimum trust level. Actions that are low-risk (such as checking a device's status) can run at the User tier. Actions that are higher-risk (such as resetting an admin password or making a firewall change) require Elevated or Admin trust.
When THEO's current trust level for the caller is below the threshold for an action, it either:
- Issues a challenge to raise the trust level, or
- Routes the request to the approval queue with a note explaining what was needed
Changing Trust Settings
Trust challenge methods are configured per user:
- Set a PIN — THEO → Trust → Set PIN
- Register a WebAuthn key — THEO → Trust → Register Security Key
- Push tokens — registered automatically when the mobile app is installed
Administrators can review and manage trust settings for their org under THEO → Settings.
FAQ
Can an end user upgrade their own trust tier?
An end user can raise their trust level within a session by completing an identity challenge. They cannot permanently change their tier — that is determined by their role in the platform.
What happens if a push notification is not answered?
The challenge times out. THEO treats the unresolved challenge as a failure and routes the request to a human technician rather than proceeding.
Can I require a specific verification method for a particular client?
Trust challenge configuration is currently per-user, not per-client. Contact your platform administrator for org-level trust settings.