Skip to content
Explore solutionsSecurity Engineering & Automation
Security Engineering & Automation

Turn repeat work into
controlled response.

Imperum gives security engineering teams a platform to connect their tools, build playbooks and agents, and inspect how they run. Bring data into a usable shape, turn a response procedure into reusable steps, and keep the decisions that need a person under your control.

Connect the toolsBuild the procedureControl the action
A procedure your team buildsContain a compromised endpoint
Illustrative workflow
Alert from a connected sourceSuspected compromise · endpoint ID supplied
HOST-042
Automatio · configured playbook
Look up the endpointConnector action → host context
Read
Request human approvalReview target and proposed isolation
Gate
Approved ↓Rejected → End without isolation
Isolate the endpointSubject to action policy
Write
Notify the teamConfigured notification channel
Send
Explore the decision:

This example looks up the endpoint, waits for the configured approval, then attempts isolation and notification on the approved path. Rejection ends this path without isolation. Action policy may require additional review. Real runs require configured connectors, credentials, access and a valid target.

01 - Connect the estate

Make the data useful to the next step.

Security engineering starts with the tools already in place. Choose a connector, configure its credentials and supported ingestion endpoints, then map the fields that the next rule or playbook needs. Ingestion and normalization depend on the connector and its configuration.

A field the procedure can useIllustrative mapping
Source responsedevice.hostnameHOST-042
Configured field mappinghostnameHOST-042

Preview the transformed data before storing it. Check that the endpoint identifier needed for a later action is also available.

Less repeated translation. Analysts and automations can work from fields your team has deliberately mapped.

02 - Build and test

Turn the procedure into something reusable.

In Automatio, connect triggers, conditions, connector actions and approval steps on a canvas. Start visually or describe the workflow to generate a draft, then review its logic and field bindings. Test with sample inputs and inspect each node’s output before enabling it.

Repeatable steps

A playbook for the known procedure.

Make the order explicit: look up an endpoint, request approval, attempt isolation, then send the configured notification. Route rejection to an end state.

Explore Automatio
Investigation with tools

An agent for the work that needs reasoning.

In Agent Studio, adapt a template or build a custom agent. Define its instructions, tools and phases, and configure where risk requires approval.

Explore Agent Studio

Choose test settings deliberately. Testing is not automatically isolated from your systems. Dry-run settings can simulate side effects while read actions and some AI analysis still execute; simulated approvals do not test a real reviewer’s decision.

03 - Operate with control

Know what ran. Know where it stopped.

An approval step gives your team a checkpoint before a sensitive action. Configure the approver, timeout and branches for that procedure. Then use Execution History to inspect node inputs, outputs and status when a run succeeds, fails or needs attention.

Execution HistorySynthetic example · all required approvals
TargetHOST-042
DecisionRequired approvals granted
Example outcomeIsolation reported successful
Endpoint lookupContext returned
Human approvalApproved path selected
Isolation actionConnector result recorded
NotificationSend result recorded

A reviewable handoff to operations. The next analyst can see what was attempted and inspect the result instead of reconstructing the procedure across tools.

Approval is configured, not universal. Timeout behavior can reject, approve or escalate. The example uses rejection on timeout; action policy may require additional review, and an approved request still needs a successful connector action.

04 - Maintain and extend

Keep the workflow useful as the estate changes.

Find gaps in detection and data flow.

With Virtus Optimus licensed, use Watch to review detection-health issues and Broken Pipe to investigate stopped ingestion or parser drift. Available verdict data can add context about noisy rules.

Explore Virtus Optimus

Build the missing integration.

Developer Studio lets your team define authentication and actions, then review and generate a connector. An OpenAPI description can provide a starting point; configure and verify the resulting connector for your environment.

Explore connector authoring
The operational result

Less repeated setup. A clearer trail when something fails.

Reusable procedures reduce the steps analysts must coordinate by hand. Mapped inputs, explicit review points and per-step results give engineering a concrete place to investigate and improve the work.

05 - Start with one procedure

Bring one repeated task and the tools it touches.

  1. Define the input and the finish.Pick the event, the fields it must carry and the result operations needs.
  2. Configure the tools and the boundaries.Confirm connector access, action targets, reviewers and rejection paths.
  3. Test, enable and inspect.Review sample runs, enable deliberately, then check execution results with the team.

Available modules and actions depend on your license, permissions and configured integrations. Validate the workflow in your deployment before relying on it.

Questions from engineering teams.

1Do we need to replace the tools we already run?

Start with supported connectors for your existing tools. Check the particular actions and ingestion endpoints you need, then configure credentials and field mappings. A catalogue entry alone does not mean every capability is ready in your environment.

2Can a person review before an action runs?

Yes. Add a Human Approval step and wire its approved and rejected branches. The default approval window is 60 minutes with rejection on timeout; these settings are configurable. This page’s example holds before isolation.

3Is a test run completely simulated?

No. Execution settings matter. Dry-run behavior can simulate side effects, while read actions and some AI analysis still run. Simulated approval chooses an example branch without exercising the real approval process. Review your tools and test inputs accordingly.

4How do we evaluate the time it saves?

Compare the same procedure over a defined period: runs completed, hands-on time before and after, approval effort and exception handling. Use execution records to understand what actually ran. Run duration alone is not analyst time saved.

Have any other questions?
Talk to our team

Bring the workflow
your team keeps repeating.

We’ll map its inputs, tools and approval points, then show how it could run in Imperum.