Straight answers about how NurpSuite works.

NurpSuite is delivered as SaaS on Vercel's serverless platform, backed by a managed Postgres database (Neon). Customers who need their data to stay in their own boundary can use the enclave deployment, where the same application runs inside the customer's environment behind their proxy and authenticates operators with DoD PKI / CAC certificates.

The application is a modular monolith: one Next.js 16 codebase with clearly separated modules, deployed as independently scaling serverless functions. Each API route, agent and scheduled job runs as its own function, so heavy work (an agent run, an integration sync) never competes with the console for resources.

• Frontend and server: Next.js 16 (App Router), React 19, TypeScript
• Data: Postgres (Neon) through Drizzle ORM
• Identity: Better Auth, with a CAC / PKI plugin for enclave deployments
• AI: Vercel AI SDK through the Vercel AI Gateway
• Detection logic: native Sigma engine that emits KQL, SPL, EQL and FQL

The compute tier scales horizontally and automatically: every request and job runs in a stateless serverless function, so more load means more concurrent instances rather than a bigger server. The database is serverless Postgres with autoscaling compute, connection pooling, and indexes designed for high-volume alert and ticket queries.

NurpSuite is not a log lake, so it does not ingest raw events. Your SIEM keeps doing that. NurpSuite pulls alerts and incidents, which are orders of magnitude fewer than raw events. If ingestion doubles overnight, the SIEM absorbs the raw volume, and NurpSuite sees more alerts, which the serverless tier absorbs by running more instances.

Tenant capacity is set by the database, not by the application. All tenants share one deployment and are separated by subscriber scope. We size the database per deployment and publish measured throughput for your environment during the pilot rather than quote a generic EPS figure.

Operational data (alerts, tickets, detections, Digital Twin, assessments, audit trail) lives in Postgres. Raw telemetry stays in your SIEM, the system of record. NurpSuite keeps the alert, the investigation and the decision, and links back to the source event.

Retention is set per deployment. Because investigations, tickets, assessment history and resilience snapshots are stored as records rather than raw logs, historical investigations stay searchable long after the SIEM has aged out the underlying events. When the raw event is still needed, the analyst pivots back to the SIEM from the linked record.

By default, tenancy is logical. Every subscriber-owned record carries a subscriber scope, and every query is filtered by it on the server. Tenant scope comes from the authenticated session, never from client input.

Physical separation is available through the enclave deployment: a dedicated instance and database inside the customer boundary.

Integration credentials are encrypted per record with AES-256-GCM before they are stored. Per-tenant encryption keys are not implemented today. All tenants in a shared deployment use one platform key, and customers who need key isolation should choose the dedicated deployment.

Stateless: the web console, every API route, all AI agents, the Sigma conversion engine, integration sync and the scheduled assessment jobs. Any instance can serve any request.

Stateful: the Postgres database, the only place state lives. That includes sessions, the Digital Twin, agent run history, integration cursors (the high-water mark for each connector) and the audit trail. A job interrupted mid-run resumes from its last persisted cursor instead of losing its place.

Through the Azure Resource Manager API for Microsoft.SecurityInsights, in both directions:

• Pull: incidents are fetched on a schedule and paged, with a durable high-water timestamp as the cursor, so no incident is missed or double-counted across runs.
• Push: approved detections are deployed as Scheduled analytics rules with a deterministic rule ID, so re-pushing a rule updates it instead of creating a duplicate.
• Webhook: an authenticated ingest endpoint accepts near-real-time pushes (for example from a Sentinel automation rule or Logic App) for teams that do not want to wait for the next sync.

Microsoft Sentinel is supported natively for incident pull and analytics-rule push. Because Sentinel aggregates alerts from the Defender family, alerts from Defender for Endpoint, Defender XDR, Defender for Identity, Defender for Cloud Apps, Defender for Cloud and Entra ID Protection reach NurpSuite through their Sentinel data connectors today.

Direct connectors to the Defender XDR and Microsoft Graph Security APIs, and to Intune for device context, are on the roadmap. We state this plainly because it affects response actions (see below).

Least privilege, scoped to the Sentinel workspace. Global Administrator is never required.

• Read-only (alerts and incidents only): Microsoft Sentinel Reader on the workspace.
• Detection push: Microsoft Sentinel Contributor on the workspace, so approved analytics rules can be written.
• Credentials: an Entra app registration (service principal) scoped to the workspace resource group, stored encrypted and never shown in the console after entry.

Yes. Sentinel incidents arriving through sync or the webhook go into triage, alert scoring and ticketing, and can start an orchestrator run: detection, validation, hunt, coverage and CTI correlation, followed by an executive summary. A Sentinel automation rule pointed at the ingest webhook starts this within seconds of the incident being created.

Today NurpSuite pushes detection content (analytics rules) into Sentinel and creates and tracks incident tickets in its own case system.

Direct containment actions (isolate an endpoint in Defender, disable an account in Entra ID) are not executed by NurpSuite today. The platform prepares the recommended action, its blast radius against the Digital Twin, and the approval record. A human then executes it in the Microsoft console or through an existing Sentinel playbook. Native, approval-gated execution through Defender and Graph APIs is on the roadmap.

Through the orchestrator and the database, not through free-form conversation. The orchestrator runs the specialist agents as ordered stages (detection, validation, hunt, coverage, CTI, then an executive agent that summarises). Each stage writes a typed, structured result to Postgres, and the next stage reads the persisted findings it needs.

This is deliberate. Agents never pass unvalidated text to each other, every handoff is inspectable after the fact, and a failed stage is recorded as a failure instead of quietly corrupting the next one.

Security Copilot is an assistant. An analyst asks a question and it answers from Microsoft data. NurpSuite agents are operational workers. They run on a schedule or on a trigger, act on the whole detection estate, and leave behind durable artefacts: a validated rule, a coverage gap, a hunt finding, a ticket, an executive brief.

• Multi-SIEM: the same agents work across Sentinel, Splunk, Elastic and CrowdStrike, with one Sigma source of truth.
• Business context: every finding is scored against the Digital Twin, so output is ranked by business impact rather than by severity alone.
• Grounded, not generative: the agents reason over records already in the platform, and several key steps (validation verdicts, triage scoring) use no model at all.
• Outcomes, not chat: results persist, are approved by humans and are measured over time.

By limiting what the model is allowed to decide.

• Grounding: agents receive only records from the platform (rules, alerts, techniques, twin data), never an open-ended prompt.
• Structured output: model responses are validated against strict schemas. Anything that fails validation is rejected, not repaired by guesswork.
• Deterministic cores: detection validation and low-risk triage scoring are computed deterministically with no model in the path.
• Reference checks: ATT&CK IDs, rule keys and asset names in model output are checked against the real catalogue before they are saved.
• Human approval: detections, suppressions and response actions need an authorised human before they take effect.
• No invented figures: diagram import extracts topology only. It never invents business values such as revenue or user counts.

Only the minimum context a task needs: the rule under review, relevant alert metadata, technique references, summarised twin context for impact, and the analyst question. Integration credentials, passwords and session data are never sent. Per-tenant scope is enforced before context is assembled, so one tenant data never enters another tenant prompt.

Low-risk alert triage runs entirely in-process against the database, so that alert content never leaves the environment at all.

NurpSuite calls models through the Vercel AI Gateway, a provider-agnostic layer. The default is Anthropic Claude Sonnet. Because the gateway abstracts the provider, OpenAI, Google and other hosted models can be selected by configuration without code changes. Azure OpenAI and self-hosted, OpenAI-compatible endpoints can be wired in for customers who need the model inside their own tenancy.

Yes, in dedicated and enclave deployments. The model is a configuration setting. A customer can point NurpSuite at their own Azure OpenAI deployment or a self-hosted, OpenAI-compatible endpoint so prompts and completions never leave their boundary. Features that need no model (validation, triage scoring, Sigma conversion) work unchanged with no model configured.

System prompts are defined in server code, not in the browser or the database, so users cannot read or alter them. Model calls run only on the server, behind authentication and role checks. Untrusted content (alert fields, uploaded diagrams) is passed as clearly delimited data, not as instructions. Output is schema-validated, so an injected instruction cannot turn into an action. Nothing the model returns is executed, and state-changing steps still need human approval.

Recommendations are a deliberate mix, and each is labelled in the product:

• Deterministic: detection validation verdicts, triage scores, ATT&CK coverage percentages and business-impact tiers. The same inputs always produce the same answer.
• Probabilistic, then constrained: rule drafting, hunt hypotheses and narrative summaries use a model, but its output is schema-validated, checked against real references and gated by a human before it takes effect.

Six specialist agents, each responsible for one part of security operations, plus an orchestrator that coordinates them. Every agent can be run on its own from its console, or together as one coordinated sweep.

• Detection Engineer: tunes and improves existing detections.
• Detection Validator: proves which ATT&CK techniques your detections actually catch.
• Threat Hunter: looks for activity that triage has not already cleared.
• Coverage Agent: finds detection gaps and degraded telemetry.
• CTI Agent: connects threat actors to your real exposure.
• Executive Agent: turns the posture into a leadership briefing.

They share one design, which is what makes them safe to run unattended and easy to coordinate.

• Grounded inputs: each agent reads only records already in the platform (rules, alerts, techniques, coverage, tickets, Digital Twin), scoped to the tenant on the server.
• Bounded runs: model-driven agents work through a small set of read and file tools, with a hard limit of 8 reasoning steps and at most 6 items filed per run, so a bad run cannot flood a queue.
• Validated output: everything an agent files is checked against a strict schema and against real references before it is saved.
• Proposals, not actions: agents file findings and recommendations into review queues. Nothing changes a detection, closes an alert or touches a customer system without an authorised human.
• A common contract: every agent reports live progress the same way and returns what it filed, what it skipped and why. That shared shape is what lets the orchestrator run any of them without special handling.

It reviews how production detections are actually performing (false-positive rates, noisy sources, match volume) and proposes specific improvements.

Each recommendation states the observation, the grounded analysis behind it, the effect on ATT&CK coverage, the concrete change (for example, a scoped exclusion for one scanner asset) and the projected noise reduction. Recommendations land in the analyst tuning queue. A detection engineer approves or rejects each one, and approved changes are applied through the normal detection workflow.

The validator is deliberately not an LLM. It scores a curated validation library against the current detection set deterministically, so the same posture always produces the same verdicts, which is what a control-validation function has to guarantee.

The validator only reports. Fixing a blind spot (writing or enabling a detection) stays human detection-engineering work.

• Detected: a production rule maps to the technique, is enabled, and has actually fired.
• Partial: a rule maps to the technique, but coverage is unproven (disabled, lossy or never fired).
• Blocked: the only mapping is a rule that cannot observe the procedure per event, so coverage exists on paper only.
• Missed: no production rule maps to the technique at all. A true blind spot.

It looks across the last 30 days of alert activity, excluding anything already adjudicated as benign or a false positive, since a hunt is about what triage has not cleared. It pays particular attention to techniques the validator marked as blind spots.

Each hunt finding is filed as a lead with a hypothesis, the supporting evidence and a severity. An analyst decides whether to pursue it, dismiss it or promote it to an investigation.

It compares nominal coverage (what your rules claim to detect) with effective coverage (what your telemetry can actually feed) per ATT&CK tactic, alongside the health of each telemetry source.

• Telemetry degradation: effective coverage has fallen behind nominal, usually because a data source went quiet or lost fields.
• Coverage gaps: a tactic sits below 50% nominal coverage.
• Control effectiveness: a security control is not delivering the coverage expected of it.

It connects threat intelligence to your own environment. For each relevant threat actor it compares the actor's known techniques against your technique coverage, current threat exposure and open tickets, and files a correlation only when the overlap actually matters. The result reads as "this actor uses these techniques, and these are the ones you cannot currently see", rather than a generic intel feed.

Before the model runs, NurpSuite builds a fixed posture snapshot from the same live queries the console uses: incidents, threat activity, coverage, telemetry health, adversary intel, response times and per-tenant health. The model is given that digest and asked only to synthesise it.

It produces either a short SITREP or a longer executive report, for the whole program or a single subscriber. Each includes an overall risk level and a set of concrete leadership actions. Because the figures come from the digest rather than the model, the briefing never diverges from what operators see on the dashboards.

AI triage is a separate machine-learning model, not one of the orchestrated agents. It scores incoming low-risk alerts in-process against the database, so alert content never leaves the environment. Inside its operating envelope it proposes benign closures, which an analyst approves or rejects. Anything outside the envelope is handed to a human. It lives under Response Automation, in the AI triage tab.

The orchestrator runs them as a sequential pipeline in a fixed order, so each agent reasons over the state the previous agents have just updated. The orchestrator itself is not an LLM. Its job is control flow, not reasoning.

• 1. Detection Engineer tunes the detection set first, so everything downstream works from the current rules.
• 2. Detection Validator re-scores which techniques are detected, partial, blocked or missed against those rules.
• 3. Threat Hunter hunts against the blind spots the validator just refreshed, where an attacker is least likely to be caught.
• 4. Coverage Agent checks whether telemetry can actually support the coverage the rules claim.
• 5. CTI Agent maps active threat actors onto the gaps the earlier stages surfaced.
• 6. Executive Agent closes the sweep with a SITREP that already reflects everything the sweep found.

Because each stage depends on the one before it. A hunt run before validation would hunt against yesterday's blind spots. An executive summary run in parallel would miss the findings of the sweep it is meant to summarise.

Sequencing also spreads load on the AI Gateway, instead of several multi-step agents bursting at once.

Through the database, not through conversation. Each agent writes typed, validated records (tuning recommendations, validation runs, hunt leads, coverage findings, CTI correlations), and the next agent reads the persisted records it needs. No agent ever receives another agent's free-form text as an instruction, so an error in one stage cannot be amplified by the next.

Each stage runs in isolation. If an agent fails (for example, the model is rate-limited or times out), the failure is recorded on that stage with a plain reason and the pipeline continues with the next stage.

A sweep ends as complete (every stage ran), partial (some stages failed) or failed (nothing succeeded). The run record shows exactly which stage failed and why, so a partial result is never mistaken for a full one.

On demand from the Orchestrator, where an operator chooses which agents to include and whether to finish with an executive summary, or automatically through scheduled assessments. Progress streams live stage by stage.

Every sweep is saved as a run record that snapshots what each agent proposed at that moment, including the items it considered but skipped and why. The record stays accurate even after the queues have been worked and items approved or dismissed.

People do. A coordinated sweep produces more proposals, not more autonomous action. Tuning changes, hunt escalations, coverage remediations and triage closures each wait in their own review queue for an authorised person, subject to role-based permissions. The Executive Agent's leadership actions are recommendations for people to decide on, not tasks the platform carries out.

In three ways, which can be combined:

• Diagram import: upload a Visio (.vsdx) or PDF architecture diagram. AI proposes the topology, and an operator reviews and approves it before anything is saved.
• Bulk import: services, assets and dependencies can be loaded from a CMDB or asset inventory export.
• Manual mapping: a guided editor for adding services, dependencies, criticality, user counts and cost of downtime.
• Observed activity: assets referenced in real alerts are linked to the twin, so gaps show up where the telemetry is.

Continuously for what the platform observes. New alerts and asset references update the twin as they arrive through integration sync. Structural changes (new services, re-mapped dependencies) are applied when an import or edit is approved. Scheduled resilience assessments re-evaluate the twin on the cadence you set and keep a history, so drift is visible over time.

NurpSuite shows missing data instead of guessing. Services without an owner, criticality, user count or cost of downtime are flagged as gaps, and impact figures derived from them are labelled as estimated or unavailable, never presented as fact. Assets that appear in alerts but not in the twin are raised as unmapped so they can be added. The twin is useful on day one and becomes more precise as the gaps close.

Impact is computed from the twin dependency graph, not assigned by hand:

• Blast radius: starting from the affected asset, NurpSuite walks the dependency graph to find every downstream service and application that would degrade.
• Exposure: each affected service contributes its criticality, user count and cost of downtime per hour.
• Duration: estimated downtime is based on recovery readiness (backup coverage, redundancy, documented recovery order).
• Tiering: the result is placed in a clear exposure tier with rounded figures and a plain-language "why this matters", so executives see a range they can act on rather than false precision.
• Traceability: every figure can be traced to the twin records it came from.

A CMDB records what you own. The Digital Twin models how the business fails. It holds dependencies, criticality and cost of downtime, and connects them to live security data: which detections cover each service, which alerts touch it and which ATT&CK techniques threaten it. It also supports simulation ("what breaks if this is compromised?") and scheduled resilience assessments. A CMDB can feed the twin, but it cannot answer those questions itself.

Sigma is the native format and the single source of truth. NurpSuite parses Sigma directly and converts it to each connected platform language: KQL for Sentinel, SPL for Splunk, EQL for Elastic and FQL for CrowdStrike. Existing rules already deployed in a connected platform are read back so current coverage is counted, and conversions that lose meaning in a target language are flagged as lossy rather than deployed silently.

Primarily from rule metadata. Sigma ATT&CK tags are parsed and resolved against the MITRE catalogue. The detection agent can suggest mappings for untagged rules, but suggestions are checked against real technique IDs and need detection-engineer approval before they count toward coverage. Analysts can correct any mapping manually.

From outcomes, not rule counts: true-positive and false-positive rates from analyst dispositions, whether the rule has ever fired, validation status (detected, partial, blocked), conversion fidelity across target platforms, and the alert volume and suppression load it creates. Rules that never fire, or fire only as noise, are surfaced for review.

The coverage agent compares validated detections against the ATT&CK matrix and against the techniques most relevant to you, weighted by active threat intelligence (CTI) and by the Digital Twin services those techniques would reach. A gap is a technique that matters to your business and has no proven detection, ranked by exposure, not simply every empty cell in the matrix.

Technique IDs are normalised to canonical form (sub-techniques resolved to their parents for roll-up) and each rule-to-technique pair is stored once. Coverage is counted per technique, not per rule, so ten rules on one technique count as one covered technique with depth, not ten. Deterministic rule IDs on push also prevent the same rule appearing twice in a target SIEM.

The validation agent runs a curated library of adversary-procedure tests against the detection set and gives each ATT&CK technique a verdict:

• Detected: a production rule maps to the technique, its Sigma form is enabled, and it has actually fired.
• Partial: a rule maps to the technique, but coverage is unproven (disabled, lossy conversion, or never fired).
• Blocked: the only mapping is a rule type that structurally cannot observe the procedure. It counts on paper but offers no real protection.
• Missed: no rule maps to the technique at all.

Yes, as the test library. Validation tests are modelled on Atomic Red Team procedures and keyed by ATT&CK technique. In the SaaS deployment they are scored against real detection and alert signals rather than executed on endpoints. Customers who run Atomic Red Team in their own lab can feed the results back, so live detonation evidence strengthens the verdict.

By default, NurpSuite detonates nothing. Validation is deterministic and read-only. It evaluates existing detections and signals, with no model and no randomness in the path, so it can run against production at any time with zero operational risk. Any live emulation happens in customer-controlled test environments, under the customer change control.

As the share of relevant techniques with a "detected" verdict, tracked over time, alongside true-positive rate and mean time to detect from real incidents. Because verdicts are deterministic, a change in the number reflects a real change in posture, not noise in the measurement.

Everything NurpSuite holds (alerts, incidents, the Digital Twin, detection history and CTI indicators, including OpenCTI feeds) plus the connected platforms it syncs with: Microsoft Sentinel, Splunk, Elastic and CrowdStrike.

Both. Hunts run as part of scheduled orchestration and when new threat intelligence arrives, and an analyst can launch a focused hunt on demand from the console.

By the product of three factors: how relevant the technique is to current threat intelligence, how weak your coverage of it is (validation verdict), and how much business impact it could reach through the Digital Twin. A well-covered technique against a low-criticality service ranks below a poorly covered one on a revenue-critical path.

By learning from dispositions. A transparent triage scorer uses signals already in the platform (prior analyst verdicts on similar alerts, asset criticality, rule history) and recommends a disposition for the high-volume low-risk tail, so humans confirm a short list instead of reading every row. Suppression rules are scoped and time-bound, and every suppression needs approval and is audited.

• In transit: TLS for all traffic, including browser to platform, platform to database and platform to every vendor API.
• At rest: the database is encrypted at rest by the managed Postgres provider (AES-256).
• Secrets: integration credentials are additionally encrypted at the application layer with AES-256-GCM before they reach the database, so a database dump or backup does not expose them.

Platform secrets (database credentials, signing secrets, cron secret) are held as encrypted environment variables in the hosting platform and are never committed to code. Customer integration credentials are encrypted at the application layer and are write-only in the console: once saved they are never shown again, only replaced. Scheduled endpoints authenticate with a secret compared in constant time and fail closed.

Today: username and password with securely hashed credentials and 12-hour shift-length sessions, plus DoD PKI / CAC certificate authentication in enclave deployments. Entra ID, SAML and OAuth single sign-on are built on the same identity layer and are enabled per deployment. MFA is enforced through your identity provider when SSO is used.

Five built-in roles (Analyst Tier 1, 2 and 3, Detection Engineer and Administrator) plus custom roles. Permissions are granted per resource (alerts, alert QA, tickets, detections, detection approval, quarantine, integrations, suppressions, subscribers, accounts and more) at none, read or write. Account and system administration can never be granted to a custom role. Every check is enforced on the server before any statement runs.

Administrative and security-relevant actions (account changes, role changes, integration changes, approvals, suppressions) are appended to an audit trail. The actor is always taken from the authenticated server session, never from what the client claims, so the trail cannot be forged from the browser.

Model calls happen only on the server, behind authentication and role checks. Prompts are fixed in code. Context is tenant-scoped and minimal, outputs are schema-validated, and no model output is executed directly. Anything that changes state needs human approval. Customers who need it can route models through their own Azure OpenAI or self-hosted endpoint so data never leaves their boundary.

For triage, the platform side takes seconds. Scoring and disposition recommendations are computed in-process, and AI-drafted incident summaries stream as they are generated. The metric that matters is analyst time to decision, which NurpSuite measures per deployment (mean time to acknowledge, triage and resolve) and reports in the Metrics view. We publish those measured numbers from your pilot rather than quote a generic benchmark.

Console pages are server-rendered and database queries are indexed for high-volume alert and ticket tables, so typical interactions complete in well under a second. Agent runs are longer by nature and stream their progress stage by stage, so an operator is never left staring at a spinner.

Processing is not bound to a single server. Each sync and ingest request runs in its own serverless instance, and concurrency scales with demand up to the database connection pool, which is pooled and sized per deployment. Throughput for your volumes is measured during the pilot.

Nothing is lost. Each connector keeps a durable high-water cursor, so when a vendor API recovers, the next sync resumes exactly where the last successful one stopped. Failures are recorded per integration and shown in the console instead of being retried silently forever. If the AI provider is unavailable, the deterministic features (validation, triage scoring, coverage, Sigma conversion) keep working.

For a Microsoft-only estate, Sentinel and Copilot are an excellent foundation, and NurpSuite is built to sit on top of them, not replace them. What they do not provide is the operating layer above the SIEM: detection engineering across multiple SIEMs from one Sigma source, deterministic proof that detections actually work, business-impact ranking from a digital twin of the organisation, and an executive view of resilience measured over time.

Sentinel tells you what happened. Copilot helps an analyst understand it. NurpSuite tells the organisation whether it is protected, where it is not, and what that means for the business, then helps close the gap.

The combination, and the data it accumulates. Any single feature can be copied, but the value comes from connecting them: a Digital Twin of how the business depends on its systems, joined to validated detection coverage across every SIEM a customer runs, scored by deterministic engines and refined by every analyst decision. Microsoft is structurally incentivised to optimise for its own stack. A vendor-neutral layer that treats Splunk, Elastic and CrowdStrike as first-class peers is not something a platform owner will build.

Proving, in business terms, whether the security programme works. Most organisations cannot answer "if this service were attacked, would we detect it, and what would it cost?" with evidence. NurpSuite answers it by joining validated detection coverage to a model of business dependencies, across mixed security stacks, with an audit trail of how each answer was reached.

E5 gives you excellent sensors and a SIEM. NurpSuite makes that investment measurable. It proves which E5 detections actually work, finds the gaps that matter to your business, extends the same rigour to any non-Microsoft tools you run, and gives leadership a defensible resilience picture. It adds value on top of E5 rather than duplicating it.