The defensible scan: why authorization is a feature, not paperwork

Most of the attack-surface conversation is about finding things. Not enough of it is about the question your legal team, your auditor, and your own on-call engineer will eventually ask: what, exactly, are you allowed to scan — and can you prove it?

A scanner that will happily fire at whatever hostname you paste into it is a convenience right up until the moment it isn’t. Point it one CIDR too wide, let a stale target resolve to someone else’s cloud, or run it the week a customer revokes permission, and “we were just monitoring our attack surface” becomes a very uncomfortable incident review.

ProbeIQ treats authorization as a first-class feature. Here’s what that means in practice.

Ownership, verified before a packet is sent

Before ProbeIQ scans anything, you have to prove the asset is yours. Names are verified with a DNS TXT record; IP space with a signed attestation. And a set of addresses is refused unconditionally — RFC 1918 private ranges, loopback, link-local (including cloud metadata endpoints like 169.254.169.254), CGNAT, and reserved space — including when a public hostname resolves to one of them. There is no checkbox that turns that off.

Signed rules of engagement

Every scope carries a signed authorization that captures the rules of engagement: intensity caps, rate limits, the time windows you’re allowed to run in, blackout periods, and an expiry date. The signature covers the scope’s assets and rules together — so if anyone edits the target list or loosens a limit, the signature is void and scanning stops until it’s re-signed. You can’t quietly widen the blast radius after the fact.

Enforced at every layer, not just the front door

A permission check that only runs when you click “scan” is theater. ProbeIQ enforces the same authorization in three places: when the scan is created, when the dispatcher schedules each job, and on the worker itself, immediately before an engine starts. Three independent checks, every time.

And the workers run behind an egress allow-list — they are, at the network level, incapable of reaching anything outside your authorized scope. Even a misbehaving engine or a malformed target can’t wander off the reservation.

A tamper-evident record of everything

Every meaningful action is written to an append-only, hash-chained audit log. The database itself rejects updates and deletes on those records, and the chain can be independently verified — so the log isn’t just a list you have to trust, it’s a sequence you can prove hasn’t been altered. It’s the backbone of a SOC 2 evidence program, and it’s your defensible answer to “who authorized this scan, against which assets, under what rules, and when?”

Controlled validation requires authorization

Standard scans report what’s exposed. Optional, bounded validation requires separate signed authorization and enablement. ProbeIQ does not weaponize findings or pivot through your systems. Continuous monitoring should make your perimeter safer, not generate its own incidents.

Why this is the easy path, not the slow one

It would be easy to read all of this as friction — more steps between you and a scan. It’s the opposite. The guardrails are what let a security-conscious generalist run continuous external monitoring confidently, without a lawyer on standby, and hand an auditor a clean trail without a week of screenshotting. The safe path is the easy path.

Want to walk through the authorization and audit model in detail? Book a demo — it’s the part of ProbeIQ we’re proudest of.