Identity Scoping & Safety
When QueAssist connects to Google Workspace, Microsoft Entra ID, or a custom server, it can look up accounts and — if you explicitly allow it — take actions like resetting a password or adding someone to a group. Identity scoping is the rule that keeps those actions tied to the right person, not to whoever an employee happens to mention in chat.
This guide explains how that works in plain terms: what QueAssist can and cannot do in portal chat vs on tickets, how raise on behalf fits in, what the audit log means, and how to configure custom integrations safely.
For connecting providers and turning individual tools on, start with Connecting Integrations & Custom MCP Servers. For the emergency stop and master AI switches, see QueAssist Settings & Usage Quota.
1. Why identity scoping exists
Employees describe problems in natural language. Without guardrails, an AI might interpret "reset Sarah's password" as permission to change Sarah's account — even when the person chatting is not Sarah, and even when Sarah never opened a ticket.
QueueDesk prevents that by binding every identity-targeted action to a verified identity the system already knows from the signed-in session or the ticket record — never from free-text conversation alone.
2. The three places QueAssist can call integrations
| Where | Who QueAssist acts for | Typical example |
|---|---|---|
| Portal chat | The signed-in employee only | Employee asks "Am I locked out?" — QueAssist can check their account, not a colleague's. |
| Ticket resolution & playbooks | The ticket's subject (see section 3) | Agent opens a ticket on behalf of a locked-out user — QueAssist can reset that user's password if write tools are enabled. |
| External AI apps (AI Agent Access) | The person who connected the app, within their QueueDesk role | An agent's Claude connector can search tickets they already have access to — it never gets broader permissions than that person. |
These are separate paths. Rules that apply in portal chat do not always apply on tickets — and vice versa.
3. How the ticket subject is determined
On tickets (agentic resolution, playbooks, and automated emails), QueAssist resolves one email address as the subject. It uses the first match in this order:
1. Raise on behalf of — when an agent or admin created the ticket for someone else and entered that person's email.
2. Affected user — the person the ticket is about, when set on the ticket.
3. Requester — whoever submitted the ticket (portal, agent UI, or chat).
4. Inbound email sender — for tickets created from forwarded email, the From address on the first message.
That email is the only identity QueAssist may target for write actions on that ticket. Resolution emails and confirmation links also go to this person when an address is available.
4. Portal chat vs tickets — what gets blocked
Portal chat (self only)
In the floating QueAssist bubble on the employee portal, every identity-targeted action is scoped to the person signed in.
- •✅ "Check if my account is locked" — allowed (their account).
- •✅ "Reset my password" — allowed if you have enabled the reset-password write tool in Integrations.
- •❌ "Reset my manager's password" — refused. QueAssist may explain that it can only help with the signed-in user's account. If a write tool is attempted anyway, it is logged as Blocked in the audit log.
Portal chat never uses raise-on-behalf — there is no ticket subject yet.
Tickets and playbooks (subject of the ticket)
When agentic resolution or a playbook runs on a ticket, identity-targeted actions use the ticket subject from section 3 — not the agent who opened the ticket.
- •✅ Agent raises INC-1042 on behalf of
alex@company.comfor a lockout — QueAssist may reset Alex's password if the write tool is enabled. This is intentional: helpdesk workflows often require acting on the person who cannot sign in themselves.
- •❌ Same ticket, but subject resolves to the agent because Raise on behalf of was left blank — a reset would target the wrong person. Always enter the affected employee's email.
When you see Blocked in the audit log
Blocked means QueueDesk refused the action before it reached your directory — for example:
- •Portal chat tried to target someone other than the signed-in employee.
- •A write tool targeted an email that did not match the verified ticket subject.
- •The user's email domain did not match your configured Google Workspace domain or Entra primary domain (see section 6).
- •The tool is Sensitive tier (never auto-run), disabled, or the Emergency stop is on.
Blocked is a safety outcome, not a system failure. Failed means the action was attempted but the provider returned an error (wrong credentials, user not found, etc.).
5. Locked-out employee — recommended workflow
An employee who cannot sign in cannot use portal chat (they are not authenticated). Use this workflow instead:
1. Another employee, agent, or the helpdesk inbox reports the lockout — via email, phone, or an agent raising a ticket in the agent UI.
2. Agent creates the ticket with Raise on behalf of set to the locked-out person's work email. Add a clear title and description (e.g. "Account locked — cannot sign in").
3. QueAssist triage and resolution (or a matching playbook) runs against the ticket subject — alex@company.com, not the agent.
4. If write tools are enabled (e.g. reset password, enable account), QueAssist can execute them for Alex. If not enabled, QueAssist sends KB steps or escalates to a human.
5. Resolution email with Fixed / Still broken links goes to Alex's email when available.
6. Domain restrictions (Google & Microsoft)
Both directory connectors can restrict identity-scoped tools to your organisation's email domain:
| Provider | Setting | Effect |
|---|---|---|
| Google Workspace | Google Workspace domain (required when connecting) | Identity-targeted tools refuse users whose email is not on that domain. |
| Microsoft Entra ID | Primary email domain (optional) | When filled in (e.g. company.com), the same rule applies. Leave blank if you do not need an extra domain check. |
This stops QueAssist from accidentally targeting a personal email or a typo outside your tenant.
7. Tool permission tiers (recap)
Every integration tool is labelled Read, Write, or Sensitive:
- •Read — lookups only (account status, group membership). Runs automatically once the connector is verified.
- •Write — changes something (password reset, add to group). Off by default — you enable each tool individually.
- •Sensitive — never runs automatically; QueAssist always escalates to a human.
Full setup steps: Connecting Integrations & Custom MCP Servers.
8. Custom MCP servers — identity field
Custom servers expose their own tools. Before enabling a Write tool, you must tell QueueDesk which input field carries the user's email or username.
When you open a custom MCP tool in Settings → Integrations:
- •QueueDesk auto-detects a likely identity field from the tool's schema when possible. You'll see Scoped to:
fieldName(auto-detected) with a Change link.
- •Choose No identity needed only for tools that truly do not act on a specific person (e.g. a global status check).
- •For write tools, pick the correct field manually if auto-detect is wrong.
QueAssist injects the verified identity into that field server-side. The AI cannot substitute a different email.
9. Tool-call audit log
At the bottom of Settings → QueAssist, the Tool-call audit log lists every integration action — from portal chat, ticket resolution, playbooks, and external AI apps.
| Column | Meaning |
|---|---|
| Provider | Google Workspace, Microsoft Entra, Custom MCP server, or the name of an external AI app. |
| Tool | Which action was requested. |
| Ticket | Linked ticket, when the call happened in a ticket context. Portal chat rows may show —. |
| Source | Portal chat, Ticket resolution, or External AI app (MCP). Playbook steps appear under Ticket resolution. |
| Result | Success, Blocked, Failed, or Unknown. |
| Time | When the call occurred. |
Use this log to verify QueAssist acted on the expected person, to debug refused actions, and to review activity after enabling write tools.
10. Emergency stop
The Kill switch on Settings → QueAssist immediately stops all outbound integration actions — agentic resolution, playbooks, and directory tool calls — without disconnecting providers. Triage, draft replies, summaries, and portal conversation continue; nothing changes in Google, Microsoft, or your custom server until you turn the switch off.
It does not disable AI Agent Access (external apps connecting in). Use the separate Allow AI agent connections toggle for that.
Details: QueAssist Settings & Usage Quota — Emergency Stop.
11. Admin checklist
Before turning on write tools in production:
1. Connect and Test connection for Google Workspace and/or Microsoft Entra.
2. Set Primary email domain on Entra if you use UPNs on a single company domain.
3. Enable only the write tools you are comfortable with unsupervised.
4. For custom MCP, confirm the Scoped to identity field on every write tool.
5. Train agents to use Raise on behalf of for lockouts and proxy reports.
6. Optionally create a playbook for recurring access requests so steps are predictable.
7. Monitor the Tool-call audit log for the first week after go-live.
12. Related guides
- •Connecting Integrations & Custom MCP Servers — credentials, tool toggles, disconnect.
- •Agentic Auto-Resolution — confirmation email flow and when tools run.
- •No-Code Playbooks — deterministic integration steps per category.
- •Portal Mode — Forms vs AI Chat — when employees use chat vs forms.
- •AI Agent Access — external AI apps connecting into QueueDesk (inbound direction).