Find your answer.

An autonomous SOC uses configured AI workflows to handle parts of alert triage, investigation and response. In Imperum, those workflows can assess routed alerts, gather evidence and carry out permitted actions. What happens automatically depends on the workflow, its settings and the connected tools.

The Imperum SecOps Platform brings alert processing, AI investigations, case management and playbook automation into one working environment. Its license model combines the Autonomous SOC capabilities with additional operational modules. The modules available to your team depend on your issued license and configuration.

Imperum can work alongside an existing SIEM or EDR through configured integrations. Those connections can supply alerts and make supported actions available to investigations and playbooks. Coverage depends on the connector, credentials and configuration, so validate the tools and workflows you want to retain.

Configured integrations bring alerts from connected security tools into Imperum. For example, supported integrations include CrowdStrike Falcon and Splunk. Each integration has its own credentials, filters and ingestion settings; receiving an alert and routing it into an investigation are separate configuration steps.

Virtus Pilot gathers evidence, analyzes an alert and builds an investigation plan. Automatio playbooks define the steps and branches of a workflow, and can call Pilot or Triage as part of it. Human Approval steps can be placed before actions that require a decision.

Analysts review uncertain triage results, inspect investigation evidence and correct Triage verdicts when needed. They also make the approval decisions required by configured workflows. Automation reduces the steps a person must carry out manually; the division of work depends on the controls you enable.

Virtus Triage and Virtus Pilot can start from configured alert and playbook workflows. The AI Assistant starts with an analyst’s question and can use available data and tools to investigate it. Pilot runs an investigation through to a report; the Assistant provides a conversation and, with Deep Hunt enabled, a guided way to pursue a hypothesis.

Built-in capabilities include Virtus Triage, Virtus Pilot and Email Phishing, alongside endpoint, network, threat-enrichment, incident-response and forensic agents. Availability depends on the licensed modules and configuration. Connected tools and credentials determine which actions an investigation can use.

Virtus Triage assesses alerts routed to it and returns a verdict and confidence score. Virtus Pilot carries out a deeper investigation, moving through evidence gathering, analysis, planning and reporting. Its execution mode determines whether planned actions run automatically, wait for approval or remain unexecuted.

Triage runs on alerts routed to it by configured workflows. Severity and source filters can narrow that selection. Incomplete or unnormalized evidence can prevent an automatic close and send the result for review, so ingestion alone does not guarantee either a Triage run or an automatic decision.

Triage can return close, escalate or needs-human verdicts. Confidence thresholds, policy rules and safety checks affect the outcome; configured actions can close an eligible alert, create a case or start Pilot. Results requiring human review are queued for a person, and a failed close-safety check can downgrade a proposed closure to review.

No. A policy rule or another deterministic decision path can supply a verdict without the later model-based verdict stage. However, connector enrichment can itself use a model before policy checks. A policy match therefore does not guarantee that the alert caused no model call.

A configured Triage escalation can launch Pilot, and an Automatio playbook can call it as an investigation step. The workflow supplies the alert and can set investigation limits, tools and approval controls. Escalating an alert does not require every workflow to launch Pilot.

Pilot includes isolation in its default approval-required action list and defaults to automatic approval of low-risk actions only. In Auto mode, both the risk threshold and the approval-required list matter. Guided mode queues planned actions for approval; Audit mode skips action execution. Review the effective configuration and connected action before enabling automatic containment.

Supported routes include the Outlook reporting add-in, an enabled phishing mailbox and polling of supported email-security alerts. Mailbox providers include Microsoft 365, Google Workspace, Exchange and IMAP. Enable and configure the relevant route; mailbox intake support does not imply that the same provider supports every response action.

The phishing workflow can examine headers, URLs, sender details and attachments. A configured browser-rendering service can return page evidence, and available sandbox integrations can analyze attachments. These checks depend on enabled services and connectors; an unavailable or skipped check should not be treated as evidence that a message is safe.

Automatic response depends on both the risk threshold and action-specific switches, such as automatic quarantine or sender blocking. Supported actions can include moving a message to junk, blocking a sender or removing a malicious inbox rule. Provider capabilities differ, and unsupported actions are skipped. Review both sets of controls before relying on approval for a particular action.

The investigation view shows the verdict, confidence, findings and execution details, including available message, URL and attachment evidence. It can also show pending or skipped response actions. A Casebook case is created when case creation is enabled and the result meets its configured verdict rules.

The Assistant can query configured Imperum data and use connected investigation tools within a conversation. It can display source citations so you can open the evidence behind a result. Which evidence and actions are available depends on the data, tools and access configured for the session.

Available sources include alerts, cases, triage history, threat intelligence and runbooks, depending on what is configured and accessible in the session’s tenant scope. Connected tools can supply additional evidence. Check the cited sources and the active scope when assessing an answer.

It can use available platform searches, forensic and hunt tools, and configured connector actions. Tools classified as high or critical risk require an approval decision; low- and medium-risk tools can run directly. Review the tool’s classification and configuration when deciding which actions to make available.

Yes. Enter a hypothesis in the Assistant and enable Deep Hunt. It can plan and run available queries and tools, assess the findings and continue within its iteration and time budgets. The resulting report includes findings and coverage gaps; when working in a case, you can attach the report as a case note.

Yes. Some workflows execute actions automatically within their configured limits. Controls differ: Pilot has execution modes and approval-required actions, phishing has risk and action-specific settings, and the Assistant gates tools classified as high or critical risk. Review the controls for each workflow before enabling it.

Yes. In an Automatio playbook, place a Human Approval step before containment and choose the approver role. Connect containment to the Approved branch. Use rejection on timeout, or escalation with final rejection, if a human decision must remain mandatory.

Review investigation evidence and track analyst corrections alongside a representative sample of your alerts. The Triage statistics include an override rate; the displayed accuracy figure is derived from that rate. It measures recorded disagreement, so it should not be treated as an independently measured detection-accuracy result.

An authorized analyst can choose a replacement verdict and enter a reason. The correction is recorded with a link to the original decision, and the override history is available for review. Correcting a verdict is separate from activating a newly trained Cerebrum model.

Open the investigation result to review its findings, report and recorded execution steps. Pilot results distinguish executed, pending and failed actions; phishing results also expose response outcomes and unavailable checks. Use those details and the available source evidence to assess what completed and what still needs attention.

Case Router can assign cases in Auto mode and defaults to Off. Case Prioritizer has a separate automatic-prioritization setting: when enabled, it can score new cases and apply a formula-based priority, subject to evidence and severity safeguards. That creation setting defaults to enabled, so review both controls when configuring your workflow.

Cerebrum learns from recorded analyst outcomes to build a tenant-specific false-positive scoring model. Depending on its operating mode, scores can be shown to analysts or contribute to case prioritization. It complements Triage and investigation workflows; separately configured automation can close eligible false positives.

It can, when configured to do so. Cerebrum defaults to Off. Automation mode lets you select rules for automatic false-positive closure, subject to evidence checks and daily limits. A separately configured Cerebrum step in Modus can also close eligible false positives.

Yes, when the required tools are configured and permitted. Agent Studio tool calls pass through gateway checks, including permissions and applicable approval policy. Configured phase gates can pause a run for review, while an agent’s automatic-approval policy can permit actions within its risk limit. Review these settings before enabling actions that change a system.

Yes. Publish the capabilities you want to expose, and configure their allowed roles, risk level, approval requirement and rate limit. Roles are checked when a tool is called. High-risk actions require approval under the default gateway policy, although a deployed agent’s configured automatic-approval policy can permit actions within its limit. Review both policies together.

You can start with built-in Sigma rules, upload rule files, create your own rules or sync a configured Git repository. Sigma is a shared format for describing detection logic.

Use the test action to inspect matches against indexed data before deploying a rule. A useful result depends on having the relevant logs and matching fields; importing a rule alone does not establish detection coverage.

Detection rules evaluate data in the Search Index using the rule’s log source, index patterns and field mappings. The data must already be available in the relevant indices and contain the fields the rule expects.

Review the selected rule’s indices and test results when checking a new source. A connected tool does not by itself mean every rule can evaluate its data.

Yes. Modus grouping rules can collect alerts that share configured fields, such as a hostname, within a chosen time window. Thresholds and rule conditions determine when the group triggers further work.

A configured Create Case action can turn that group into a case. Alerts do not automatically belong together just because they mention the same host; the relevant fields and grouping rules must match.

Yes. Imperum supports configured indicator sources, including URL downloads, supported object-storage sources and indicator uploads. You choose the sources and configure how their indicators are checked against indexed data.

Feed availability, credentials, update schedules and field mappings affect the results. Confirm any commercial feed subscription separately from the Imperum integration.

No. The vulnerability library brings together published advisory and vulnerability intelligence. It helps explain a vulnerability and its reported context.

Defensum uses findings and asset information from configured sources to assess exposure in your environment. A vulnerability appearing in the library does not establish that one of your assets is affected.

Cognitio records known aliases alongside the threat group’s main name. Searching the main name or a recorded alias can return the same profile, and the Details view shows the vendor names behind the alias records.

This helps analysts connect reporting that uses different names. The mapping reflects the bundled catalog; it is not a promise that every vendor name or attribution is known.

Cognitio provides threat-actor profiles, aliases and associated intelligence so analysts can understand who a report refers to and examine related detection opportunities. Indicator-feed management is a separate workflow for maintaining indicators and matching them against data.

The bundled actor catalog and configured live feeds serve different needs. Access to a commercial feed still depends on that provider’s terms and your configuration.

The source registry includes organizations such as CISA, ENISA, CERT-EU and national cybersecurity agencies. Administrators can configure supported sources and their update cadence, and add supported custom feeds.

Availability varies by source and network access. Managed vulnerability feeds have their own scheduling, and the source status should be checked for failed or stale updates.

Yes, where matching rules and the required capabilities are available. The profile can queue matched local rules for server-side detection and launch an endpoint hunt using a supported artifact. These actions require their own permissions and the relevant endpoint or detection setup.

Rules from the Virtus Optimus Library follow its conversion and deployment workflow. A profile match is a starting point for investigation, not proof that an actor is present in your environment.

The threat-actor catalog and ATT&CK reference data are bundled with the product, so those reference records can be read without fetching them from the internet.

Live advisory updates and external indicator feeds need access to their configured sources. Confirm the required update process and any other connected workflows when planning a restricted-network deployment.

Local Sigma rules have their own Detection Lake workflow. Cognitio can match those local rules even when the Virtus Optimus Library is not licensed.

Optimus Library content has a separate availability check and deployment path. Confirm the modules and permissions needed for your detection workflow during evaluation.

Imperum’s endpoint collection workflow supports Windows, macOS and Linux. It offers artifacts suited to the endpoint’s operating system, such as Windows execution records, macOS launch agents and Linux system activity.

Available artifacts depend on the enrolled endpoint and its configured collection service. Select the evidence you need and check collection and indexing results; not every artifact is available or successful on every endpoint.

Collected records can be indexed for search and timeline review, and collection results identify the endpoint, artifact and collection flow. When an action includes case context, its audit record can also carry the case, actor and target.

Check that the collection was indexed and that any required files were retained. Set and validate your evidence-handling and retention process for the deployment; collection success alone is not a guarantee of complete evidence preservation.

In hunt mode, Virtus Assistant can query indexed forensic records, retrieve timelines and work with endpoint hunts through its available tools. Calls carry the caller and tenant context into the forensic execution path.

The Assistant’s risk rules require approval for high and critical risk tools, while low and medium risk tools can run without that approval step. Endpoint access, available tools and the relevant permissions still determine what the workflow can do.

Yes. Imperum brings endpoint artifact collection, indexed search and a forensic timeline into its investigation workflow. Analysts can select an event and inspect its source fields instead of relying only on a summary.

You still need the relevant module access, endpoint setup and collection artifacts. Whether you also need specialist forensic tools depends on the evidence and analysis your team requires.

An analyst can create a case from an alert, or open a case directly. Configured automation can also create cases, including correlation rules and triage escalation. A case can retain its source and linked alert context so the next analyst can understand how the work started.

Automatic case creation depends on the active rules and workflow configuration. Review those settings during deployment rather than assuming every alert creates a case or that automatic creation is always disabled.

The case timeline distinguishes the time an action was recorded in Imperum from the time the underlying event occurred. Event time is stored when a real source timestamp is available.

The investigation view follows action time. The incident view orders entries by event time and labels entries that do not have one, so missing timestamps are visible rather than silently treated as incident times.

Yes, through a supported, deployed ticketing connector and configured Casebook Sync. You select the connector, credentials, field and status mappings, and conflict behavior before enabling synchronization.

This lets the investigation remain in Imperum while relevant updates reach the linked ticket. Supported actions and sync behavior depend on the connector and configuration; confirm your required workflow during evaluation.

An analyst can hand selected unfinished cases to an incoming analyst and include handoff notes. The handoff updates ownership and adds a timeline entry to each transferred case.

The case stays available with its existing investigation context. Only cases owned by the outgoing analyst qualify for that ownership transfer; it is an explicit handoff, not an automatic change at a fixed clock time.

Automatio can run supported actions through configured connectors. Each action needs the appropriate connector, credentials, parameters and permissions. An HTTP Request step can also call a configured API endpoint.

Choose the actions that fit your workflow and review their inputs and results before enabling the playbook. Tool access and an available connector do not guarantee that every vendor operation is supported.

Yes. An enabled playbook can start from a configured trigger and run its automated steps. Add Human Approval steps where the workflow should pause for review, then define what happens after approval, rejection or timeout.

Approval requirements also depend on the action and applicable policy. Configure the timeout deliberately: rejection is the default for the Human Approval step, while other timeout behavior can be selected. Unattended execution is not a guarantee that a run will complete successfully.

Automatio can compare a locally inspectable connector action’s definition with the version captured when a run starts. If that definition changes during the run, the affected step can stop with a connector-schema error.

This check does not cover every upstream API change: remote connectors and action definitions that cannot be captured are outside it. Review the failed step, update the connector or playbook as needed, and test the workflow again.

Yes. An authorized operator can deploy an enabled, validated playbook to selected tenants. Deployment creates a tenant-specific copy and records its relationship to the source.

A deployment can be removed from one tenant without removing the source playbook or another tenant’s copy. Check each tenant’s connector setup, permissions and approval configuration before putting the workflow into use.

Recovery depends on the deployment’s execution configuration. Imperum has an optional durable-execution path that can resume a run from saved state; this needs to be enabled for your deployment.

Confirm that recovery is configured for your deployment and validate it with your approval and connector steps. Do not assume every interrupted action can be replayed safely or that every run will resume automatically.

Choose the connector in Marketplace, configure the appropriate tenant or profile, and save its connection details and credentials. Review the reported connection-test result, then enable supported ingestion and field mappings. A reachable host does not always mean that credentials were verified; available tests and ingestion options depend on the connector.

Imperum can ingest alerts through supported SIEM integrations. The route depends on the product: a configured API poller, webhook or syslog feed. Check the connector’s ingestion capabilities, credentials and field mapping against the alerts you want to bring in. A catalog entry alone does not mean every event type is ready to ingest.

Sources can send syslog, post to a webhook, or supply events through a configured API poller. Ingestion and normalization use the source’s supported recipe and field mappings so the resulting records can be searched and used by downstream workflows. Configure source access, tenant attribution and mappings before relying on those records for analysis.

Connector credentials are encrypted in Imperum’s server-side Vault. Tenant and profile settings determine which connection a workflow uses, so separate customers can configure separate credentials for the same tool. Viewing or changing stored secrets requires the relevant permissions; authorized administrators may manage credentials across their permitted tenant scope.

Developer Studio provides a guided connector builder and an OpenAPI import workflow. Import a supported specification, select the operations you need, and review the generated actions, authentication and optional ingestion settings before deployment. The connector still needs working service access, credentials and configuration; an import is a starting point for review.

Yes. Developer Studio defines how Imperum connects to a tool and which actions it exposes. Agent Studio defines the procedure an agent follows using available tools, prompts, phases or a visual graph. Review connector bindings, permissions, approval settings and deployment capacity before activating the agent.

Agent Studio offers form-based Single and Structured agents, an Advanced visual graph editor, and Virtus Architect for generating a draft from a description. You can use these authoring paths without starting from source code. You still need to understand the procedure, configure its tools and review the draft before deployment.

An agent template is a reusable definition containing prompts, tools, phases and configuration. Copying it creates a draft custom agent that you can adapt to your procedure. Review its connector bindings and approval policy before deployment; a template is not evidence that its tools are already configured or that a run will succeed in your environment.

MCP, the Model Context Protocol, lets an AI client discover and call tools through a common interface. Imperum’s MCP Gateway exposes published platform and connected-tool capabilities to authenticated callers, and can register external MCP servers as tool sources. It reuses configured integrations; available operations depend on the published tools, connected services and permissions.

Use an MCP client that supports the gateway’s connection method and authentication. Confirm the client’s current transport support, configure the gateway endpoint and access token, then check tool discovery and a permitted action. Compatibility depends on that setup; support for MCP alone does not guarantee every client or feature will work unchanged.

The caller authenticates to the MCP Gateway separately from the credentials used for a connected service. Imperum resolves connector credentials from the Vault in the caller’s tenant context. Credentials for registered external MCP services are also stored encrypted and used to authenticate to those services. This lets the gateway manage service access centrally.

CTEM means continuous threat exposure management: regularly reviewing exposure, deciding what matters most and following up on the work. Defensum supports that process by collecting configured asset and identity evidence, assessing risk and connecting qualifying findings to casework.

The assessment depends on the sources and policies you configure. A risk finding helps prioritize investigation and remediation; it does not by itself show that an issue has been fixed.

Defensum primarily collects vulnerability findings and other posture data through configured connectors, then adds asset, control and exposure context for prioritization.

External attack-surface discovery has a separate scanning workflow. It requires accepted rules of engagement, verified eligible targets and the relevant scan configuration. Available scan methods and infrastructure determine what can run; connecting an internal scanner is a different workflow.

The shadow-identity view examines identity-related exposure such as risky OAuth grants, unapproved SaaS applications and guest identities reported by connected identity systems. This helps teams inspect permissions and application access that may otherwise be difficult to track.

Checks depend on the fields a connector actually returns. Rules without the necessary data are deferred rather than treated as evidence that the identity is safe.

Defensum combines signals such as vulnerability severity, exploitation context, internet exposure, security-control gaps and business criticality into an asset risk assessment. The result includes a priority tier and an explanation of the contributing signals.

Certain combinations, such as internet exposure with a known-exploited or critical vulnerability, can raise the priority beyond the weighted score alone. Use the explanation and available evidence to decide the next investigation or remediation step.

Virtus Sentinel is Imperum’s AI security module. It brings together reported AI assets and activity from configured endpoint, browser, gateway and platform sources, helping teams inspect what is being used and the associated evidence.

Its policy and protection capabilities include configured masking and prompt-injection controls. Coverage depends on the components you deploy and the traffic they can observe; discovery and classification alone do not block an asset.

Sentinel can show AI tools, MCP servers, agent processes and browser-reported AI activity from its configured sources. A record keeps its classification and available source evidence so an analyst can investigate how it was identified.

Supported, unambiguous matches can combine endpoint and gateway sightings, or platform-agent and gateway sightings. Browser sightings and ambiguous matches remain separate; a shared name is not enough to merge everything into one asset.

Prompt-injection policy starts in monitor mode, and Veil masking is disabled in its default configuration. Enabling prompt-injection blocking requires the administrator-controlled block permission and an enforcement policy.

Other gateway and tool policies have their own settings. Review the controls for each deployed component; the monitor default is not a blanket promise that no configured policy can block a call.

By default, Sentinel’s endpoint reporting retains call metadata without prompt excerpts. Optional redacted excerpts require a policy change, and allowing full payloads requires a separate administrator permission. The receiving service enforces that policy.

This controls endpoint telemetry sent to Imperum. It does not prevent an AI application from sending prompts to its configured model provider; review provider routing and the relevant gateway policies separately.

Imperum provides deployment configuration for customer-operated infrastructure and can connect to locally hosted models. For an air-gapped environment, agree the required modules, local model endpoints, installation packages, updates and reachable integrations in the deployment design. Include endpoint connectivity and evidence storage for forensic collection. Confirm each required workflow against those constraints before committing to the architecture.

You configure the model providers and their endpoints, including supported cloud services and locally hosted models. Virtus routing can assign different provider chains to features such as Triage and Pilot, with configured fallbacks. Data follows the selected route, so review the full chain when setting residency requirements. Local model hosting alone does not describe every integration’s data flow.

Veil is Imperum’s protection and masking layer. For supported platform language-model calls, configured PII redaction replaces matching identifiers with placeholders and can restore them in the returned answer. This masking must be enabled and depends on the feature’s routing and provider type; the platform redactor is cloud-provider scoped. Review categories and routing for the workflow you intend to protect.

Cerebrum trains and scores its learning models inside the Imperum deployment. Sharing is a separate setting: Cloud Sync can send a model package containing training samples to Imperum’s support service after the model passes its quality gates. The default auto-update setting is off. Review that setting and any export or sharing policy before deciding what may leave your environment.

The license model groups AI agents, Agent Studio, case prioritization and routing, Cerebrum and Magister under Autonomous SOC. SecOps Platform extends that group with playbooks, detections, endpoint operations, multi-tenant operations, Defensum and Cognitio. Your issued license determines enabled modules; confirm the commercial package in your proposal.

Scriptorium, Virtus Optimus, Virtus Sentinel and Limen Autopilot have separate module entitlements in the license model. Cerebrum belongs to the Autonomous SOC group, which is also part of SecOps Platform. Confirm module availability and pricing in your proposal.

Confirm Defensum availability and the required deployment with Imperum during evaluation. Describe the asset, identity and exposure workflows you need, including any service-provider tenant requirements.

Ask for the applicable modules and commercial terms to be stated in your proposal. A capability appearing in product documentation does not establish that it is included in every package.

Ask Imperum to confirm the Sentinel module, deployment components and commercial terms for your requirements. Include whether you need endpoint discovery, browser coverage, gateway controls or a combination of them.

The proposed configuration should state which components and permissions are required. Confirm packaging and availability in the proposal rather than inferring them from the presence of a product page.

Confirm the connectors and authoring tools you need in your quote, together with any third-party subscriptions or API charges. Share the systems, deployment model and workflows you want to connect so the proposal can make the included scope and any additional costs explicit.

Where a license sets an Agent Studio deployment limit, active custom agents count against that platform-wide allowance. Draft and disabled agents do not count as active deployments. Capacity is checked when an agent is activated. Confirm the allowance and commercial terms for your license; the platform’s capacity counter does not establish a price.

Imperum uses a product-and-module license model. Named product editions include Autonomous SOC, SecOps Platform and The Portal; enabled modules and capacity limits are recorded in the license. Additional module access can vary by agreement. Discuss your workflows, deployment and provider requirements to confirm the right scope, capacity and pricing.

Multi-tenant operations give providers customer-scoped views, connector profiles and onboarding workflows. Authorized operators can work across their permitted customer scope, while the self-service portal offers customer access to requests and cases. Configure tenant permissions and customer workflows to match the service you deliver, and confirm the required modules in your license.

The Portal is a product edition whose default modules include multi-tenant operations, Case Router and Case Prioritizer. The self-service customer portal is a separate feature for submitting requests and following permitted cases. Distinguish the edition you license from the customer-facing access and workflows you configure.

Multi-tenant mode uses tenant context to scope supported views, API operations and connector credentials. Customer profiles let you configure separate service connections. Authorized provider operators and administrators can access the customer scope assigned to them. Confirm the required data boundary, permissions and deployment arrangement for each customer during architecture review.

Yes. You can configure case time budgets by priority and lifecycle phase, with customer overrides and inheritance from a parent tenant. A rule-specific target takes precedence; otherwise the tenant setting or global default applies. These are workflow targets for tracking your service, not a promise of response times from Imperum.

AI agents belong to the Autonomous SOC and SecOps Platform product defaults; they are not part of The Portal’s default module set. If you want AI triage alongside provider operations, discuss a license that covers both capabilities, then configure the relevant integrations and triage rules. The enabled modules on your license determine access.

Visit the Analyst Recognition collection to browse research references by analyst firm and follow the report links. Check the access note for each report: full Gartner research may require a subscription, while available reprints can have different access terms.

Read each reference in its original context and date. Being named in research, participating in an interview and receiving a particular assessment describe different kinds of recognition.

Gartner Peer Insights is a customer-review source. Its content reflects individual users’ experiences and opinions; it does not represent Gartner analyst research or an endorsement of Imperum by Gartner.

Use the review profile to read customer feedback, and the Analyst Recognition collection to explore research references separately.