Pulsobot security pack

For security reviewers. Pulsobot is a Databricks FinOps product that runs inside your own Databricks account: its jobs, its API App and its data live in your workspace. Pulsover operates no service that reads your data.

Tiers in one paragraph

The Diagnose Tier (free, default) reads System Tables and writes only to the product's own schema, volumes, secret scope and Lakebase database. The Optimize Tier is unlocked by a signed Licence and adds no permission: it opens paid features in code. Remediation (changes to your jobs) needs agents that exist only if you install them explicitly (--prepare-optimize or upgrade), stay dormant without a valid Licence, and act only on Remediation Orders a human approved.

Reviewer FAQ

Does it write to my jobs? Not in the Diagnose Tier: no grant on your jobs is write-level. With a prepared Optimize install, the Deployment Agent can deploy a remediated job definition, only for a Remediation Order a human approved, and only while both the Licence and the FF_REMEDIATION flag allow it. See Permissions.

What data leaves our account? Only the Registration, once at install: an email, your Databricks account ID and the install's public key. Rule and Licence refresh are plain GET requests with no body. No cost, workload, code, log or user data is sent. See Data flows.

Is there telemetry? No. None is shipped. If it is ever added, it will be opt-in.

Can Pulsover access our workspace? No. There is no inbound connection, no Pulsover credential in the product, and none of your credentials with Pulsover. Pulsover only publishes encrypted files your rules job chooses to download.

What credentials does it hold? In its own secret scope: the Licence, the private half of the Install Key, the credentials you give for each Account you register and, on prepared installs, the two agents' own service-principal credentials. The account-admin credentials used by --prepare-optimize or upgrade are used for that run only and never stored. See Permissions.

Can it run with no internet access? Yes. Registration falls back to a code you paste on a web page from any machine, and rules and Licences can be imported by file (pulsobot-installer rules import). See Data flows.

What network access does it need? Outbound HTTPS to downloads.pulsobot.com (optional, see above), GitHub for the Databricks CLI download at install, and the public AWS price list for AWS installs. Nothing inbound. See the allow-list.

What happens if the Licence expires? A Grace Period keeps everything running with a banner. Afterwards the install falls back to the free Diagnose Tier: no new remediation, but work in flight (verification, rollback, cleanup) always finishes. Nothing breaks in production. See Licence model.

Does the Licence call home? No. It is an Ed25519-signed file verified offline against keys built into the binary.

Can Pulsover switch the product off remotely? No. Pulsover can stop delivering new rules and Licence renewals; the current Licence then expires on its date. Delivered rules stay usable.

How do we verify the binary? Check the SHA-256 against the release's checksums file, then the platform signature: Apple Developer ID plus notarization on macOS (codesign, spctl), Authenticode on Windows (Get-AuthenticodeSignature). Commands in Signing and supply chain.

Is there an SBOM? Yes, CycloneDX JSON, published with every release next to a signing ledger and checksums.

Why aren't the binaries obfuscated? So your tools can inspect them. The paid value is protected by signatures and encryption, not by hiding code. See Signing and supply chain.

Can someone inject rule SQL into our install? An install runs only Rule Set Bundles signed by Pulsover's keys and encrypted to its own Install Key. The free-tier key cannot sign paid rules, and the free registration service can only ship templates approved in a human-signed manifest.

Who can see the product's data inside our workspace? account users can read and write the product's own schema (never your objects), so your analysts can query it; the dashboard is open to workspace users; admin actions require membership of the admin group you configure.