Admin Portal

The Admin Portal is the system-level control surface of MCintelligentplus: instance admins configure the model catalogue, authentication, connectors, storage, messaging bots, skills, security, credits, and can inspect users, workspaces, analytics, logs, and audit trails — all without shelling into the container.

What you get

Highlights:

• Models — central model management with full per-model configuration; model config is stored in the database (not YAML) as the single source of truth, and the workspace chatbot resolves it per turn. Each model can also be limited to selected organizations (see Model access per organization below).
• Security — the prompt-injection guard selector is DB-first: the portal value wins over SURFSENSE_PROMPT_GUARD from the environment, so a GUI edit takes effect without redeploying. Guard findings are filterable in Audit Logs (action=prompt_guard.flagged).
• Sandbox — turn code execution on, create runtime profiles for Docker, Podman, Kubernetes, or Daytona, and see each profile's health (see Code execution below).
• Credits — wallet settings, signup bonus, referral rewards, auto-reload.
• Logs — capture level, expandable rows, per-row copy button, and a "Copy for AI" button that copies the filtered set.

Code execution (Sandbox)

Admin → System → Sandbox (/admin/system/sandbox) is where a system admin configures sandboxed code execution without touching a .env file:

• the deployment-wide Code execution switch and the Default profile;
• a table of runtime profiles (Docker, Podman, Kubernetes, Daytona) with status, isolation tier, last test, last canary, and live sandboxes;
• the profile wizard — generate the gateway credential, test the connection, trust the certificate, run the canary, acknowledge risks, activate;
• per-profile settings, credential rotation, disable, and delete.

Profiles are assigned per organization on Admin → Organizations, and each workspace gets its own on/off switch and quota on Admin → Workspaces. All changes are audited and reach the API and workers within about 15 seconds. Only SANDBOX_ENABLED and SANDBOX_GUI_CONFIG remain as environment switches. The full guide is on the Code Execution page.

Context and retrieval

Admin → System → Context & retrieval (/admin/system/context-management) is the platform tier for context management: the compaction on/off switch, the trigger and keep ratios, tool-output masking, the hard floor, the max summary tokens and the summary model — plus the retrieval rerank toggle, off by default. The page also sets the bounds (the allowed range for every value) and the locks (fields that organizations and users may not override). One save writes every changed key as a single bulk update, each field shows whether its current value comes from the database, an environment variable or the built-in default, and a live preview shows the token equivalents for a sample window.

System jobs

Admin → System → System jobs (/admin/system/jobs) lists every scheduled system job the deployment runs — memory consolidation, retention sweeps, credit reconciliations, gateway health checks, cache and notification maintenance — with the status of its last run (success, failed, running, skipped, never), when it last ran and when it runs next. An admin can change a job's schedule within its bounds or disable it; changes land within a minute, without a restart or redeploy, and critical jobs ship with a pinned schedule that says why. Run now dispatches a job on demand, and the detail drawer shows the last 20 runs with durations and error excerpts. Schedules are deployment-wide by design — user- and workspace-created automations are a separate feature and never appear on this page.

Model access per organization

Admin → Models (/admin/models) lets a system admin decide which organizations can use each system model:

• Every model row shows an All orgs / N orgs badge. The Organizations action opens a checklist (with search and select all/none) that reports "available to N of M organizations" and how many workspaces currently use the model, so the review happens before saving.
• All organizations (the default) keeps today's behaviour. Selected organizations limits the model to the checked set; selecting none is allowed and means no org workspace can use it.
• A global disable still wins: a model switched off in the catalogue is unavailable everywhere, whatever the org selection says.
• Saving is refused (ORG_WOULD_HAVE_NO_CHAT_MODEL) when the change would leave an organization with no allowed chat model — the error names the organization.
• Embedding models cannot be restricted: a fallback would mean re-embedding a knowledge base or searching with mismatched vectors. They are recognised by embed in the model id, and the dialog hides the Organizations action for them (the API refuses with MODEL_IS_EMBEDDING).
• Workspaces in a non-allowed org don't see the model in their picker, and assigning it via the API is rejected (MODEL_NOT_ALLOWED_FOR_ORG). Existing assignments are not rewritten: the next chat turn, automation or /ext call falls back to an allowed model, and the person chatting sees a notice. /ext API calls fail with 403 MODEL_NOT_ALLOWED_FOR_ORG instead, so API clients find out. Automation run logs record the substitution.
• Org owners get a read-only Models page in the org console and a notification when a model they could use is removed.
• Personal workspaces (not attributed to an organization) keep every globally enabled model in v1.

Every change is audited as model.org_access_updated and applies to the next request (other workers within the existing cache TTL).

How to enable

The portal is always available to instance administrators — there is no feature flag. Access is granted by User.is_admin (see Admin → Administrators). Many pages write configuration that is resolved DB-first (admin GUI value, then env var, then default) and reload without a restart; other settings are env-only and need a redeploy.

Where in the UI

• Open the avatar menu in the workspace and choose Admin, or go to /admin.
• Admin → API Clients for External Chat API clients and their per-client chat keys (list, revoke).
• Admin → System → Security for the prompt guard; Admin → Audit Logs for findings.
• Admin → System → Sandbox for code execution runtime profiles.
• Admin → System → Context & retrieval for the compaction defaults, bounds, locks and the retrieval rerank toggle (see Context Management).
• Admin → System → System jobs for the platform's scheduled jobs, run history, bounded schedule overrides, and Run now.
• Admin → Models for the model catalogue and per-organization model access.

Related PRs

• #205 — Admin Portal; #47 — Admin System Configuration GUI; #216 — system roles
• #249 / #255 / #510 / #955 — central model management, planner model, DB as the single source of truth, full model config
• #597 — feedback widget with internal storage and admin review
• #658 / #660 — object storage in the Admin Portal
• #664 / #778 — system logs S1 and per-row copy
• #959 — dedicated max_tokens and temperature fields
• #961 / #962 — credits config page and unit fix
• #693 / #709 / #711 — embedding config read-only + Test Connection
• #1270 — per-organization model access on Admin → Models
• #343 — in-app feedback