Concepts

This page defines the core entities you will encounter throughout Robost. Understanding how they relate to each other makes it easier to configure policies, interpret alerts, and navigate the dashboard.

Organization

An organization is the top-level tenancy boundary in Robost. Every piece of data — alerts, detections, employees, applications, policies — belongs to exactly one organization. Isolation is enforced at the database level using PostgreSQL Row-Level Security (RLS), meaning one organization can never read another’s data regardless of application-layer logic.

Application

An application is an AI tool that Robost can observe. The current set of monitored applications is ChatGPT, Claude, and Gemini; the extension adapter pattern makes it straightforward to add others. Each application in the admin dashboard carries a risk-tier classification (Critical, High, Medium, or Low), usage statistics, and a per-employee breakdown of activity.

Detection

A detection is a typed finding produced when the browser extension classifies a prompt submission as containing sensitive content. There are 25 detection types organized across categories including PII, security credentials, financial data, healthcare records, legal documents, HR records, Confidential Business Information, and source code. For the full list and per-type descriptions, see the Detection Types Reference.

Policy

A policy (called a “scenario” in the configuration UI) is a rule that targets a specific combination of application and detection type and specifies what action to take when that combination is observed. Policies support default scenarios (apply to all applications or employees) and exception scenarios (apply to a narrower subset). When a prompt is submitted, the extension evaluates all active policies for that application and fires the highest-priority matching action. See Creating a Policy for the full authoring workflow.

Action

An action is the enforcement response specified in a policy. Robost supports three actions for sensitive data detections:

• Monitor — log the event silently; the employee is not interrupted.
• Warn — surface an in-page warning and require the employee to provide a justification before proceeding.
• Block — prevent the submission entirely; the employee must remove the flagged content.

For application-access policies (controlling whether an AI tool may be used at all), the available actions are allow, advise, and block. For full details on each action’s behavior see Actions.

Alert

An alert is the persisted record created in the admin dashboard when a policy fires on a detection. Alerts appear in the Alerts Inbox and include the detection type, the application, the employee, the action taken, and — where the employee chose to warn rather than be blocked — the justification they supplied. Alerts support a triage workflow (mark reviewed or escalate) and a feedback loop so admins can signal false positives.

Exposure

An exposure is the underlying data event: a prompt submission that contained sensitive content, regardless of whether a policy existed at the time it occurred. An exposure may predate the alert that references it if a policy was added or changed after the submission was captured. This distinction matters when reviewing historical data — you may see exposures from before any policies were configured.

Employee

An employee is a user account linked to one or more enrolled browser extension devices. Robost associates detections and alerts with employees, enabling per-person drill-downs in the Employees module. Employees are created separately via the Employees module before a device can be enrolled — device enrollment links an existing employee to a device credential (the POST /settings/devices API requires a pre-existing employee_id). Employee records include department affiliation, detection counts, application usage breakdown, and intervention history.