Lumini Security — Infrastructure auditing and continuous monitoring

The method

A snapshot, a comparison, and judgment. At the cadence you need.

Daily by default; every five minutes if your operation calls for it. We don't stare at dashboards waiting for something to turn red: we compare complete states and only investigate what changed. And we're not here to grade anyone's work — we know day-to-day operations come first. We're here to tell you which few changes protect you most.

01 · Collector

Read-only, auditable

A script your team can read line by line. No network: it writes a file and exits. The AI interprets results — it never improvises commands.

02 · Baseline

The complete snapshot

Packages, ports, users, SSH keys, scheduled tasks, firewall, permissions and code on disk. Reviewed once, versioned forever.

03 · Diff

Only the changes

Every run is compared against the previous one. The odd-but-known makes no noise; the new change does. And a finding alerts once, not forty times.

04 · AI triage

Context, not panic

The agent investigates every change: who made it, when, whether it was planned and what risk it carries. It tells you in plain language, with its evidence.

If nobody is going to act on a signal, it's not an alert: it's noise.

The catalog

Twelve modules. Buy the ones you need.

Each module is sold, run and delivered separately, and they all return the same thing: an inventory of what was analyzed, findings with reproducible evidence, prioritized remediation, a score and — above all — what could not be examined and why. The consolidated report assembles itself, whether you buy three modules or all twelve.

Base Only needs access to your repository · automated flow

M1

Code

Injections, input validation, misused cryptography, authentication logic, and controls that exist in the code but protect nothing.

Evidence: repository

M2

Supply chain

Known vulnerabilities in your dependencies, component inventory, licenses, artifact integrity and unpinned dependencies.

Evidence: repository + lockfiles

M3

Secrets

Credentials in the code, in environment variables and in git history — including the ones that were deleted and are still valid.

Evidence: repository + history

M4

Development governance

Branch protection, code review, test coverage, pipelines, and who can deploy to production — today, in practice.

Evidence: repository + CI configuration

With access Requires read-only credentials that you create and can revoke

M5

Infrastructure

Servers and cloud: configuration, network, containers, hardening and infrastructure as code. It's the most monitored module.

Read-only role · restricted user

M6

Identity and access

Who gets into what: sessions, least privilege, service accounts, two-factor authentication, and offboardings done in HR but not in the systems.

Identity provider + IAM + code

M7

Data and privacy

Classification, personal data, encryption in transit and at rest, retention, and the real state of your backups: whether they exist and whether anyone has ever tested them.

Inventory + schemas + interview

M8

Third parties

Connected SaaS, OAuth integrations, inherited permissions and vendor risk. What others see of you without anyone having decided it.

Inventory + contract review

With a consultant Requires human work and, in one case, your signed authorization

M9

Exposed surface

Subdomains, undocumented APIs, open ports and panels. The passive part needs no access; active testing only with signed authorization.

Testing authorization

M10

Architecture and threats

Segmentation, separation between customers, trust between services and threat modeling on your actual design.

Workshops with your team

M11

Detection and response

What gets logged, how long it's kept, what alerts whom, and whether anyone has ever restored a backup. How long would it take you to find out?

Interviews + log review

M12

AI and agents

Prompt injection, data leakage into the model, agent permissions and exposure through RAG. Only if it applies.

If your product uses models

Compliance (ISO 27001, SOC 2, PCI, Peru's Law 29733) is not a module: it's a mapping of the findings from the modules you contracted. With few modules the mapping has gaps — and we tell you that before selling it to you, not at delivery.

And there is one more module, M13, that isn't in this catalog because it's not an audit and isn't billed like one: it optimizes your cloud bill and is billed on results. It's right below.

From audit to monitoring

The modules that keep running on their own.

An audit is a snapshot. Monitoring is the continuous re-execution of the automatable part of the modules you contracted — and not all of them convert equally, so you only pay for the ones that do.

M5 · Infrastructure

Persistence and access

Keys, scheduled tasks, services, ports and new accounts. It's what guarantees that whoever got in can come back even after you close the door — and the first thing a comparison gives away.

[P1] New key among a user's authorized keys that doesn't belong to anyone on the team

M1 × M5

Code changes

Every file that runs in production, with its fingerprint. Four hundred changes at once are a deployment; a single one at three in the morning is something else. And the content of the change gets analyzed.

[P1] The payments script loads from a domain that isn't your payment gateway's

M11 · Detection

Commands executed

Who logged in, when, and what they ran. Not with a blocklist: with each server's normal repertoire. And if your server doesn't log any of that today, that's the first finding.

[P1] Download from the internet executed straight in a shell, in a temporary directory

Cross-cutting

Fleet correlation

The most valuable findings don't live on any one machine or in any single module: they appear when you cross-reference. A server audited in isolation is just an audited server.

[P1] The same SSH key opens six servers: compromising one is compromising six

M13 · Cloud optimization

You pay six months of what you save. Nothing else.

The same engine that hunts for risk finds money: oversized machines, misrouted egress, storage in the wrong class, resources nobody turned off. We propose and measure; your team approves and executes. If you don't save, there is no fee.

Real result

−42% off the bill

In weeks, touching only network and storage, without a single outage. Documented case, available under a non-disclosure agreement.

How it's billed

Six months of savings

It's 50% of what you save in a year, billed on the actual invoice, not on a projection. In installments, as the savings happen.

The red line

Security is off-limits

We don't touch log retention, backups, versioning or redundancy. Saving money by turning off what protects you is an incident at a discount.

How it's executed

One change every 48 hours

First what's reversible in 30 seconds, then what requires a build. With abort thresholds: if anything degrades, it's rolled back and documented.

Before touching anything, we agree in writing on the baseline and how savings are measured. Without that, eight months from now we'd be having an argument instead of a result.

Where the evidence comes from

It's not one server. It's your infrastructure.

Underneath the modules there are connectors: read-only pieces that collect the evidence. One connector feeds several modules, and a module can use several connectors. That's why it works the same whether you live in one cloud, in three, or in none.

SSH connector

Linux servers

On-premise, your own datacenter or a VPS, one or fifty. No console to watch: the connector logs in with a restricted user, reads and leaves. Inventory, access, processes and code.

Cloud connectors

Google Cloud, AWS and Azure

IAM, service accounts and their keys, databases, buckets and audit logs. With read-only credentials that you create — and can revoke whenever you want.

No credentials

Edge, DNS and email

What's visible from the outside: certificates and expirations, DNS records, email authentication, forgotten subdomains and exposed panels. It needs no access, only your authorization.

Read-only

Identity and code

Corporate email and repositories: who is an administrator, who has two-factor authentication, who can write to the branch that gets deployed, and who still has access without working here anymore.

What matters isn't the sum, it's the cross-reference: the same key on six machines, the offboarding done in HR but not in the infrastructure, the domain pointing to an address that is no longer yours. None of that shows up looking at one server at a time.

Designed to break nothing.

Auditing someone else's infrastructure is a privilege. These guarantees are not internal policies: they are enforced by permissions that we ourselves have no way around.

Read-only by design

Read-only credentials in the cloud, and on servers a user that the operating system restricts to a single program. It's not a promise: it's a permission.

The collector has no network access

It writes a file and exits. The only thing that runs with privileges on your infrastructure cannot exfiltrate anything, and you verify that by reading the program.

You know what will run, beforehand

You receive the manifest with the complete list of commands, what each one reads and why. The program itself generates it, so it cannot differ from what it does.

And what ran, afterwards

Every command, with its date, its duration and the hash of its result, delivered alongside the report. The audited can audit the auditor.

It proposes, it doesn't execute

Any change action arrives as a proposal: exact command, expected impact and rollback command. No change happens without your team's written approval.

Your data stays with you

We collect configuration and state, never the contents of your databases. Secrets are reported as findings, never in plaintext.

# All of the agent's access to a server fits in two lines
# that your own team installs — and can delete:
adduser lumini-audit
echo 'lumini-audit ALL=(root) NOPASSWD: /usr/local/bin/lumini-collector' \
  > /etc/sudoers.d/lumini-audit

# And revoking it takes less time than reading this line:
userdel -r lumini-audit && rm -f /etc/sudoers.d/lumini-audit

The collector is a published program, with a verifiable hash, that your team reviews before installing. Outside of it, that user cannot run anything with privileges.

How to engage

Start wherever makes sense.

Packages built on the catalog, or individual modules if you prefer. A fixed price in writing before we start, always.

No access · 48 h

External X-ray

The passive part of M9: what anyone can see of you from the internet — certificates, DNS, email, forgotten subdomains and your credentials in public breaches. No access and no installation.

Just your domain and a written authorization

Base · 1 week

Base Diagnostic

The four modules of the Base block on your repository: code, dependencies, secrets and development governance. Automated flow, without touching anything of yours.

M1 · M2 · M3 · M4

Standard · 3–5 weeks

Full audit

The base plus infrastructure, identity, data and whichever modules apply. A signed consolidated report, with score and coverage per module, presented in a meeting with your team.

Up to twelve modules, depending on scope

Monthly

Continuous monitoring

The continuous re-execution of the modules that automate, against the baseline your audit left behind. Alerts by severity when something matters, silence when it doesn't, and a monthly report.

Billed only for the monitorable modules

And fixing it? Every finding ships with its plan. Remediation —version control, reproducible deployment, tested backups, tidy access— can be executed by your team or by ours, and it's quoted separately so it doesn't depend on the audit.

Where the method comes from

This didn't come off a whiteboard.

It came from responding to real security incidents —containment, forensic analysis, infrastructure rebuilds and regulatory notification— and from five years building and operating software in production. What worked on those late nights became a method, and the method became an agent.

Experience

Real incidents

Every rule in this product exists because something failed and had to be solved with production on the line. None of them comes from a theoretical framework.

Craft

We operate, we don't just audit

Five years building and sustaining software. We know what a production change costs, and that's why we propose the ones worth making.

Accountability

The report is signed

With a name and a date. A report someone signs is worth ten generated ones, and it gives you someone to ask when something doesn't add up.

Discretion

We never say whose

You won't see any client's name here, or any finding recognizable as theirs. Yours will get exactly the same treatment.

Knowledge bases

Our agents don't improvise judgment.

They carry the knowledge bases of the certifications the team trained in: what they run, what they verify and what they report follows the same standard demanded of a certified professional.

See all the knowledge bases

INE Security

Google Cloud Cybersecurity

AWS Certified Security · Specialty

When was your last audit?

Let's talk for 30 minutes about your infrastructure. No commitment and nothing to install: just the right questions and a concrete scope in writing.

Schedule a conversation

We know what changed in your infrastructure. And whether it matters.