Skip to content
Netlume

Security

Designed for production networks from day one.

Infrastructure teams cannot adopt a tool they cannot trust. Netlume is read-only by default, keeps credentials in your environment, records everything it does, and never takes destructive action without explicit approval.

Book a DemoExplore Platform

Controls

Security model

The controls below describe how Netlume is designed to operate. Specific configuration is agreed with each team.

Read-only connectivity

Connectors are read-only by default. Investigations use show commands, telemetry and APIs that do not modify device state.

Credential isolation

Device credentials are referenced from your secrets store and used only by collectors inside your environment. They are never shown to users or to the reasoning layer.

Least privilege

We recommend dedicated, narrowly scoped device accounts — read-only roles and command allow-lists — and provide templates for common platforms.

RBAC

Roles control who can see which networks, run which investigations and approve which kinds of change, aligned with your identity provider.

Approval workflows

Any proposed change shows the exact diff, blast radius, verification plan and rollback, and requires approval from an authorized operator.

Audit logs

Every command run, recommendation made, approval given and verification result is recorded with actor and time, and can be exported.

Private deployment

The platform can run on-premise or in your private cloud. Collectors connect outbound, so no inbound access to your network is required.

Encrypted transport

Traffic between collectors, devices and the platform uses encrypted transports — SSH, TLS and gRPC over TLS.

No automatic destructive actions

Netlume does not reload devices, shut interfaces, clear sessions or change configuration on its own. Write actions are opt-in, scoped and approved.

Human in the loop

You decide how far automation goes.

Autonomy is configured per environment. Most teams start read-only and add recommendation and approval workflows as trust grows.

  1. 01Read Only

    Default for every connector

    Collect state, logs, telemetry and configuration. No writes to any device.

  2. 02Recommend

    Netlume generates

    Propose a remediation with evidence, blast radius and a rollback plan.

  3. 03Approval Required

    Operator decides

    A named operator with the right role must approve the exact change.

  4. 04Execute Approved Action

    Scoped credentialoff by default

    Apply only the approved change, scoped to the approved devices and window.

  5. 05Verify Result

    Netlume verifies

    Re-run the evidence checks and confirm the symptom is gone.

  6. 06Rollback Guidance

    Operator decides

    If verification fails, present the prepared rollback and its expected effect.

Approval required

rb-2291 · INC-4126

Revert CHG-2291 on JUN-MX-EDGE-01

Restore local-preference 100 for DCI-EXPORT so 10.44.18.0/24 prefers JUN-MX-EDGE-02 while the et-0/0/2 optic is replaced.

[edit policy-options policy-statement DCI-EXPORT term PREFER-EDGE-01 then]
-    local-preference 200;
+    local-preference 100;
Blast radius
1 device · 1 term
Prefixes moved
1 (/24)
Method
commit confirmed 5
Rollback
automatic if unconfirmed

Verification plan

  • Best path for 10.44.18.0/24 via 172.16.0.9
  • Probe loss < 0.1% for 5 minutes
  • No new BGP flaps on ARISTA-BL-01

Requires role: network-lead · 1 of 1 approvals

Reject Approve change

Audit log · INC-4126

immutable · exportable
  1. 14:03:52

    investigator · Generated recommendation

    Revert CHG-2291 on JUN-MX-EDGE-01

  2. 14:04:30

    netops-oncall · Requested approval

    Rollback candidate rb-2291

  3. 14:06:12

    network-lead · Approved change

    Rollback candidate rb-2291 · window 5 min

  4. 14:06:20

    executor (scoped) · Applied commit confirmed 5

    JUN-MX-EDGE-01 · 1 policy term

  5. 14:07:41

    investigator · Verified result

    Best path → EDGE-02 · probe loss 0.0%

  6. 14:08:02

    netops-oncall · Resolved incident

    INC-4126 · root cause linked

Data flow

Credentials stay inside your boundary.

  1. 01

    Secrets store

    Your vault holds device credentials. Netlume references them; it does not copy them.

  2. 02

    Collector

    Runs inside your network, retrieves credentials at run time and connects to devices over SSH, TLS or gRPC.

  3. 03

    Devices

    Accept read-only sessions from a dedicated, least-privilege account with an allow-listed command set.

  4. 04

    Platform

    Receives collected evidence over an outbound, encrypted connection — never the credentials.

FAQ

Questions security teams ask

Does Netlume need write access to my devices?

No. Investigation, correlation and root cause analysis work with read-only access. Write access is only relevant if you choose to let Netlume execute approved changes, and can be granted narrowly or not at all.

Where do device credentials live?

In your environment — typically your existing secrets manager. Collectors retrieve them at run time; they are not stored in investigation records or exposed to users.

What data leaves my network?

With an on-premise or private-cloud deployment, nothing needs to. With a managed deployment, collected operational data is sent over encrypted connections to the platform; we agree scope and retention with you up front.

Is Netlume certified against a compliance framework?

Netlume is an early-stage company and has not yet completed third-party certifications. We are glad to walk your security team through our design and answer security questionnaires.

Can we limit which commands collectors run?

Yes. Command and path allow-lists are part of the connector configuration, and every executed command appears in the audit log.

Review our security design with an engineer.

We'll walk your network and security teams through connectivity, credentials, data handling and approval workflows for your environment.

Book a DemoTalk to Engineering