Skip to content
LogSentinel
Self-hosted log security for Nordic fintechs

Your access logs already know who is attacking you. Now your auditor will too.

LogSentinel runs on your own server, reads the API access logs you already have, and turns them into a dated security report every few hours: ten attack detectors, a Swedish-calibrated personal-data scan, and an audit trail you can hand straight to your auditor. No agents. No new data processor. No customer identifiers sent to anyone.

Book a demoOrder a PII & Threat Snapshot
  • Runs in one Docker container
  • Works with nginx, uWSGI and CSV logs
  • First report on day one
report · overview · sample run

Overall severity

CriticalPII exposure in URL
Findings
7
Critical
1
High
2
Detectors run
10 / 10

Narrative

USER_IP_0001 tried 22 different accounts on /api/login within 45 minutes and 91 % of the attempts failed. Account USER_ID_0012 then answered with a success.

What the LLM sees: tokens only. The token table stays on your disk.

Sample data

LogSentinel in six facts

  • 10attack detectors, each threshold documented and pinned by an automated test
  • 8personal-data patterns scanned in every URL: personnummer, IBAN, card, e-mail, phone, BankID, Swish, secrets
  • 0raw log lines or customer identifiers sent to third parties
  • 1container on your own infrastructure. No database, no agents
  • 14 daysdefault retention for reports and baseline history, then a clean command deletes them
  • 24 hcontext window re-read each run, so an attack that spans two runs is still seen whole

Product facts, not customer statistics.

The problem

Your logs are evidence. Right now, nobody is reading them.

Every brute-force attempt, every scraping bot, every account takeover leaves a trace in your access logs. So does every personnummer or IBAN that a front-end developer accidentally put in a URL. That turns your logs into regulated personal data.

  • Access logsevery requestInput
  • WAFsingle requests at the edge
  • Auth servicelogin events
  • CDNedge traffic
  • App errorsstack traces

One LogSentinel report

Thu 22 Oct 2026, 15:05 CEST · 4 of 7 findings shown

  • Credential stuffing22 accounts, 91 % failedHigh
  • Personnummer in a URL14 requests, maskedCritical
  • /.env answered 2001 of 3 sensitive probesCritical
  • Bot timingnear-constant 2.0 s rhythmLow

Entities appear as tokens such as USER_IP_0001Sample data

LogSentinel reads the access log. The other four are where the same activity shows up in separate tools today.

Most fintechs your size end up with one of three options:

  1. 01

    Ship the logs to a cloud SIEM.

    Expensive, and your customers' IPs and identifiers now sit with another processor, often outside the EU.

  2. 02

    Rely on the WAF.

    It judges single requests at the edge. It doesn't see one account logging in from five networks in a day, or a slow credential-stuffing run spread over an afternoon.

  3. 03

    Do nothing and hope.

    Until an incident, a customer complaint or a supervisory question asks you to show how you monitor.

DORA expects you to detect anomalous activity promptly and to prove that you do. "We have logs" is not proof.
How it works

From raw log to audit-ready report, on your server, on your schedule.

  1. Point it at your log.

    nginx combined/common, uWSGI or CSV, detected automatically. Each run picks up where the last one stopped (byte offset) and re-reads a 24-hour context window, so an attack that spans two runs is still seen whole.

  2. It learns your normal.

    14-day baselines per IP, user and endpoint, in the Stockholm time zone, with daylight-saving days handled correctly.

  3. Ten detectors and a PII scan run.

    These are deterministic statistical rules with documented thresholds, not a black box.

  4. You get the report.

    Interactive HTML, Markdown for your records, a machine-readable JSON file, an audit file, and a short Slack / Mattermost / Telegram notification. A private dashboard lets you browse every run, compare trends and drill into any IP or user.

LogSentinel pipeline and data boundary

YOUR SERVER
  1. 01Access log
  2. 02Parse
  3. 03Normalise
  4. 04Baseline
  5. 05Detect (10)
  6. 06PII scan
  7. 07Geo (offline)
  8. 08Pseudonymise
  9. 09Report + audit trail

From Pseudonymise, the only arrow that leaves: pseudonymised summary only: no IPs, no user ids, no personnummer

LLM narrative (optional)
Everything inside the dashed line runs on your server. Run with --no-llm and nothing leaves at all.
What it finds

Built around how fintechs are actually attacked.

Attack detection: ten independent detectors

  • Brute force (per IP and distributed)

    Repeated login failures from one IP, or one account attacked from many IPs at once. Authorisation probing is reported separately.

  • Credential stuffing

    One source trying many different accounts with a high failure rate: the signature of a leaked password list.

  • Account takeover

    One customer account logging in successfully from five or more networks in a single day.

  • API abuse & race conditions

    Request rates no person produces, and duplicate POSTs fired milliseconds apart to beat limits.

  • Scraping & enumeration

    404 storms, mapping of your whole API surface, sequential ID harvesting.

  • Sensitive endpoints

    Probes for /.env, /.git, /admin, /actuator and your own payment, KYC and BankID endpoints, graded by outcome. A served .env is critical; a 404 is noise.

  • Bot timing

    Machine-regular request rhythm, in contrast with how irregularly people actually click.

  • User-agent & device anomalies

    Headless browsers, scripted clients, UA rotation, one device trying many accounts.

  • Round-the-clock activity

    Accounts or IPs active almost every hour of a Stockholm day, which a person doesn't do.

  • Search abuse

    Autocomplete traffic used to scrape. Ordinary search-as-you-type is never counted against your real users.

01Brute force

A burst that crosses the line

More than 10 failed logins from one IP in any rolling 60 minutes is flagged. The window slides, so a burst that straddles an hour boundary is still caught.

Failed logins from one IP in 60 minutes, by hourSample data
Brute force is flagged above 10 failures per IP in a rolling 60 minutes. Hours are Europe/Stockholm.
Peak failed logins from a single IP in any rolling 60 minutes, by clock hour. Threshold: more than 10 (sample data)
HourFailed loginsOver threshold
00:002no
01:001no
02:001no
03:000no
04:001no
05:002no
06:003no
07:004no
08:005no
09:006no
10:005no
11:004no
12:006no
13:005no
14:0041yes
15:0018yes
16:006no
17:005no
18:004no
19:003no
20:003no
21:002no
22:002no
23:001no

02Credential stuffing

Many accounts, mostly failing

One source that tries 15 or more accounts in an hour, with 60 % or more of the logins failing, looks like a leaked password list rather than a forgetful customer.

Share of logins that failed, per IPSample data
Flagged when an IP tries 15 or more accounts in an hour and 60 % or more of its logins fail.
Login failure rate per source IP in its busiest hour. Threshold: 60 % together with 15 or more accounts (sample data)
Source IP tokenFailure rate (%)Distinct accounts triedFlagged
USER_IP_00019122yes
USER_IP_0006172no
USER_IP_0003121no
USER_IP_000283no
USER_IP_000541no
USER_IP_000801no

03Across runs

See what changed since the last run

Each finding is reported once, not every six hours forever. The private dashboard compares runs, so a new kind of finding stands out from the usual background.

Findings per run, by severitySample data
Last 14 runs, oldest on the left. A finding is counted once, in the run where it first appeared or escalated.
Findings per run by severity, last 14 runs, oldest first (sample data)
RunCriticalHighMediumLowTotal
Run 101236
Run 200224
Run 301135
Run 411226
Run 500123
Run 601247
Run 701124
Run 800235
Run 902226
Run 1012339
Run 1101225
Run 1200123
Run 1301236
Run 1412238

Personal data in your logs: calibrated for Sweden

Findings describe the personal data. They never contain it: values are masked before anything is stored.

  • Personnummer and samordningsnummer

    Validated by Luhn check and calendar date, so order numbers and timestamps don't raise false alarms.

    Critical

  • Personnummer used as a user id

    Flagged without the number ever being stored in the finding.

    Critical

  • IBAN and card numbers

    IBAN (Swedish and all other countries, mod-97 validated) and card numbers (Luhn).

    Critical

  • E-mail, phone, BankID orderRef, Swish references

    E-mail addresses, phone numbers, BankID orderRef and Swish payment references.

    High

  • Secrets in query strings

    ?password=, ?api_key=, ?token=.

    Medium
Personal-data hits by type, one runSample data
Counts of requests whose URL carried the pattern. Values are masked before anything is stored.
Personal-data hits by type in one run, grouped by severity (sample data)
TypeHitsSeverity
Personnummer14critical
IBAN3critical
Card number1critical
E-mail9high
Phone5high
BankID orderRef4high
Swish reference2high
Secret in query string6medium
Sample incident reports

What a finding looks like.

Three excerpts modelled on the report LogSentinel writes. Every value is synthetic: documentation IPs, tokens and made-up counts.

Sample incident — synthetic dataexcerpt of a run report
HighCredential stuffingcredential_stuffing

One source tried 22 accounts on the login endpoint

Entity
USER_IP_0001IP address
First seen (Europe/Stockholm)
Thu 22 Oct 2026, 14:02 CEST
Last seen (Europe/Stockholm)
Thu 22 Oct 2026, 14:47 CEST

Evidence

Distinct accounts tried
22threshold: 15 or more per IP per hour
Auth failure rate
91 %threshold: 60 % or more
Auth requests
45 (41 failed, 4 answered 2xx)
Failures in rolling 60 min
41brute-force threshold: more than 10
Endpoint
POST /api/login
Sample accounts
USER_ID_0012, USER_ID_0013, USER_ID_0018
Login attempts per minute

Login attempts per minute from 14:00 to 15:00 Stockholm time: one or two a minute from 14:02 to 14:47, none before or after.

LLM narrative (excerpt)

USER_IP_0001 tried 22 different accounts against /api/login within 45 minutes and 91 % of the attempts failed, the signature of a leaked password list rather than people mistyping. Four attempts succeeded, so accounts such as USER_ID_0012 should be treated as exposed until their owners have reset the password.

This is what leaves your server: tokens only. The token table stays on your disk.

Recommended action

  1. Rate-limit or block USER_IP_0001 at your WAF or load balancer. 41 failed logins across 22 accounts in 45 minutes.

  2. Review the 4 accounts that answered 2xx and consider a password reset. A success after a stuffing run means the password was on the list.

LogSentinel detects and reports. Your team decides.

Audit trail

Log segment
bytes 48,213,904–49,102,377 (888,473 B), 5,214 new rows (+9,880 context)
Segment SHA-256
3f9a1c07e2…b14d58a6
Versions
LogSentinel 0.1.0 · detectors 7c1e90ab4d22f6a1 · config 5d08b3e1a97c40f2
LLM used
yes · called (accounts/fireworks/models/…)
Run
logsentinel_run_22102026-130500
Privacy

Your logs stay home. Seriously.

LogSentinel was designed for teams who have to answer "where does our customers' data go?" in writing.

Your server

  1. Raw log line

    203.0.113.24 - cust_48213 "GET /api/kyc/lookup?pnr=19121212-1212" 200

    Never leaves your server.

  2. Tokenise

    • 203.0.113.24becomesUSER_IP_0001
    • cust_48213becomesUSER_ID_0007
    • 19121212-1212becomesUSER_PNR_0003

    Stable tokens. The table that maps them back stays on your disk.

  3. Canary gate

    The payload is re-scanned for any identifier before it is sent. Fail-closed.

    • Clean: the summary is sent.
    • A value slipped through: the LLM step is skipped. The report is still written.

pseudonymised summary only

LLM narrative

optional

Receives
counts, categories, tokens, generalised paths
Never receives
raw log lines, IPs, user ids, personnummer
Run with --no-llm and nothing leaves at all. Example values only.
What leaves your server, and where it goes
WhatWhere it goes
Raw log linesNowhere. They never leave your server.
IPs, user ids, e-mails, phone numbers, personnummer, device fingerprintsNowhere. They are replaced by stable tokens (USER_IP_0001, USER_ID_0007…) before any external step. The token table stays on your disk.
Pseudonymised statistical summary (counts, categories, tokens, generalised paths)To the LLM for a written threat narrative, or nowhere if you run with --no-llm.
Country / hosting / VPN / Tor flagsComputed from local files. No IP lookups to external services.
NotificationSeverity, count and one line of narrative, tokens only.

Three safeguards

  • Fail-closed.

    Before anything is sent, the payload is re-scanned for identifiers. If one slipped through, the LLM step is skipped, the report is still written, and the log says why.

  • The AI can raise the alarm, never lower it.

    The LLM may increase a severity. It can never downgrade what the detectors found.

  • Owner-only files.

    Every report and state file is written readable by the owner only. The dashboard sits behind a login, is read-only, and never runs on a third-party host.

Pseudonymised data is still personal data under GDPR. The token table is the key, so treat it like the logs. Your DPO makes the final call; we give them the facts.

Built for audit

Evidence your auditor can verify.

Each run writes an audit record: the exact byte range of the log it analysed and the SHA-256 hash of those bytes, row counts, tool version, a hash of the detector code (every threshold is in it), a hash of the configuration, and whether the AI was used and which model. Six months later you can prove which lines were analysed, with which rules, and that nothing has been edited since.

When the analysis is incomplete (a detector failed, or your log shows proxy addresses instead of client IPs), the report opens with a "Read this first" banner. An incomplete report is never presented as clean.

audit.jsonSample data
run_id
logsentinel_run_22102026-130500
log.byte_start / byte_end
48,213,904 / 49,102,377
log.segment_sha256
3f9a1c07e2…b14d58a6
log.rows_new / rows_context
5,214 / 9,880
detectors.source_sha256
7c1e90ab4d22f6a1…
config_sha256
5d08b3e1a97c40f2…
tool_version
0.1.0
findings_reported
7
detector_failures
[]
llm.called
true
The hashes cover the exact bytes analysed, the detector code (every threshold is in it) and the configuration.

How LogSentinel supports your obligations

How LogSentinel supports your obligations
ObligationHow LogSentinel helps
DORA Art. 10, DetectionContinuous, scheduled detection of anomalous activity in your API traffic, with documented thresholds.
DORA Art. 9, Protection & prevention / Art. 6, ICT risk frameworkDated reports at the cadence you set, as recurring evidence that monitoring happens.
DORA Art. 17–19, Incident management & classificationTimestamped findings with severity, evidence and an audit hash, ready as input to incident classification and reporting.
DORA Art. 28, ICT third-party riskRuns on your infrastructure. No customer log data is processed by us, which keeps your third-party footprint small.
GDPR Art. 32, Security of processingFinds personal data leaking into URLs and logs, so you can fix the root cause.
GDPR Art. 25 & 5(1)(c), Privacy by design & data minimisationPseudonymisation by default, fail-closed, AI step optional.
GDPR Art. 33, Breach awarenessEarlier awareness of exposures that may start the 72-hour notification clock.
PSD2 / RTS on SCASupports monitoring for account takeover and credential attacks on your login and payment APIs.

Please note: LogSentinel supports these obligations. It does not make you compliant by itself. Your compliance function decides how it fits your framework.

Two audiences, side by side.

For the CTO

  • One container, no database, no agents. It reads the log file you already write.

  • Fast: millions of lines per run on a modest VM. Later runs only read what's new.

  • Explainable: deterministic rules, documented thresholds and an evidence panel for every finding. No "the model thinks…".

  • Quiet: each finding is reported once, not every six hours forever. Ordinary search-as-you-type traffic is never flagged.

  • Honest failures: a broken detector shows up in the report, the notification and the exit code. Nothing fails silently.

  • Under your control: --dry-run, --no-llm, --no-geo, JSON logs for your log stack, and an alias lookup when you need the real value behind a token.

For Risk & Compliance

  • No new data processor for log data. That's one less DPA and one less vendor-risk review.

  • Recurring, dated evidence of ICT monitoring, mapped to DORA and GDPR.

  • A verifiable audit trail: hash-proven input, versioned rules, a record of whether the AI was involved.

  • Swedish PII scan that finds personnummer, IBAN and BankID references where they shouldn't be.

  • Data minimisation built in: identifiers are tokenised before any external step, and 14-day retention by default.

  • A dashboard you can actually read: trends across runs, "what changed since last run", and drill-down by IP or user.

Why not a SIEM or a WAF

The right size for a regulated team of fifty.

  • Customer log data leaves your infrastructure

    Cloud SIEM
    Yes
    WAF / CDN rules
    Edge only
    Open-source DIY stack
    No
    LogSentinel
    No

  • Behaviour across hours and days (stuffing, takeover, bots)

    Cloud SIEM
    If you write the rules
    WAF / CDN rules
    Limited
    Open-source DIY stack
    If you write the rules
    LogSentinel
    Built in

  • Swedish PII scan (personnummer, IBAN, BankID, Swish)

    Cloud SIEM
    Build it yourself
    WAF / CDN rules
    No
    Open-source DIY stack
    Build it yourself
    LogSentinel
    Built in

  • Audit trail per run

    Cloud SIEM
    Varies
    WAF / CDN rules
    No
    Open-source DIY stack
    Build it yourself
    LogSentinel
    Built in

  • Time to first report

    Cloud SIEM
    Weeks
    WAF / CDN rules
    n/a
    Open-source DIY stack
    Weeks–months
    LogSentinel
    Same day

  • Who runs it

    Cloud SIEM
    A security team
    WAF / CDN rules
    Ops
    Open-source DIY stack
    An engineer, forever
    LogSentinel
    Cron
Pricing

Priced like a tool, not like a SOC.

Annual subscription per production environment. No per-seat fees and no per-GB metering, so you never pay more for logging properly.

  • Snapshot

    Fixed price, on request

    100 % credited to a first-year subscription signed within 60 days

    Scope
    30 days of your logs, analysed on your server in a guided session
    All 10 detectors + Swedish PII scan
    Included: All 10 detectors + Swedish PII scan
    HTML / Markdown / JSON reports, audit trail
    Included: HTML / Markdown / JSON reports, audit trail
    Dashboard (trends, explorers, change view)
    Demo
    Slack / Mattermost / Telegram notifications
    Not included: Slack / Mattermost / Telegram notifications
    Updates and new detectors
    Not included: Updates and new detectors
    Findings read-out with your team
    1 × 90 min
    Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Not included: Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Onboarding and baseline tuning
    Not included: Onboarding and baseline tuning
    Support
    Not included: Support
    Auditor / supervisor Q&A support
    Not included: Auditor / supervisor Q&A support
    Start with a Snapshot

  • Monitor

    Contact us

    Billed annually

    Scope
    1 production environment
    All 10 detectors + Swedish PII scan
    Included: All 10 detectors + Swedish PII scan
    HTML / Markdown / JSON reports, audit trail
    Included: HTML / Markdown / JSON reports, audit trail
    Dashboard (trends, explorers, change view)
    Included: Dashboard (trends, explorers, change view)
    Slack / Mattermost / Telegram notifications
    Included: Slack / Mattermost / Telegram notifications
    Updates and new detectors
    Included: Updates and new detectors
    Findings read-out with your team
    Not included: Findings read-out with your team
    Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Not included: Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Onboarding and baseline tuning
    Self-serve docs
    Support
    E-mail, next business day
    Auditor / supervisor Q&A support
    Not included: Auditor / supervisor Q&A support
    Talk to us about Monitor

  • Compliance

    Most chosen

    Contact us

    Billed annually

    Scope
    Up to 3 environments
    All 10 detectors + Swedish PII scan
    Included: All 10 detectors + Swedish PII scan
    HTML / Markdown / JSON reports, audit trail
    Included: HTML / Markdown / JSON reports, audit trail
    Dashboard (trends, explorers, change view)
    Included: Dashboard (trends, explorers, change view)
    Slack / Mattermost / Telegram notifications
    Included: Slack / Mattermost / Telegram notifications
    Updates and new detectors
    Included: Updates and new detectors
    Findings read-out with your team
    Quarterly
    Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Included: Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Onboarding and baseline tuning
    Guided
    Support
    Priority, same business day
    Auditor / supervisor Q&A support
    1 session / year
    Talk to us about Compliance

  • Assurance

    Contact us

    Annual, custom

    Scope
    Unlimited environments
    All 10 detectors + Swedish PII scan
    Included: All 10 detectors + Swedish PII scan
    HTML / Markdown / JSON reports, audit trail
    Included: HTML / Markdown / JSON reports, audit trail
    Dashboard (trends, explorers, change view)
    Included: Dashboard (trends, explorers, change view)
    Slack / Mattermost / Telegram notifications
    Included: Slack / Mattermost / Telegram notifications
    Updates and new detectors
    Included: Updates and new detectors
    Findings read-out with your team
    Monthly
    Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Included: Compliance pack: DORA/GDPR mapping, DPIA & legitimate-interest templates, vendor questionnaire answers, data-flow diagram
    Onboarding and baseline tuning
    Guided + on-site (Stockholm)
    Support
    Named contact, agreed SLA
    Auditor / supervisor Q&A support
    Included
    Talk to us about Assurance
FAQ

Questions we are asked first.

Do our logs or customer data ever leave our servers?

No raw log lines and no customer identifiers. The only optional outbound step is a pseudonymised statistical summary sent to an LLM for a written narrative. It is re-scanned before sending and blocked if anything identifying remains. Run with --no-llm and nothing leaves at all.

Which LLM do you use, and where is it?

Today: Fireworks AI, called with your own API key, so you have the contract with them directly. You can see exactly what was sent: every run saves the payload next to the report.

Can the AI invent or hide findings?

It can't hide them. The AI can raise a severity, never lower one, and every finding comes from a deterministic detector with evidence attached. The narrative is clearly separated from the detector findings.

We already have a WAF / Cloudflare.

Keep it. A WAF judges requests one at a time at the edge. LogSentinel looks at behaviour across hours and days at the account level: credential stuffing spread over an afternoon, one customer logging in from five networks, a personnummer in a URL. You need both.

We already send logs to Datadog / Elastic.

LogSentinel can run next to them on the same log file. It adds fintech-specific detectors, a Swedish PII scan and audit evidence, without writing rules yourself.

Does it block attackers automatically?

Not today, on purpose. LogSentinel detects and reports, and your team decides. A machine-readable hand-off file for your WAF and fraud teams is on the roadmap.

RoadmapMachine-readable hand-off file. Not available today.

What do we need to run it?

A Linux server or VM with Docker, read access to your API access log, and roughly 1 KB of RAM per log line in a run (about 2 GB for 2 million lines). Scheduling is a cron line.

Our logs sit behind a load balancer. Does that matter?

It matters, and LogSentinel tells you. If most client addresses look like proxy or CDN addresses, the report opens with a warning so you can log the real client IP before trusting per-IP findings.

Who can see the reports?

Only you. Reports are written owner-only on your server. The dashboard is read-only, sits behind a login with rate limiting, and is meant for localhost or your VPN, never a public host.

How long is data kept?

Reports and baseline history are kept for 14 days by default. A built-in clean command deletes older runs, and you can configure the period.

Does this make us DORA compliant?

No tool does that on its own. LogSentinel gives you detection and evidence that fit inside your ICT risk framework. The Compliance tier includes a mapping document your compliance function can use directly.

Find out what your logs are hiding, this week.

Start with a fixed-price PII & Threat Snapshot. We run LogSentinel on your server, together with your team, on 30 days of your own logs. Your data never leaves your infrastructure, and you keep the report. If you subscribe within 60 days, the full fee is credited.

Order a SnapshotBook a 30-minute demo

Write to [contact e-mail]