AI Assistant (OrbisAI)

OrbisID's AI/Intelligence Layer adds ten optional, AI-assisted features across the product: a conversational setup assistant, a natural-language Access Graph query, AI-assisted identity-link suggestions, AI-assisted PAM inventory linking, AI-assisted Account Type and Identity Type classification, AI-assisted Privilege Detection and Service Privilege Detection, narrative risk summaries, and Threat Detection clustering.

Two independent switches in Administration > Settings > OrbisAI control all of it:

• AI LLM — the master switch for everything that calls the local Ollama language model: the OrbisAI chat assistant (Onboarding Assistant, General Help, Natural-Language Access Graph Query), narrative risk summaries, Threat Detection clustering, and the ambiguous-case second opinion inside identity/PAM linking and Account Type/Identity Type/Privilege Detection classification.
• Smart Matching & Suggestions — the deterministic, non-AI fuzzy-matching engine behind identity-link suggestions, PAM inventory link suggestions, and Account Type/Identity Type/Privilege Detection classification suggestions. Runs entirely locally using text similarity, with no Ollama connection — it works even with AI LLM switched off.

Requires Pro or Enterprise

The AI/Intelligence Layer is not available on Community edition — see Licensing. Both switches described below only have any effect on Pro or Enterprise; on Community they are hidden/disabled in Administration > Settings > OrbisAI regardless of setting.

On by default, local-only

On editions where it's available, both switches are on by default — the first administrator to log in is asked to confirm this (or turn either off) in the same one-time Initial Setup prompt used for Check for Updates / Usage Statistics, and it can be changed at any time afterwards in Administration > Settings. AI LLM talks only to a locally hosted Ollama instance running inside your own network — no data ever leaves your network, and no external AI provider is used. Even with AI LLM on, every LLM-backed surface stays hidden (not shown-but-erroring) until an Ollama instance is actually reachable — see below.

Enabling the AI Layer

If you accepted the defaults during Initial Setup, both switches in step 2 below are already on — you only need step 1 (an actual Ollama instance for AI LLM to talk to; Smart Matching & Suggestions needs nothing further). If you turned either off at that prompt, or are configuring an existing install, do all three steps.

1. Start Ollama

There's nothing to do here — the release package (all-in-one or external-db) defines an ollama container that starts automatically with the rest of the stack, pulling its own image plus the default models (qwen2.5:1.5b-instruct, nomic-embed-text) from the internet on first start via a one-shot ollama-init container. Give it a few minutes on first start for those downloads, then skip to step 2. See Deployment — AI Runtime (Ollama) for how that's packaged and how to disable it if you don't want it running.

If you already run Ollama elsewhere on your network, you don't need the bundled container — just point OrbisID at it (see below).

2. Configure and enable in Administration > Settings

Navigate to Administration > Settings > OrbisAI and set:

Field	Default	Description
AI LLM	Off	Master switch for everything Ollama-backed. Nothing that calls the model has any effect while this is off.
Smart Matching & Suggestions	On	The deterministic fuzzy-matching engine. Independent of AI LLM — works with or without it.
Ollama Base URL	http://ollama:11434	The Ollama endpoint. Use http://localhost:11434 if you're running the local dev loop (dev.sh) — the backend runs on the host there, not inside the Docker network, so the ollama hostname doesn't resolve.
Chat Model	qwen2.5:1.5b-instruct	Model used for chat/instruction completions
Embedding Model	nomic-embed-text	Model used for retrieval-augmented grounding (Onboarding Assistant)
Request Timeout (seconds)	300	How long to wait for a response. CPU-only Ollama (no GPU/Metal passthrough, common in Docker Desktop, or a small/burstable cloud instance) is much slower than GPU-accelerated — increase this further if you see "taking too long to respond" errors, particularly for connector-scoped Onboarding Assistant questions, which send a larger prompt than general help and can run 2-3x longer.

Click Test Connection to confirm OrbisID can reach Ollama before relying on AI LLM. Note this only checks that the Ollama server itself responds — it does not confirm the configured Chat Model has actually been pulled; if chat still fails afterwards, check that the model is present (docker exec <ollama-container> ollama list).

3. What each switch enables

Feature	Switch	Requires
Onboarding & Help Assistant	AI LLM	Pro or Enterprise
Risk Narrative Summarisation	AI LLM	Pro or Enterprise
Access Graph Natural-Language Query	AI LLM	Pro or Enterprise (Access Graph itself is available on Community, but the AI query layer on top of it is not)
AI-Assisted Identity Linking	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
AI-Assisted PAM Inventory Linking	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
AI-Assisted Account Type Classification	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
AI-Assisted Identity Type Classification	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
AI-Assisted Privilege Detection	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
AI-Assisted Service Privilege Detection	Smart Matching & Suggestions (deterministic) + AI LLM (ambiguous-case escalation)	Pro or Enterprise
Threat Detection Clustering	AI LLM	Enterprise (same as Threat Detections)

For the six matching/classification features, the deterministic scorer always runs when Smart Matching & Suggestions is on — AI LLM only adds a second opinion for genuinely ambiguous cases, and each still works (just without that second opinion) if AI LLM is off.

A separate "LLM Escalation (Ambiguous Cases)" section on the same Settings tab gives each of those six features its own on/off toggle for just the LLM-escalation piece — Identity Linking, PAM Inventory Linking, Account Type Classification, Identity Type Classification, Privilege Detection, Service Privilege Detection. All are on by default. Turning one off stops that specific feature from ever calling the model, while leaving AI LLM on for everything else (chat, narrative summaries, natural-language graph query, threat clustering, and the other five escalation toggles) and leaving that feature's own deterministic scoring completely unaffected. These toggles only matter — and are only shown as enabled — while AI LLM itself is on; with AI LLM off, none of the six ever escalate anyway.

The Chat Assistant (OrbisAI)

A persistent chat icon appears in the bottom-left corner of every page once at least one chat-based feature is enabled. It's a single conversation, not a set of per-page modes — a connector-setup question and an Access Graph question can both be asked back to back, regardless of which page happens to be open: ask about adding a CyberArk connector from the Dashboard, or ask what an account can reach while the Systems "Add System" dialog is still up. By default, which capability answers a given message is decided automatically from the message itself (and, as a fallback, from whatever connector is currently in view, e.g. the "Add System" dialog, or from what the previous message in the conversation was about) — you never have to pick anything.

An "Ask about" dropdown at the top of the chat lets you pick a capability explicitly instead — OrbisID Help, Account / Access Question (the Access Graph), or Connector Configuration — when you already know what kind of question you're asking. This skips the automatic guess entirely, so it's both faster (no wasted attempt at the wrong capability) and useful when a question's phrasing is ambiguous enough that auto-detection might get it wrong. Leave it on Auto (the default) for everyday use.

Follow-up questions work within a conversation — asking "are you sure that's correct?" or "what about for a non-admin user?" right after an answer carries the last couple of exchanges along as context, so the assistant can actually address what was just said rather than treating every message as a brand-new, unrelated question. This is scoped to the current conversation only: nothing is stored once you close the browser tab or start New Chat, and it does not affect Audit Logs, which still only ever record a hash of each request, never full text.

The chat window stays open across pages until you close it with the × — it doesn't auto-dismiss if you click elsewhere. New Chat clears the conversation; reopening the launcher otherwise continues where you left off.

Onboarding Assistant

Ask about a connector by name from anywhere — e.g. "How do I configure CyberArk?" — or open its setup dialog on the Systems page and ask a question without naming it (e.g. "What permissions does the scan account need?"), which uses whichever connector is currently selected there. If a Test Connection attempt fails, the Need help with this error? link next to the failure pre-seeds the chat with the exact error for you.

Answers cite the section of OrbisID's own documentation they came from. The assistant never asks for, displays, or accepts a credential value — it will always direct you to the separate Credential fields instead.

General Help

Ask general "how do I" or "what is" questions about OrbisID itself, from anywhere — for example:

• "What is a KRI?"
• "How do I export a report to CSV?"
• "What's the difference between the Pro and Enterprise editions?"
• "How does PAM reconciliation work?"

This shares the same toggle and grounding approach as the Onboarding Assistant, just retrieving from OrbisID's whole user guide instead of one connector's page — answers still cite the section(s) they came from, and the assistant says plainly when a question isn't covered rather than guessing. If Access Graph Natural-Language Query is also enabled, a question is tried against the graph first (since many "who/what" questions are graph questions); if the graph decides it's genuinely not a graph question, general help answers instead, so you rarely need to think about which one will respond.

Natural-Language Access Graph Query

Ask a graph question from any page, for example:

• "What can svc-backup reach?" → blast radius from that account
• "Who owns the prod-db-01 server?" → ownership chain
• "How is jsmith connected to Domain Admins?" → shortest path
• "Show me unvaulted privileged accounts" → runs the matching pre-built query

The chat response always shows the interpreted query in plain English before any results, so you can confirm it understood correctly — this text is generated from the actual query that ran, not the model's own description of it, so it can't misdescribe what happened. If your question names something that matches more than one entity, you'll be offered the specific matches to pick from rather than a guess. Click Open in graph to load the result onto the Access Graph canvas — if that page isn't already open, this navigates there for you.

Read-only: no natural-language question can create, modify, or delete anything, and results are limited to whatever your role and licence could already see directly in Access Graph.

AI-Assisted Identity Linking

When you open the link identity dialog for an unlinked account on the Accounts page, a Suggested Matches list appears above the identity search box — ranked candidates with a confidence percentage and the reason for the match (e.g. "Account email matches the identity's email", "Account name matches the identity's initial and surname").

This works even with the AI layer completely off — the base matching is a deterministic name/email comparison, not an AI feature. When AI is enabled, genuinely ambiguous matches (neither clearly right nor clearly wrong) get a second look from the model, shown as method LLM instead of RULE.

Clicking a suggestion fills in the identity selection — on this page, nothing is ever linked automatically. If the account's PAM Risk Level is High or Critical, you'll always be asked for an extra explicit confirmation before the link is saved, regardless of how confident the suggestion is.

Auto-Linking via a Policy Rule (Pro+/Enterprise)

Requires the IDENTITY_LINKING_AUTO licence feature (Pro or Enterprise) in addition to AI-Assisted Identity Linking above.

For a hands-off alternative, create an Identity Linking (AI Auto-Link) rule on the Policy Rules editor (Configuration page) with a Confidence Threshold (0.51–1.00). Once enabled and attached to a Scan Policy, any unlinked account whose best AI-assisted match meets or exceeds that threshold is linked automatically during the scan — no manual click required. Use Test Rule first to see which accounts would link (and at what confidence) without actually linking anything, then Apply Rule to link them immediately, or just let it run on the next scheduled scan.

The High/Critical PAM risk exception above is absolute here too — it is not configurable and cannot be raised by the rule's threshold. An account on a High or Critical risk system is always left for manual review on the Accounts page, however confident the match. Every auto-link this rule makes is recorded in Audit Logs the same way a manually-confirmed suggestion is, with the matching method and confidence.

AI-Assisted PAM Inventory Linking

Requires the PAM_INVENTORY_LINKING_AUTO licence feature (Pro or Enterprise).

Unlike identity linking, privileged account names repeat constantly across an estate (root, Administrator, svc-backup on dozens of different servers), so name similarity alone can't reliably tell one PAM vault record from another. The matcher instead anchors on the vaulted credential's reported address (hostname or IP) against the account's own system — a candidate whose address doesn't plausibly correspond to the account's system is never scored highly on name similarity alone. This deterministic address/name matching runs even with the AI layer completely off; when AI is enabled, genuinely ambiguous matches get a second look from the model, shown as method LLM instead of RULE.

Create a PAM Inventory Linking (AI Auto-Match) rule on the Policy Rules editor (Configuration page) with a Confidence Threshold (0.51–1.00). Once attached to a Scan Policy, any privileged account not yet linked to a PAM inventory record whose best match meets or exceeds that threshold is linked automatically during the scan. Use Test Rule first to see which accounts would link (and at what confidence) without actually linking anything, then Apply Rule to link them immediately, or let it run on the next scheduled scan.

The same High/Critical PAM risk exception applies here, non-negotiable: an account on a High or Critical risk system is always left for manual review on the PAM Reconciliation page, however confident the match — a false "this dangerous account is vaulted" signal on the highest-risk accounts is exactly the failure this exists to prevent. Every auto-link this rule makes is recorded in Audit Logs with the matching method and confidence.

AI-Assisted Account Type / Identity Type Classification

Requires the CATEGORISATION_AI_AUTO / IDENTITY_CLASSIFICATION_AI_AUTO licence feature (Pro or Enterprise) respectively.

Account Type and Identity Type rules classify discovered accounts and identities as Human or Non-Human. The built-in rule catalogue covers common naming conventions (svc-, service-, low Linux UIDs, missing employee ID, and similar), but any account or identity that doesn't match one of those patterns is left unclassified. The AI classifiers exist specifically to cover that gap — they only ever run on accounts/identities no existing rule has classified, never on ones a rule-based match already decided. A deterministic keyword/pattern scorer (broader than the built-in catalogue) always runs first; when AI is enabled, a genuinely ambiguous score gets a second look from the model, shown as method LLM instead of RULE.

Create an Account Type (AI Auto-Classify) or Identity Type (AI Auto-Classify) rule on the Policy Rules editor with a Confidence Threshold (0.51–1.00). Once attached to a Scan Policy, unclassified accounts/identities whose best AI-assisted classification meets or exceeds that threshold are classified automatically during the scan. Use Test Rule first to preview what would be classified (and at what confidence), then Apply Rule to classify immediately, or let it run on the next scheduled scan.

Unlike privilege detection, this classification is bidirectional — the confidence threshold alone decides between Human and Non-Human, with no asymmetric safety rail (mislabelling in either direction is a data-quality issue here, not a security gap). A rule-based classification always takes precedence: if you later add or enable a SpEL Account Type / Identity Type rule that matches an AI-classified item, the rule-based result wins on the next scan.

AI-Assisted NHI Subtype Classification

Requires the AI_NHI_SUBTYPE_CLASSIFICATION licence feature (Pro or Enterprise).

NHI Subtype Classification assigns a finer-grained subtype (API Key, Service Account, Cloud Role, Managed Identity, Application, Scheduled Task, Bot, Certificate, Machine Account, Other) to Non-Human accounts, on top of the base Human/Non-Human Account Type above. Many connectors (see Systems) assert this directly from an unambiguous source-system signal at scan time — an AWS IAM access key, an Azure AD service principal's certificate, a CyberArk platform ID, and similar — no rule or AI involved. For everything else, the built-in NHI Subtype rule catalogue covers common naming conventions, and the AI classifier covers what's left: it only ever runs on Non-Human accounts no connector signal or existing rule has already classified, never on ones a connector hint or rule-based match already decided. A deterministic keyword/pattern scorer always runs first; when AI is enabled, a genuinely ambiguous score gets a second look from the model, shown as method LLM instead of RULE.

Not yet available in the Policy Rules editor

Unlike the other AI Auto-Classify rule types on this page, NHI Subtype Classification (AI Auto-Classify) rules can currently only be created and run via the Policy Rule API (test/run endpoints) — there is no Configuration page UI for this rule type yet. The base, non-AI NHI Subtype SpEL rule type is available in the Policy Rules editor today.

Once created via the API with a Confidence Threshold (0.51–1.00) and attached to a Scan Policy, matching Non-Human accounts are classified automatically during the scan — the same test-first, apply-or-schedule workflow as the other AI Auto-Classify rule types.

This classification is bidirectional in the same sense as Account Type / Identity Type — there's no asymmetric safety rail, since assigning the wrong subtype is a data-quality issue, not a security gap. A connector signal or rule-based classification always takes precedence: if a later scan's connector hint or a SpEL NHI Subtype rule matches an AI-classified account, the higher-tier result wins.

AI-Assisted Privilege Detection / Service Privilege Detection

Requires the PRIVILEGE_DETECTION_AI_AUTO / SERVICE_PRIVILEGE_DETECTION_AI_AUTO licence feature (Pro or Enterprise) respectively.

Privilege Detection and Service Privilege Detection rules flag discovered entitlements and services as Privileged. The built-in rule catalogue matches specific, literal group/user names (Domain Admins, sudo, root, and similar) — any custom or organisation-specific privileged group ("DBA-Team", "IT-Support-L3") or non-root-run privileged service won't match. The AI classifiers exist specifically to cover that gap — they only ever run on entitlements/services no existing rule has already flagged as Privileged. A deterministic keyword/pattern scorer (broader than the built-in catalogue — for example it also recognises individual sudo privilege entries the catalogue's group-name matching misses entirely) always runs first; when AI is enabled, a genuinely ambiguous score gets a second look from the model, shown as method LLM instead of RULE.

Create a Privilege Detection (AI Auto-Classify) or Service Privilege Detection (AI Auto-Classify) rule on the Policy Rules editor with a Confidence Threshold (0.51–1.00). Once attached to a Scan Policy, not-yet-privileged entitlements/services whose best AI-assisted classification meets or exceeds that threshold are flagged Privileged automatically during the scan. Use Test Rule first to preview what would be flagged (and at what confidence), then Apply Rule to flag immediately, or let it run on the next scheduled scan.

Two safety properties apply here, both non-negotiable:

• One-directional. These rules can only ever add Privileged status — never remove or downgrade an entitlement/service a rule, a manual override, or a previous AI classification already marked Privileged. Under-flagging a privileged entitlement (a missed audit finding) is a worse failure than over-flagging one (review noise), so there's no symmetric "AI thinks this isn't privileged" action.
• Shared per-scan escalation cap. Because a single system can have thousands of entitlements, the LLM second opinion is capped per scan (combined across entitlements and services, admin-configurable, default 20) — the deterministic scorer still evaluates everything, but only a bounded number of genuinely ambiguous items get a model call in any one scan. Anything beyond the cap is simply reconsidered on the next scan, never treated as decisively non-privileged.

Narrative Risk Summarisation

A short, plain-English summary appears in two places once enabled:

• Dashboard — a collapsible panel directly above Threat Detection Alerts, broken into three columns (Current State, Progress Since Last Month, Recommended Next Steps) summarising the latest scan's KRI values and how they've changed since the previous scan. There's no regenerate control here — it refreshes automatically as a side effect of each scan; an administrator can also trigger it on demand with Generate Risk Summary Now in Administration > Settings > OrbisAI (the only way to produce it before your first scan).
• Gap Analysis PDF report — an "AI-Generated Risk Summary" section, generated when the assessment is completed and regenerable from the assessment page before your next download.

Both summaries are generated only from already-computed values (KRI numbers, gap-analysis finding counts) — never from account-level or identity data — and are cached, so historical reports stay reproducible even if you later change the AI model or prompt. Regenerating updates the cached copy but does not rewrite past PDF exports you've already downloaded.

Threat Detection Clustering

Requires Enterprise edition (same as Threat Detections itself).

On the Threat Detections page, a Clusters | All Alerts toggle appears once enabled. Clusters group related alerts for the same account within a configurable time window into a single incident card, showing the systems and detection rules involved, the highest confidence score, and a short AI narrative explaining the pattern. Expand a cluster to see (and action) the individual constituent alerts exactly as before.

Clustering itself is a deterministic grouping, not an AI feature, so clusters still form correctly if the AI layer is briefly unreachable — only the narrative text is missing in that case. Clustering never changes the underlying Threat Detection engine or its confidence scoring; it only changes how related alerts are presented. All Threat Detections surfaces, clustered or not, retain their Beta labelling.

Audit Trail

Every AI call is recorded in Audit Logs — which feature made the call, which model, timing, and a hash of the prompt, never its full content. The one exception is the Access Graph natural-language query, where the brief requires the actual question text and interpreted query to be logged in full (still alongside a separate hash-only entry for the underlying model call) so query interpretation itself is fully auditable.

Data Sent to the Model

Because the runtime is local-only Ollama, nothing here ever leaves your network — but each feature is still deliberately scoped to send the minimum it needs:

Feature	Sent to the model
Onboarding Assistant	Your question, the selected connector type, and matching sections of OrbisID's own documentation. Credential-shaped text is stripped before sending.
General Help	Your question and matching sections of OrbisID's own user guide. Credential-shaped text is stripped before sending.
Access Graph query	Your question text only. Entity names are resolved to database records separately, after the model responds.
Identity linking	The account name and the shortlisted identities' display names — never raw account attributes or credentials.
PAM inventory linking	The account name, its system's hostname/IP, and the shortlisted PAM records' account name/safe name/address — never credentials.
Account Type classification	The account name only.
Identity Type classification	The identity's full name, email, and whether it has an employee ID (not the ID value itself).
Privilege Detection	The entitlement's name and type only.
Service Privilege Detection	The service's name, type, run-as account, command, and description.
Risk narrative	Computed KRI values/deltas and gap-analysis finding counts — never account-level or identity data.
Threat clustering	Detection rule names, system names, alert counts, and confidence scores — never raw event data.