Skip to content

Intelligence integrations

SecOpsAI supports two separate model-assisted operating modes. Both use the same versioned, read-only intelligence contract and both keep raw scanner output, packet data, package artifacts, credentials, and private keys outside model context.

Choose the correct mode

Mode Where the model runs Authentication Best use
Local Codex bridge Codex CLI on the operator's Mac or Linux sensor Existing local ChatGPT sign-in Private local analysis and Mission Control actions
MCP Gateway Any approved compatible MCP host calls the same hosted SecOpsAI gateway SecOpsAI OAuth plus the client's own model authentication Provider-neutral access to authorized findings, assets, and research cases

ChatGPT authentication pays for and identifies the model session. SecOpsAI OAuth separately decides which SecOpsAI data that person may read. One never replaces the other.

Local OpenCodex / multi-model bridge

SecOpsAI can use your local OpenCodex proxy so research analysis is not locked to one ChatGPT account.

Research actions request evidence-led structured output rather than a chat-style paragraph. A completed case analysis includes an executive summary, confirmed facts, inferences, unsupported claims, contradictions, missing evidence, prioritized next steps, a confidence-scored verdict, evidence references, limitations, and publication risks. Mission Control presents these fields separately and retains the complete normalized result and job history.

Persistent model routing

Open Administration → Automation → Models to choose any model returned by the local OpenCodex catalog. The selected primary model is persisted by Core, so a refresh, a closed browser tab, or a restarted bridge does not silently replace it with a provider default. The same workspace shows the effective chain and lets an operator add, remove, and reorder explicit fallbacks.

Fallback behavior is opt-in and explainable:

  • Primary model only keeps work queued when the selected model is unavailable.
  • Quota or authentication failures uses the ordered fallbacks only for quota, usage-limit, or authentication failures.
  • Provider availability failures also permits fallback for timeouts, connection failures, provider 5xx responses, or an unavailable provider/model. Validation, schema, and safety failures never trigger fallback.

The equivalent CLI configuration is:

secopsai intelligence bridge configure-models \
  --primary xai/grok-4.6 \
  --fallback google-antigravity/gemini-3.7-flash \
  --fallback kimi/kimi-k2.7-code \
  --fallback-mode quota_auth

The routing file stores model identifiers and policy only. Provider credentials remain owned by OpenCodex or Codex and are never copied into SecOpsAI.

Specialist Orchestrator model snapshots

Mission Control Work uses the same persisted routing through the Specialist Orchestrator. Each durable specialist run captures the primary model, ordered fallbacks, fallback mode, specialist, reviewer, and execution policy when the run is created. A later global model change does not rewrite an existing run. The specialist profile supplies reviewed domain guidance only; it cannot select a provider or grant tools.

Read-only specialist work uses the durable OpenCodex bridge. Approved implementation work runs only in an isolated allowlisted git worktree and is followed by an independent review job. Neither path can autonomously merge, push, deploy, publish, disclose, or mutate external infrastructure.

Autonomous finding and alert triage

Mission Control can use any model in the local OpenCodex catalog, including Kimi K3, Grok, Gemini, or an available Codex model, to review new canonical findings continuously. This includes host detections, Edge findings, supply-chain findings, and high-confidence research candidates produced by registry monitoring. Open Administration → Automation, select the model, then configure Agent finding and alert review.

Research candidate alerts are normalized into canonical findings with source secopsai_research. Package verification remains actionable even when the package is not present in the local repository. Missing local exposure affects the response scope only; it is never evidence that the external package is safe.

The reconciliation runs before every agent-triage cycle and is idempotent. It also backfills older open research alerts, so upgrading Core does not leave pre-existing alerts outside the model review queue.

Operational alerts such as registry timeouts and stale collector cursors are handled by deterministic health checks instead of model opinion. They resolve only after successful coverage recovery, remain visible while degraded, and never become package verdicts.

The modes are:

  • off: no automatic model jobs are created.
  • advisory: the model records a verdict, counterarguments, evidence references, and handling recommendation without changing the finding.
  • guarded: Core may close a false positive or expected behavior only when deterministic SecOpsAI analysis independently supports the same disposition, the model meets the configured confidence and evidence thresholds, and no advisory-backed or strong threat evidence conflicts. The prior state is retained for one-click rollback.

Guarded mode may promote corroborated true positives to in_review. It never publishes, sends disclosure, submits an artifact, executes package code, performs destructive response, or treats missing local exposure as proof that a package is benign.

Complete daily workflow

The daily coordinator links the operational steps that previously required separate clicks or terminal commands. It runs only when its persisted schedule is due and records one durable run with a result for every step:

  1. Run a read-only telemetry and intelligence health preflight.
  2. Run due registry collectors, score new events, retry bounded failures, and recover interrupted collector work.
  3. Apply the configured deterministic candidate-promotion policy. Promotion creates draft research cases only; it is not a maliciousness verdict.
  4. Index and statically process a bounded Artifact Fleet batch without running package code; model execution remains a later queue stage. Backpressure pauses new metadata indexing when the safe scan queue is already above the bounded threshold, preventing unattended queue growth.
  5. Record every alert as feedback and queue eligible findings for the selected model. Unknown outcomes remain active-learning records and are never used as labels.
  6. Collect exact package evidence and run bounded static investigations for eligible high-priority findings.
  7. Under guarded / read_only specialist policy, synchronize completed independent reviews, route evidence-bearing Research Cases once, and create review-only drafts only for cases whose publication review was already approved by a human.
  8. Run the guarded detection-learning replay, holdout, shadow, and canary checks. A failed quality gate produces a proposal or a blocked run; it does not silently change a detector.
  9. Apply bounded storage retention.
  10. Deliver configured operational health alerts with the existing retry and audit controls.

Configure or run the coordinator from Administration → Automation → Daily workflow automation, or use the CLI:

cd /Users/chrixchange/secopsai
.venv/bin/python -m secopsai.cli intelligence autopilot daily status
.venv/bin/python -m secopsai.cli intelligence autopilot daily configure \
  --enabled on --interval-seconds 86400 \
  --max-alert-reviews 25 --max-investigations 5 \
  --max-candidate-cases 25 --auto-promote-candidates on --run-learning on
.venv/bin/python -m secopsai.cli intelligence autopilot daily run

The research worker checks the same schedule on every normal worker cycle, so no second daemon is required. A stale or overlapping run is recovered and marked in the run history rather than started twice. A failed step does not cancel later steps; the cycle is marked degraded and the failed step remains retryable on the next due cycle.

Agents may prepare evidence, triage recommendations, reversible finding changes, specialist reviews, draft cases, review-only editorial drafts, and learning proposals. Specialist-result acceptance, publication-review approval, sandbox submission, disclosure delivery, publishing approved posts, deployment, and unverified detector activation remain explicit approval actions.

The model may propose rule or threshold tuning. Every proposal enters shadow mode. Only an ecosystem threshold that exactly matches a high-confidence deterministic historical replay, includes enough reviewed safe and risky findings, and introduces no known true-positive regression can activate automatically. Rule weights, conditions, and exceptions remain shadow-only.

Closed-loop alert feedback

Every observed alert now contributes to a durable feedback ledger. This includes verified true positives, false positives, expected behavior, unresolved alerts, true-negative baseline observations, and later-discovered false negatives. Unknown outcomes are retained for active learning, but they are not treated as truth. Only evidence-backed or explicitly verified outcomes become training examples.

The learning label is derived separately from the operational outcome:

Outcome Training class Meaning
true_positive positive The alert correctly identified a threat.
false_negative positive A threat was missed; the missed evidence becomes a positive example.
false_positive negative The alert was not a threat.
true_negative negative A reviewed baseline stayed benign.
unknown none Not enough evidence yet; retained for future adjudication.

The feedback ledger is append-only and records the subject, event, outcome, evidence references, feature version, source, confidence, actor, and dedupe key. The existing replay, holdout, shadow, canary, false-negative gate, and rollback controls remain in force. This means every alert improves SecOpsAI's context and active-learning queue immediately, while production detection rules change only after deterministic validation.

Because the ledger is immutable, the number of historical unknown feedback records is not the live adjudication workload. A subject can first be recorded as unknown and later receive a trusted verdict; both records remain for audit. The status API and Mission Control therefore report three separate values:

  • Unknown feedback records: the complete historical audit count.
  • Previously unknown subjects resolved: subjects that later received a trusted, evidence-backed label.
  • Subjects needing evidence: distinct subjects that still have no trusted resolution. This is the actionable adjudication queue.

Blocked or Rejected by guardrails applies to a learning proposal, not to an alert, finding, or job. It means the proposed ranker did not meet an offline quality gate and did not change production detection. Mission Control displays unrounded precision, recall, false-positive rate, true negatives, the configured gate, and the failed guardrail. Repeating a scheduled cycle with the same dataset, algorithm, and policy reuses the prior evaluation rather than creating another identical proposal. Operators should add trustworthy adjudications or improve the ranker; they should not lower a safety threshold merely to force promotion.

Record a verified outcome explicitly when an investigation finishes:

cd /Users/chrixchange/secopsai
.venv/bin/python -m secopsai.cli intelligence autopilot learning feedback \
  --finding-id SCM-EXAMPLE \
  --feedback-outcome true_positive \
  --source operator_verified \
  --confidence 95 \
  --trust-score 95 \
  --evidence-ref EVD-EXAMPLE \
  --actor analyst

Record a missed detection or a reviewed benign baseline with a stable subject key. These records do not require a finding ID:

.venv/bin/python -m secopsai.cli intelligence autopilot learning feedback \
  --subject-key missed-release-2026-01 \
  --feedback-outcome false_negative \
  --source operator_verified \
  --confidence 95 \
  --trust-score 95 \
  --evidence-ref EVD-EXAMPLE \
  --actor analyst

.venv/bin/python -m secopsai.cli intelligence autopilot learning feedback \
  --subject-key baseline-window-2026-01 \
  --feedback-outcome true_negative \
  --source rule_fixture \
  --confidence 100 \
  --trust-score 100 \
  --evidence-ref FIXTURE-EXAMPLE \
  --actor test-harness

Run the learning cycle from Administration → Automation → Detection Learning. The page leads with the current evaluation decision, exact safety metrics, failed guardrails, and the evidence decisions still requiring an operator. Repeated historical evaluations are collapsed in the interface while their immutable records remain available for audit. A model recommendation alone never becomes a label, and no learning cycle can publish, disclose, execute packages, or perform destructive response.

CLI equivalents:

secopsai intelligence autopilot configure --mode guarded --model kimi/k3
secopsai intelligence autopilot run-now
secopsai intelligence autopilot status
secopsai intelligence autopilot runs
secopsai intelligence autopilot tuning
secopsai intelligence autopilot rollback ATR-XXXXXXXXXXXXXXXX
secopsai intelligence autopilot rollback-tuning DTP-XXXXXXXXXXXXXXXX

The background bridge checks for newly changed findings and normalized research-candidate alerts before each queue poll, so a continuously running service provides near-real-time review without adding a second daemon.

The bridge processes durable queued work before discovering another record, performs at most one new deterministic assessment per idle poll, and bypasses OpenCodex's redundant per-command ensure step after the provider health check succeeds. If the user-level bridge is stopped or reinstalled during a model run, interrupted local jobs are requeued immediately and keep their audit history.

Configured on this machine:

  • gpt-5.6-luna (primary)
  • gpt-5.6-sol, gpt-5.6-terra, and gpt-5.4-mini (same OpenAI/Codex fallback pool)
  • kimi/kimi-k2.7-code
  • xai/grok-4.5
  • google-antigravity/gemini-3.5-flash-low
  • plus the rest of your OpenCodex catalog

Choose a model

List models:

cd /Users/chrixchange/secopsai
.venv/bin/python -m secopsai.cli intelligence bridge models

Run one job on a selected model:

.venv/bin/python -m secopsai.cli intelligence bridge run --once   --model kimi/kimi-k2.7-code   --db-path data/openclaw/findings/openclaw_soc.db

Set a default model for the bridge service:

export SECOPSAI_BRIDGE_MODEL=xai/grok-4.5
export SECOPSAI_BRIDGE_FALLBACK_MODELS=gpt-5.6-sol,gpt-5.6-terra,gpt-5.4-mini,google-antigravity/gemini-3.5-flash-low,kimi/kimi-k2.7-code,xai/grok-4.5
.venv/bin/python -m secopsai.cli intelligence bridge service stop
.venv/bin/python -m secopsai.cli intelligence bridge service start

The operator-selected model is persisted and used exclusively. Health probes and jobs do not walk the Codex fallback pool unless SECOPSAI_BRIDGE_FALLBACK_MODELS is set. If the selected model is at a usage limit, SecOpsAI reports that model as unavailable instead of spending other providers' quotas.

Mission Control model picker: the local bridge module in the dashboard lists the same catalog as a dropdown. Pick a model there and use Process next job; failed jobs can be requeued from the jobs table and retried on another model without recreating the pipeline.

Requeue a failed job after switching models:

.venv/bin/python -m secopsai.cli intelligence jobs requeue AIJ-...   --db-path data/openclaw/findings/openclaw_soc.db

OpenCodex must be healthy:

opencodex status
opencodex health --json

Local Codex bridge

The bridge accepts only named SecOpsAI actions. It does not expose an arbitrary prompt or shell endpoint. Core builds a minimized context, the bridge runs Codex in an ephemeral read-only sandbox, and the structured result returns to the durable job record for human review.

Check the local installation and ChatGPT sign-in:

cd /Users/chrixchange/secopsai
.venv/bin/python -m secopsai.cli intelligence bridge doctor

List the approved actions:

.venv/bin/python -m secopsai.cli intelligence actions

Queue an explanation for one finding:

.venv/bin/python -m secopsai.cli intelligence enqueue \
  --action explain_finding \
  --target-id FND-EXAMPLE

Process one queued request:

.venv/bin/python -m secopsai.cli intelligence bridge run --once

Install the bridge as a user-level background service:

.venv/bin/python -m secopsai.cli intelligence bridge service install
.venv/bin/python -m secopsai.cli intelligence bridge service status
.venv/bin/python -m secopsai.cli intelligence bridge service logs

The installer creates ~/Library/LaunchAgents/ai.secopsai.codex-bridge.plist on macOS or ~/.config/systemd/user/secopsai-codex-bridge.service on Linux. It does not copy or persist a ChatGPT credential. Codex continues to own its local authentication state.

Automated research investigations

Mission Control's Run Investigation Pipeline action uses the same durable bridge queue. Core first performs bounded package collection and deterministic static analysis, then creates three read-only jobs: case analysis, analyst brief, and publication-safety review. The bridge receives normalized case context, hashes, manifests, static indicators, and comparison results. It never receives the quarantined artifact, raw registry responses, local quarantine paths, secrets, or customer telemetry.

Bridge results return to Core as review proposals. They do not become evidence until an operator accepts them, and model-generated text is stored only as an analyst-reviewed case note. A bridge failure leaves the pipeline retryable; retries create a new revision and preserve the previous attempt for audit. Verdicts, sandbox submission, disclosure delivery, and publication remain independent human approvals.

Universal MCP Gateway

The provider-neutral gateway exposes nine read-only tools:

  • workspace summary
  • list and get findings
  • list assets and recent asset changes
  • list and get research cases
  • build a non-persisting evidence matrix
  • check publication readiness

The MCP server never runs a model. ChatGPT, Codex, Claude-compatible clients, VS Code, Cursor-compatible clients, or another MCP host may provide the reasoning and call the same tools. The gateway verifies a SecOpsAI OAuth access token, checks issuer, audience, expiry, signature, approved client, tenant, workspace, and per-tool scope, then calls Core with a server-side read credential. Provider tokens are never accepted as SecOpsAI workspace credentials.

Local protocol test

cd /Users/chrixchange/secopsai/apps/secopsai-mcp
npm ci --ignore-scripts
npm test
npm audit --audit-level=moderate

The complete deployment, client-profile, stdio, audit, and revocation guide is in Universal MCP Gateway.

Production OAuth requirements

Use an established OAuth 2.1 provider such as Auth0, Okta, Cognito, or Stytch. Configure authorization-code flow with PKCE S256, a token audience equal to SECOPSAI_MCP_RESOURCE, short-lived signed access tokens, the four SecOpsAI read scopes, and a JWKS endpoint. Do not build a custom password or token issuer inside the MCP server.

Required scopes:

  • secopsai.workspace.read
  • secopsai.findings.read
  • secopsai.assets.read
  • secopsai.research.read

The primary render.yaml deliberately does not provision this service. This keeps ordinary Core and research-worker Blueprint syncs independent from optional OAuth configuration and avoids an unused paid service. When the MCP Gateway is ready for a pilot, create one web service with:

  • Repository: Techris93/secopsai
  • Root directory: apps/secopsai-mcp
  • Runtime: Node
  • Build command: npm ci --ignore-scripts
  • Start command: npm start
  • Health path: /readyz
  • Instance: Starter or higher for a reliable pilot; free is acceptable only for temporary development

Required service values include:

Variable Purpose
SECOPSAI_MCP_AUTHORIZATION_SERVER OAuth issuer base URL advertised to every MCP client
SECOPSAI_MCP_ISSUER Exact expected JWT iss value
SECOPSAI_MCP_JWKS_URL Provider signing-key endpoint
SECOPSAI_CORE_READ_TOKEN Same server-side read credential configured on Core

Also set:

Variable Value
SECOPSAI_MCP_ENVIRONMENT production
SECOPSAI_MCP_RESOURCE Exact public service origin, without /mcp
SECOPSAI_MCP_AUDIENCE Same exact public service origin
SECOPSAI_MCP_ALLOWED_HOSTS Public service hostname only
SECOPSAI_MCP_ALLOWED_ORIGINS Explicit comma-separated browser origins; no default and no wildcard
SECOPSAI_MCP_ALLOWED_CLIENT_IDS Explicit OAuth client IDs approved for the gateway
SECOPSAI_MCP_ORGANIZATION_ID Exact SecOpsAI tenant required in the token organization claim
SECOPSAI_MCP_WORKSPACE_ID Exact SecOpsAI workspace required in the token workspace claim
SECOPSAI_MCP_CLIENTS_JSON Optional display-name/profile mapping for approved clients
SECOPSAI_MCP_DOCUMENTATION_URL https://docs.secopsai.dev/intelligence-integrations/
SECOPSAI_CORE_API_URL https://core.secopsai.dev

Set the production MCP resource and audience to the exact public MCP service origin. The read-only Core upstream is the separate https://core.secopsai.dev origin.

After the opt-in deployment, verify:

curl -sS https://mcp.secopsai.dev/readyz
curl -sS https://mcp.secopsai.dev/.well-known/oauth-protected-resource
curl -sS https://mcp.secopsai.dev/.well-known/secopsai-mcp

Register https://mcp.secopsai.dev/mcp in one approved client, complete OAuth, and test secopsai_workspace_summary before enabling a wider pilot group. ChatGPT remains a supported client profile, not a separate server.

The current hosted Core is a single-tenant pilot deployment. Limit OAuth access to the same invited SecOpsAI organization. Do not use this deployment for multiple unrelated customers until Core enforces organization membership on every query.

Security boundary

  • Every MCP tool is read-only and declares its exact OAuth scope.
  • Core read, ingest, and intelligence credentials are different.
  • The local bridge runs only allowlisted actions and structured output.
  • Raw telemetry and artifact contents are removed before context construction.
  • Package metadata and finding text are treated as untrusted data, not model instructions.
  • Model output is advisory. It cannot resolve a finding, approve disclosure, submit a sandbox artifact, or publish research.