The AI Command Center is the single console where you run SITEY’s AI, watch what it is doing, and control what it is allowed to do. From one page you can give the AI a goal in plain language and follow every step it takes, score the real-world risk of a host or a finding, run a saved security procedure, read the day’s summary, check how many tokens and dollars the AI has consumed, and switch individual AI capabilities on or off per user. It is the operator’s seat for an autonomous system.
The problem
Autonomous security tooling fails for two opposite reasons. Either it does too little, every AI feature lives on its own page, nobody knows which ones are turned on, and the team quietly stops using them. Or it does too much. It acts on production systems and nobody can reconstruct why.
Without a command center, the analyst’s day looks like this. Open the triage page, run a batch. Open the remediation page, generate a plan. Open a third page to see whether the patch was approved. Copy the numbers into a spreadsheet for the Monday meeting. Nobody can answer “what did the AI actually do last week, how much did it cost, and who authorised it” without reading database rows.
And when a question spans several of those pages, such as “which of our internet-facing hosts has both a known-exploited CVE and a ten-year-old unpatched service”, there is no place to ask it. Somebody writes a query by hand.
How it works
One console reads every AI signal
Opening the page loads a single dashboard call that returns your active and critical vulnerability counts, AI requests and tokens consumed in the last 24 hours, the estimated cost in USD for that period, weekly request volume, how many orchestrator sessions ran this week and what share of them reached a final answer, how many playbooks are active and how often they ran, and which model is currently in use.
Read that share as a completion rate rather than a quality score: a run that stops because it reached its step limit is counted as not completed.
The same response carries the on/off state of each AI capability, so the operator sees the configuration and the consumption side by side.
You give a goal; the orchestrator works in visible steps
Type an objective, for example, analyse the critical vulnerabilities and produce a remediation plan, and the orchestrator runs an observe/think/act/verify loop for up to fifteen steps (eight by default). It is not a chatbot: it calls real tools against your database. It can search and filter vulnerabilities, pull a single finding’s full detail, look up asset information by IP or hostname, calculate a risk score, search the knowledge base, run triage, correlate related threats across host, CVE and port, generate a report, change a finding’s status, create and assign a task, build a remediation plan, and hand a sub-task to one of four specialist agents (triage, remediation, recon, report). Every step is rendered in the UI with its phase, the tool it chose, the arguments it passed and the result it got back, and the whole session is stored, so you can reopen it later from the session list, which shows your own twenty most recent runs.
Destructive actions stop at an approval gate
When the orchestrator decides a machine needs patching, it does not patch it.
- Patch job created, not applied
It creates a patch job in pending approval status, with the vulnerability, CVE, classification category and confidence recorded on the job.
- Blast radius guard on multi-host actions
If it targets multiple machines at once, agents that are inactive, deleted, or explicitly exempt from autonomy are dropped from the target list.
- All-or-nothing ceiling check
If the remaining count exceeds the ceiling, which is set by an environment variable on your server and defaults to one machine, no jobs are created at all rather than a partial rollout.
The operator raises that ceiling deliberately, in the server configuration, once they trust the behaviour.
Two of the orchestrator’s tools are not behind this gate: changing a finding’s status and creating a task are written to the database directly. Both are recorded in the session steps and the activity log, so you can see afterwards what changed and why.
Risk is scored in context, not copied from CVSS
The risk tab takes a host IP or a finding and returns a 0-100 score assembled from six weighted components, each of which is shown separately alongside the human-readable factors that drove it.
| Component | Weight | What it reads |
|---|---|---|
| CVSS base | 25% | The published score, or the severity label if no score exists |
| Exploit availability | 20% | Matches the CVE and title against a list of known-exploited families such as Log4Shell, EternalBlue, ProxyLogon, Zerologon and MOVEit. This list ships with the platform and is not a live exploit feed |
| Asset exposure | 20% | Whether the port is on the platform’s list of commonly internet-exposed ports, whether the service is on its critical-service list, and how many open findings already sit on that host |
| Environment | 15% | The host operating system, whether its agent is currently online, and the finding’s severity label |
| Temporal | 10% | Age of the CVE. A flaw three years old or more scores highest, and a CVE from the current year also scores up |
| Business impact | 10% | Severity label plus vulnerability class, weighted up for remote code execution, injection, auth bypass and privilege escalation |
The severity label still feeds several of those components, so the score moves with severity rather than replacing it. What reorders your queue is exposure, exploit maturity and age. The result carries a recommended timescale with it: act within 24 hours above 80, within 72 hours above 60, plan within two weeks above 40, and handle at the next maintenance window below that. Scoring a host rolls its findings up with the worst one weighted most heavily, plus a density penalty, and returns the severity breakdown and the five highest-scoring findings on that machine.
Repeated procedures become playbooks
A playbook is an ordered list of steps that runs on demand from this page. Steps can perform AI analysis, advanced risk scoring, triage, smart remediation classification, report generation or a database search. Five procedures ship pre-built:
Each step’s output is passed into the next step’s context, execution stops at the first failing step, and every run is stored with per-step status so you can see exactly where a procedure broke.
What you can do
Ask a free-text security question that spans hosts, CVEs, assets and tasks, and get an answer built from tool calls against your own data rather than from a language model’s memory.
See every step, tool call and tool result the AI produced, and reopen your recent runs from the session list.
Score any host by IP and get its total risk, severity breakdown, contributing factors and worst five findings.
Score an individual finding and see the six components that produced the number, so you can argue with it.
Run a multi-step security procedure on demand and read the per-step outcome.
Create a new playbook from your own step list, or deactivate one you no longer want available.
Generate a remediation plan for a single finding that lands in the approval queue as a patch job.
Read a basic daily statistics summary without consuming any AI budget at all, then generate the AI-written analysis on top of it only when you want it, and, where SMTP is configured on your server, email that summary to yourself or a colleague.
Requests, tokens and estimated USD cost for the last 24 hours and the last week, with per-request cost derived from a model price table that ships with the platform. A model missing from that table is costed at a default rate, so treat the figure as an estimate and reconcile it against your provider’s own invoice.
Review the AI activity log filtered by activity type, with token counts and durations, plus a rolling summary of the last N days grouped by activity.
As an admin, enable or disable each AI capability for one user or for every user at once. Switching off the orchestrator, auto-remediation, playbooks, risk scoring or the command center itself makes the matching API endpoint reject the request outright rather than merely hiding the button, and auto-remediation is off by default.
Tune model behaviour per user for the AI assistant and triage: temperature, token ceiling and whether knowledge-base retrieval is used. The orchestrator itself runs on a fixed prompt and is bounded by the per-request step limit.
As an admin, index your completed remediation history into the knowledge base in bulk, so that what actually worked on your estate, including the failures and the lessons recorded against them, informs future answers.
Who it is for
Use it as the place to ask a question that crosses several data sets and get a traceable answer.
Use the risk tab to decide which of thirty pending findings on a server actually justifies a maintenance window this week.
Build the playbooks and set the blast-radius ceiling.
Read the weekly completion rate, the cost figures and the activity log, the evidence that an autonomous system is being supervised.
Use the stored sessions and activity log as a searchable record of who asked for what and what the system changed.
These are application records held in your own database. SITEY does not present them as a tamper-evident audit chain.
Why it matters
The cost of an unsupervised AI in security operations is not the token bill; it is the incident it causes and cannot explain.
This module is what makes autonomy defensible. Every orchestrator run is stored with its full step list, every AI call is logged with its model, token count and cost, and every patch job the AI proposes waits in an approval queue with the reasoning attached. When an auditor asks how a change was authorised, the answer is a stored record rather than a recollection.
On the time side, the saving is in question-answering. A cross-referencing question that an analyst would answer by exporting three lists and comparing them by hand is a single sentence here, and the result includes the reasoning. Contextual risk scoring cuts the queue further.
CVSS score alone
- A 9.8 on an offline internal workstation ranks at the top of the queue
- A 7.5 on an internet-facing database server with a known-exploited CVE ranks below it
Contextual risk score
- Exposure, exploit maturity and vulnerability age are weighted in
- The internet-facing database with the known-exploited CVE moves to the top: it is the one that will actually hurt you
Because SITEY runs inside your own infrastructure, none of this telemetry, your hosts, your findings, your remediation history, leaves your network. You connect your own key for an OpenAI-compatible model endpoint, and the consumption you see on this page is the consumption you are paying for.
Works with
The orchestrator and playbooks both call triage as a step; the command center is where you trigger it across the whole open backlog.
Plans generated here become patch jobs there.
Every patch job the AI creates from this page arrives as pending approval.
The cost and token figures summarised here are recorded per request.
The full, filterable history behind the activity summary on this page.
Frequently asked questions
Can the AI change my production systems on its own?
It cannot patch them on its own. Remediation work is created as a patch job in pending-approval status and waits for a human. If the AI targets several machines in one action, a guard removes ineligible agents and refuses the entire batch if the target count exceeds the configured ceiling, which defaults to a single machine. The orchestrator can update a finding’s status and create tasks directly, with no approval step in front of those two actions. They are recorded in the session and the activity log so you can review them, and you can switch the orchestrator off entirely if that is not acceptable in your environment.
What if we do not want some of these capabilities enabled?
Each capability is a separate switch, and only an administrator can change them, for one user or for everyone at once. Switching off the orchestrator, auto-remediation, playbooks, risk scoring or the command center itself makes the corresponding API endpoint reject the call rather than merely hiding the button, so the control holds even if someone calls the API directly. Auto-remediation is off by default.
How do we keep AI costs under control?
Every AI call is logged with its model, token counts and an estimated cost taken from a price table built into the platform, and the dashboard shows 24-hour requests, tokens and dollars plus the weekly request volume. This is visibility, not a hard spending cap: the platform does not cut off requests at a budget threshold, so set any hard limit on your model provider’s own billing controls. What the platform does give you is cheaper defaults. The basic daily summary is deliberately built from database queries alone, so the statistics you look at every morning cost nothing, and the AI-written analysis runs only when you press the button. Orchestrator runs are bounded by a step limit you set per request, up to fifteen.
Does the AI learn from our environment?
Yes, from your remediation history specifically. Completed remediation records, successful and failed, can be indexed in bulk by an administrator into the knowledge base, carrying the vulnerability name, CVE, risk level, category, software, target host and operating system, the action taken, the outcome and any lessons recorded against it. Records already indexed and unchanged are skipped on a re-run, so repeating the bulk index does not re-embed the same history. The orchestrator can then search that knowledge base as one of its tools, so answers reflect what has actually worked on your estate.
The AI Command Center is included in every SITEY deployment. There is no separate AI tier and no per-seat AI charge. You install the platform on your own servers, connect your own OpenAI-compatible model key, and decide capability by capability how much autonomy to grant. See pricing and start your deployment.