Enterprise Portal

The Aura Enterprise Portal is the control plane for running Aura Workshop across an organization. From one dashboard your administrators enroll devices, publish security and spend policy, operate a central LLM gateway, and monitor usage, cost, tool calls, and an audit trail — while every policy is enforced locally on each node, offline, with no per-user login. It is the enterprise counterpart to the desktop app: the app runs the agents, the portal governs them. This guide covers the portal for Aura Workshop 1.36.2.

What the portal is

A multi-tenant control plane that aggregates telemetry from a fleet of Aura Workshop deployments and pushes governance back down to them. The portal is organized into the sections below, documented here in the order you typically use them — sign in, set up your organization, enroll devices, define policy, configure the gateway, then monitor.

The portal pipe is entirely separate from the anonymized training / diagnostics pipe (metrics.secureinsights.ai) and from licensing / updates / billing (control.secureinsights.ai). The gateway's default host is gateway.secureinsights.ai. On-prem deployments simply point the enrollment file's URLs at the customer's own portal and gateway.

Signing in & first-run organization setup

Browse to portal.secureinsights.ai and choose Sign in. Authentication is handled by your organization's identity provider through WorkOS AuthKit — depending on how your org is configured you sign in with a social / work account (Google, Microsoft) or are redirected to your company SSO (SAML / OIDC). Each sign-in re-authenticates; signing out fully ends the session.

The first person to sign in for a newly purchased plan becomes the organization Owner. Subsequent members are added under Users or provisioned automatically through SCIM directory sync.

First-run setup

The first time an Owner or Admin signs in, a one-time setup dialog appears so you can establish your organization identity (also editable later under Settings → Organization Profile):

• Organization name — required. This is the name shown on every managed device ("Managed by your company") and on invoices. A fresh signup otherwise defaults to your email domain.
• Contact email — the IT / admin contact for your organization.
• Phone and Website — optional details.
• Logo — an image (max ~380 KB) shown across the portal and on managed devices.

Click Save & continue to finish, or Skip for now to be reminded next sign-in. The organization name you set here propagates to enrolled devices on their next policy sync.

Monitoring

Every enrolled node ships tenant-scoped telemetry outbound to the portal on a background cycle, and the gateway meters every request it proxies. Together these feed four monitoring surfaces.

Usage

The Usage dashboard is the portal landing page. It shows live token throughput and request volume across every enrolled device and every gateway-routed call, broken down by model and provider over a selectable time range. Data arrives from two sources: telemetry uploaded by each Aura Workshop node, and metering recorded directly by the gateway for every proxied request.

Cost

Cost translates usage into dollars, aggregating spend by provider, model, user, and time period. Because spend is metered centrally at the gateway (and by node telemetry), the figures reflect true consumption regardless of which client made the call. Cost data underpins the per-user spend caps you set in Policies and Users.

Tool Calls

Tool Calls is an audit feed of the agent tool and function invocations your nodes perform — file edits, shell commands, web requests, MCP tools, and so on. It gives security teams visibility into what the agents actually did, not just what they said. Each row carries the tool, success / failure, and a short summary (including blocked when a guardrail intercepted it). Combined with Guardrails, this is the basis for tool-level governance.

Audit Log

The Audit Log is an immutable record of administrative actions in the portal: device enrollment, enable / disable, policy publishes, profile changes, token mint / revoke, and more. Each entry records the actor, the action, the target, and a timestamp. Audit and event records are designed to be append-only and hash-chained per organization for tamper-evidence, so entries cannot be silently altered. Use it for compliance evidence and to investigate configuration changes.

Users & roles

The Users section lists everyone in your organization and their role. Roles determine what each member can do in the portal, and are enforced by an API permission check plus mandatory org-level row scoping.

You can set a per-user spend cap (daily and monthly) here. As a user nears their cap the gateway can automatically route them to cheaper models (see Spend-aware routing); when they hit it, further calls are blocked with a clear error. Suspending or deleting a user immediately revokes their gateway access. Members can be invited directly or provisioned automatically from your directory via SCIM.

Licenses

The Licenses section shows your license keys and the seat entitlements attached to your plan. A license key unlocks the paid feature set in Aura Workshop; in managed mode the entitlement is applied automatically to enrolled devices, so end users never paste a key. On a managed node the org enrollment is the license entitlement — the node reports the managed tier with the full feature set and no network check. Seat counts here are the basis for the seat usage shown in Deployments.

Deployments & managed mode

Deployments is where you roll Aura Workshop out to your team. Each node runs in one of two modes:

• Standalone — the user configures their own provider keys and settings locally (the default for individual installs).
• Managed mode — the device is enrolled into your organization. It pulls policy from the portal, can route through your central gateway, bypasses the setup wizard, and shows a "Managed by your company" banner. Every settings surface your policy governs (provider keys, model allow / block, routing, spend caps, guardrails) renders read-only on the device, so users can't override what the org has set.

A device becomes managed by reading an enrollment file at startup. Managed mode is a durable local flag that survives settings resets. The device table lists every enrolled machine — hostname, machine ID, app version, last-seen heartbeat, and status — and a seat equals one enabled device. From here you can:

• Disable a device — immediately revokes its access (it shows as disabled in the app) without losing its enrollment; re-enable anytime. This is a soft disabled flag; you can also mark a device restricted (limited but still observable).
• Watch seats used vs. purchased ("N used / M purchased") — exceeding your plan warns you and bills the extra seats next cycle.
• Set managed app-update approval — nodes can be told to auto-update or to install only releases the org has approved.

Whether nodes route their model calls through the gateway is controlled in Policies → Gateway routing; the central keys and tiers live on the Gateway page.

Device enrollment (zero-login)

An IT admin drops an enrollment file so a device self-registers with no per-user login and skips the setup wizard. Generate it under Deployments → Generate enrollment file; you can edit the URLs inline before downloading (useful for on-prem / customer-hosted gateways), then Download or Copy.

The enrollment file

aura-enroll.json is a small JSON document that tells Aura Workshop which organization to join and where to send telemetry and model calls. Only portal_url and join_token are required; on-prem admins edit the other URLs to point at their own server.

{
  "portal_url":  "https://portal.secureinsights.ai",
  "join_token":  "aura_join_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "gateway_url": "https://gateway.secureinsights.ai",
  "ingest_url":  "https://portal.secureinsights.ai"
}

• join_token — an organization join secret, shown once; copy or download immediately. The same token is reusable across all of this org's machines.
• portal_url / ingest_url — the policy / enrollment API and telemetry endpoints.
• gateway_url — the LLM gateway calls are proxied through. For a customer-hosted gateway, point this at your own server.

When the app finds this file on startup it self-registers by machine ID, stores its device tokens, applies your policy, and switches to managed mode. Find-or-create on the portal is keyed by (org, machine_id), so re-enrolling the same hardware never mints a duplicate seat. The file is safe to distribute to many machines; each registers as a distinct device.

Where the file is found (priority order)

On startup Aura Workshop searches three locations and uses the first it finds:

1. The path in the AURA_ENROLL_FILE environment variable (highest precedence).
2. The application data directory (per-user) — the recommended location for most rollouts.
3. Next to the application executable — convenient for MDM-packaged or portable installs.

Application data directory per platform:

Example — copy the downloaded file into place on macOS:

mkdir -p ~/Library/Application\ Support/aura-workshop
cp ~/Downloads/aura-enroll.json ~/Library/Application\ Support/aura-workshop/

For MDM (Jamf, Kandji, Intune, SCCM) or config management (Ansible, Puppet), push the file to the per-user app-data path or alongside the binary as part of the package.

Sourcing via AURA_ENROLL_FILE

Instead of a fixed directory, point Aura Workshop at any path with the AURA_ENROLL_FILE environment variable. It takes highest precedence and is the cleanest option for MDM / golden-image rollouts, because the file can live anywhere (including a read-only managed location).

# macOS (GUI apps — global launchd variable)
sudo launchctl setenv AURA_ENROLL_FILE /opt/aura/aura-enroll.json

:: Windows (current user; use /M as Administrator for machine-wide)
setx AURA_ENROLL_FILE "C:\ProgramData\aura\aura-enroll.json"

# Linux (machine-wide, all users)
echo 'AURA_ENROLL_FILE=/opt/aura/aura-enroll.json' | sudo tee -a /etc/environment

Restart the app (or sign out / in) after setting the variable so GUI sessions pick it up.

Enrollment lifecycle

Enrollment is idempotent and self-healing. On each cycle an enrolled node re-verifies its device status with the portal, refreshing the disabled and restricted soft flags. If the device was revoked, or its tokens were deleted server-side, the node clears its stale identity and re-enrolls automatically — reappearing in the fleet within one cycle without a restart. To fully remove a node, delete it in the portal; the next check unenrolls it locally: it reverts to standalone, clears its managed settings, resets to the default license tier, and renames the file to aura-enroll.json.unenrolled so a relaunch won't auto re-enroll.

Policies

Policies is your organization's security and governance baseline. You edit a draft, then publish a versioned policy; every managed device pulls the latest published version on its sync cycle and enforces it locally, so enforcement works offline. Each policy field maps to a primitive Aura already enforces on the node — the portal just publishes the values. Policy can only tighten what a user may do; users cannot override it on their device, and the portal keeps every published version for rollback and audit.

Model allow / block & ZDR

The model gate evaluates in a fixed order: block wins → ZDR → allow ceiling.

• Blocked models — always denied, even if they match the allow list.
• ZDR — when enabled, restricts usage to a curated set of models that contractually do not retain prompt data; anything outside that set is blocked.
• Allowed models — if non-empty, only these are permitted (empty means all are allowed). Unenrolled nodes have no lists set, so everything is permitted.

The same gate is enforced both on the device and centrally at the gateway, so a blocked model is refused no matter which path a request takes.

Tool categories

Set a ceiling on which categories of agent tools are available — Core (files, bash, search, web, memory), MCP (all mcp_* tools), Automation (listeners, webhooks, schedules), Management (skills, teams, workflows, settings), Device (screen, camera, notifications), Desktop (browser, native app control), and Docker (container run / list / images). The node intersects its local tool set with this allowlist, so disabling a category removes those tools from every agent fleet-wide.

Spend caps

Define daily and monthly spend limits per provider. They are checked before every model call and synced to each device's local spend_limits; per-user caps are set in Users. Together with spend-aware routing, caps let you soften the impact before a hard stop — routing users to cheaper models as they approach the limit.

Guardrails

Guardrails are content rules enforced around the model and tool calls. Built-ins include detect-secrets and PII-in-input, prompt-injection detection, secrets / PII-in-output redaction, block-destructive-bash, and an output-token ceiling. Each rule has an action: block, warn, or redact, and you can add custom pattern-based rules. Policy guardrails only add protection — they never weaken a rule a user already enabled, so they can only tighten security. The node runs the full set (input, output, and tool stages) locally; the gateway additionally enforces input-stage DLP server-side, so every client is covered — including direct-API customers without Aura Workshop.

Gateway mode

The Gateway routing directive decides whether (and which) gateway your fleet routes through:

• Off — nodes call providers directly with their own keys.
• SaaS gateway — route all model calls through gateway.secureinsights.ai using your org's central keys.
• Customer-hosted gateway — route through a gateway URL you operate.

When a gateway mode is on, the node redirects its providers to the gateway and uses its device gateway token as the key — so every call benefits from central keys, per-user caps, and the model gate without the user ever holding a provider key.

The central LLM gateway

The Aura Gateway is a centralized, multi-protocol LLM proxy (default host https://gateway.secureinsights.ai). It speaks the OpenAI API (/v1/chat/completions, /v1/models) and the Anthropic API (/v1/messages). It holds your central provider keys, enforces policy (model gate, ZDR, per-user spend caps), records usage and cost, and can intelligently route requests across models. Clients authenticate with a gateway token and never see the underlying provider keys.

Provider keys

On the Gateway page you add your organization's API keys for each upstream provider (Anthropic, OpenAI, Google, DeepSeek, Moonshot / Kimi, MiniMax, OpenRouter, and more). These are the keys the gateway uses on your behalf when proxying. You can store multiple keys per provider with weights for load balancing, edit or disable individual keys, and the gateway resolves the right key for each call. Because keys live only at the gateway, you rotate or revoke them centrally without touching a single device.

Routing (weighted tiers)

Gateway routing lets a single virtual model — auto — be scored and dispatched to a concrete model automatically. It is configured entirely on the Gateway page and is independent of any node's local router.

• Tiers — define the models for Simple, Standard, Complex, and Reasoning. Each request is scored for complexity and sent to one model in the matching tier.
• Weighted load balancing — within a tier, each model has a weight; requests are spread across them by weight (sticky per conversation to keep provider caches warm).
• Scorer thresholds — tune the complexity cut points that map a request to a tier.
• Routing rules — optional conditions (e.g. token count, tool count, prompt contents) that override the score and pin a request to a tier or model.

Fallback & spend-aware routing

• Fallback — if the picked model errors or is over its cap, the gateway walks the fallback order (independent of the load-balancing weights, so you control exactly where traffic shifts on failure). Fallback applies to routing / pricing only; a pinned concrete model never silently switches.
• Spend-aware routing — for auto requests, as a user approaches their spend cap the gateway drops them to a cheaper tier, softening the hit before the hard limit.

Gateway tokens

A gateway token is the bearer credential clients use to call the gateway. Tokens are organization- and (optionally) user-scoped, stored only as a hash, and revocable at any time. There are two ways they come into existence:

• Device tokens — minted automatically when a device enrolls; the managed Aura Workshop app uses these transparently.
• API keys — mint a standalone token in the portal to let any OpenAI / Anthropic-compatible client use your gateway without Aura Workshop. The raw token is shown once; store it securely. Scope it to a user to attach per-user spend caps and attribution.

Every request to the gateway requires a valid, non-revoked token — a missing or invalid token returns 401.

Connecting clients to the gateway

The gateway is OpenAI- and Anthropic-compatible, so most existing tools and SDKs work by overriding two things: the base URL and the API key.

The gateway accepts the token in either header, so both client styles work:

Authorization: Bearer aura_gw_...      # OpenAI style
x-api-key: aura_gw_...                  # Anthropic style

A quick smoke test with curl:

curl https://gateway.secureinsights.ai/v1/chat/completions \
  -H "Authorization: Bearer aura_gw_..." \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hello"}]}'

Aura Gateway Routing (model: "auto")

Set model to auto and the gateway scores the request, picks a tier, and weighted-picks a concrete model for you; the response's model field tells you which model actually served it. You can also pin a tier with auto:simple, auto:standard, auto:complex, or auto:reasoning. Sending a concrete model ID instead still flows through the gateway for keys, caps, and policy — just without the scorer. Inside the managed Aura Workshop app this is exposed as the Aura Portal Routing model in the picker, available only when your org has enabled gateway routing.

CLI tools & SDKs

Any tool that lets you override the OpenAI or Anthropic base URL and key can use the gateway. Replace the provider's key with your aura_gw_ token, and the base URL with the gateway. For routing, set the model to auto; otherwise use a concrete model your org has a central key for.

# Claude Code (Anthropic CLI)
export ANTHROPIC_BASE_URL="https://gateway.secureinsights.ai"
export ANTHROPIC_AUTH_TOKEN="aura_gw_..."   # sent as Authorization: Bearer
claude

# OpenAI Codex CLI
export OPENAI_BASE_URL="https://gateway.secureinsights.ai/v1"
export OPENAI_API_KEY="aura_gw_..."
codex

# aider
export OPENAI_API_BASE="https://gateway.secureinsights.ai/v1"
export OPENAI_API_KEY="aura_gw_..."
aider --model auto

OpenAI SDK (Python / Node) — override base_url and api_key:

# Python
from openai import OpenAI
client = OpenAI(
    base_url="https://gateway.secureinsights.ai/v1",
    api_key="aura_gw_...",
)
client.chat.completions.create(model="auto",
    messages=[{"role":"user","content":"hello"}])

// Node
import OpenAI from "openai";
const client = new OpenAI({
  baseURL: "https://gateway.secureinsights.ai/v1",
  apiKey: "aura_gw_...",
});

LangChain:

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
    base_url="https://gateway.secureinsights.ai/v1",
    api_key="aura_gw_...",
    model="auto",
)

LiteLLM:

model_list:
  - model_name: aura-auto
    litellm_params:
      model: openai/auto
      api_base: https://gateway.secureinsights.ai/v1
      api_key: aura_gw_...

The same pattern works for any OpenAI-compatible client (LlamaIndex, Continue, Cursor, Open WebUI, etc.): base URL https://gateway.secureinsights.ai/v1, key aura_gw_.... Every call is authenticated, policy-checked, metered, and (with auto) intelligently routed — with no provider key ever leaving the gateway.

SSO & SCIM provisioning

The Settings page holds your Organization Profile and your identity integration. Under Single Sign-On & Provisioning you can:

• Configure SSO (SAML 2.0 / OIDC) — let your team sign in with Microsoft Entra ID, Okta, Google Workspace, Ping, OneLogin, and others. The button opens a secure hosted setup wizard (WorkOS Admin Portal) where your IT admin uploads metadata — no code, nothing leaves your IdP boundary.
• Directory Sync (SCIM 2.0) — automatically provision and de-provision users from your directory, and map directory groups to portal roles.

Once connected, new hires get portal access automatically and departures lose it immediately. Note that identity governs portal access; enrolled Aura devices themselves use zero-login device enrollment, not per-user login.

Self-hosted & air-gapped

The portal is designed to run from a single codebase in two modes — SaaS multi-tenant, or a self-hosted appliance a customer runs entirely within their own boundary. In the appliance model, nodes POST telemetry to the customer's own portal and gateway, so data never leaves their infrastructure; every table is org-scoped from day one (single-tenant is just "one org"), and all telemetry remains outbound-only push.

Identity is designed to run through WorkOS for both modes, with a fallback to direct OIDC against an internal IdP for air-gapped deployments, behind a common identity interface so both builds share one codebase. Every dataset is designed to be exportable (CSV / JSON / NDJSON with a signed manifest) via the UI, an Export API, scheduled export, and SIEM streaming — scoped by role. The admin UI is a self-contained static SPA served by the portal's own server with no external runtime dependencies, so it can run air-gapped.

Related

For the node-side deployment mechanics referenced above — the daemon image, remote deployment, isolation layers, and guardrails — see Deployment & Security. For provider setup and Aura Routing on standalone installs, see Models & Providers. For the full node REST and /v1/* surface, see the API Reference.