DEV Community: DEVALAND

Actively exploited this week: 6 new CISA KEV entries (28 September to 4 October 2026)

DEVALAND — Mon, 05 Oct 2026 07:33:07 +0000

Every week CISA adds vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalogue. The bar for getting on that list is not "severe on paper" but "attackers are using it now". For a small team with limited patching hours, that makes KEV the most useful priority list there is.

Below: every entry added between 28 September and 4 October 2026, copied from the catalogue and linked to its NVD record, plus what Romania's national cyber security directorate and Have I Been Pwned published in the same days. Nothing is estimated or rewritten.

The 6 actively exploited vulnerabilities added this week

Added	Product	CVE	Known ransomware use
4 Oct	Citrix NetScaler Improper Restriction of Operations within the Bounds of a Memory Buffer Vulnerability	CVE-2026-88779	not known
2 Oct	Zammad GmbH Zammad Improper Privilege Management Vulnerability	CVE-2026-102490	not known
2 Oct	Zammad GmbH Zammad Session Fixation Vulnerability	CVE-2026-102489	not known
1 Oct	Fortinet FortiMail Path Traversal Vulnerability	CVE-2026-104286	not known
30 Sep	Cisco Catalyst SD-WAN Manager Hex Encoding Vulnerability	CVE-2026-76504	not known
29 Sep	Apple Multiple Products Out-of-Bounds Write Vulnerability	CVE-2026-86950	not known

What Romania's DNSC flagged the same week

Alerts from DNSC, Romania's national cyber security directorate, with their original titles in Romanian:

ALERTĂ: Vulnerabilitate critică la nivelul Fortinet FortiMail, 2 October
ALERTĂ: Vulnerabilități critice exploatate activ în Citrix NetScaler, 28 September

When a national authority and CISA point at the same product in the same week, that product goes to the top of the queue.

Breaches added to Have I Been Pwned

Medela: 423,947 accounts, added 30 September. Check the breach page

If your team's work addresses may be in one of these, check the breach page and the password reuse question, not only the address.

How to use a list like this in an hour

Start with what faces the internet. VPN and access gateways, firewalls, routers, mail servers and public web platforms are how many ransomware incidents start.
Search your inventory by product name, not by memory. "We don't run that" is a claim, and the asset list is the evidence.
Patch or apply the vendor mitigation, then confirm the version. A patch that was downloaded but not applied reads as done in a ticket and is still exploitable.
If you cannot patch today, reduce exposure: restrict the management interface to known addresses, disable the affected feature, or put the service behind an access gateway you trust.

Where this comes from

A small collector reads official sources every hour: DNSC, CERT-EU, CERT-FR (ANSSI), CERT-Bund (BSI), the UK NCSC, CISA KEV, Have I Been Pwned and three specialist newsrooms. It copies each item exactly, with its source link, and publishes the result on one page:

https://devaland.cloud/alerte-live.html (in Romanian, with every title kept in its original language).

Nothing on that page or in this post is written by a model. A security page that paraphrases an advisory wrongly does more harm than no page at all.

Sources: CISA KEV catalogue (dateAdded 2026-09-28 to 2026-10-04), DNSC alerts, Have I Been Pwned. Generated from the sources on 2026-10-05.

Four Controls That Turn an AI Agent From a Demo Into a System

DEVALAND — Sun, 04 Oct 2026 13:01:27 +0000

A chatbot answers. An agent acts: it searches a document, fills in a form, drafts the reply and sends it. Because it acts, it needs rules before it needs features.

Two guides on AI agents published by Sifted in 2026, one sponsored by Box and one by Salesforce, collect the experience of companies that got past the pilot stage. Strip out the product names and the same four controls appear in both. Each one is a question you can put to any vendor, including us.

1. Scoped access, time-bounded, fully logged

The clearest version comes from Box's chief information security officer, Heather Ceylan: agents should never have broad standing access just because they are useful. Permissions should be scoped to a task, time-bounded where possible, and fully logged.

The question to ask: what exactly can the agent read and change, and who can see what it touched? If the answer is "everything", that is not an answer.

2. A second check

Agents make mistakes, and the guides say so plainly. One founder describes them as "well-intentioned, slightly forgetful children". The teams that got past the pilot all added a second step. Either a person approves before anything leaves the building, or a separate evaluator checks the first agent's work independently and scores its confidence.

One London company in the Box report, Deliverance, builds this in as a pair of agents: an executor that does the work and an evaluator that critiques it. Its founder's summary is worth borrowing: "It's not magic. It's a governed system."

The question to ask: what checks the output before a customer sees it?

3. Rules for when it does not know

A reliable agent knows when not to act. That matters more than being right most of the time, because an agent that recognises its limits does far less damage than one that is merely usually correct. The rules are written in advance: if it cannot find the source, it says so; if confidence is low, it asks a human; if money or an upset customer is involved, it escalates.

Then test exactly those cases. The tidy requests almost always work. The oddly phrased ones are where the failures are.

The question to ask: show me what it does with a request it cannot answer.

4. A log of every step

For each run: what the agent received, what it used, what it produced. When something goes wrong, the log tells you whether the input was bad, the instructions were unclear or a tool failed, instead of guessing. It is also what lets you answer, months later, where a particular answer came from.

The question to ask: if I pick any answer from last week, can you show me its sources?

What this means in practice

These are the rules we build to at Devaland. Our assistants answer from the client's own documents, cite the source behind every claim, and say plainly when they cannot find one. We do not present that as a guarantee. We present it as something you can verify yourself, on every single answer.

Sources

Sifted, "The rise of AI agents", June 2026 (sponsored by Box). Sifted, "The startup agentic AI playbook", August 2026 (sponsored by Salesforce).

Originally published on devaland.com: Four Controls That Turn an AI Agent From a Demo Into a System

I told a friend a number was not in her document. It was on page 6, sideways.

DEVALAND — Fri, 02 Oct 2026 06:19:43 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

everypage is a small tool that answers questions about a PDF using a model that runs on your own machine. It names the page for everything it says, and when it could not read a page it tells you that instead of telling you "no".

I built it for a friend. She is not technical. She has a folder of family property papers, some printed from a computer, some scanned, some scanned lying on their side. She asks me the kind of question anyone asks about a contract: does it say this anywhere?

A while ago she asked me one of those, and I answered "no, that figure is not in the document". I had searched the text. The text I searched ended at page 4. The figure was on page 6, on a scanned page that my extraction had quietly skipped. Nothing warned me. A document with two missing pages looks exactly like a complete document that does not contain the thing.

She trusted my "no". That is the bug I wanted to fix, and it is not a model bug. It is a reading bug.

So the tool has three answers, never two:

verdict	what it means
FOUND	here is the sentence, and here is the page it is on
NOT FOUND	every page was read, and it is not there
CANNOT SAY	it was not on the pages I could read, but there are pages I could not read

Demo

A real run of the five commands below, recorded on a CPU with gemma2:2b. Only the waits for local inference are cut, and each cut is labelled on screen. MP4 version.

The sample is an invented 6-page sale agreement (every name, place and amount is made up). Pages 1 to 3 have a text layer. Pages 4 and 5 are scans. Page 6 is a scan lying on its side, and it is the only page that mentions unpaid taxes.

First, the usual way: extract the text, give it to the model, ask.

$ python3 demo/naive.py samples/sale-agreement.pdf "Are there unpaid property taxes, how much, and who has to pay them?"
NAIVE: pdftotext returned 1449 characters and no warning
NAIVE ANSWER: The provided document does not contain information about unpaid property taxes,
their amount, or who is responsible for paying them.

That is a confident, fluent, wrong answer, and the model did nothing wrong. It was handed half a document.

Now the same model, the same question, through everypage:

$ python3 -m everypage read samples/sale-agreement.pdf
COVERAGE: read 6 of 6 pages
  page 1   text-layer   591 chars  legibility 0.54  OK
  page 2   text-layer   446 chars  legibility 0.56  OK
  page 3   text-layer   408 chars  legibility 0.67  OK
  page 4   ocr          384 chars  legibility 0.48  OK
  page 5   ocr          225 chars  legibility 0.41  OK
  page 6   ocr          459 chars  legibility 0.68  rotated 90°  OK

$ python3 -m everypage ask samples/sale-agreement.pdf "Are there unpaid property taxes, how much, and who has to pay them?"
COVERAGE: read 6 of 6 pages
ANSWER: Unpaid property taxes total $18,450. (page 6) The seller must pay this amount before closing. (page 6)
If the seller does not pay the unpaid taxes by closing, the buyer may deduct $18,450 from the price and pay
the county directly. (page 6)
  page 6 (ocr): "Property taxes for the years 2022, 2023 and 2024 remain unpaid in the total amount of $18,450."
  page 6 (ocr): "The Seller shall pay this amount in full before closing."
  page 6 (ocr): "If the Seller has not paid the unpaid taxes by closing, the Buyer may deduct $18,450 from the price and pay the county directly."
VERDICT: FOUND.

A question whose honest answer is no:

$ python3 -m everypage ask samples/sale-agreement.pdf "Does the agreement say anything about a broker commission?"
COVERAGE: read 6 of 6 pages
VERDICT: NOT FOUND. All 6 of 6 pages were read, so this is a real negative.

And the case that started all this. Same agreement, but page 6 is blurred past reading:

$ python3 -m everypage ask samples/sale-agreement-damaged.pdf "Are there unpaid property taxes, how much, and who has to pay them?"
COVERAGE: read 5 of 6 pages; could NOT read page(s) 6
VERDICT: CANNOT SAY. Nothing found on the pages that were read, but page(s) 6 could not be read. This is NOT a 'no'.

That last line is the whole project. It is the sentence I should have said to her.

Code

MariusGithub13 / everypage

Ask a PDF a question with a local model. It names the page, and says which pages it could not read.

everypage

Ask a question about a PDF and get an answer that names its page, from a model that runs on your own machine If a page could not be read, it says so instead of saying "no".

It was built for one person: a friend with a folder of property papers, part printed, part scanned, some scanned sideways. Her question is usually "does it say X anywhere?". The honest answers to that are three, not two.

verdict	meaning	exit code
`FOUND`	here is the sentence, here is the page	0
`NOT FOUND`	every page was read, and it is not there	1
`CANNOT SAY`	it was not on the pages I could read, but some pages I could not read	2

A real run on the invented sample, recorded 02.10.2026. Only the waits for local inference are cut, and each cut is labelled on screen. MP4 version.

What

…

View on GitHub

https://github.com/MariusGithub13/everypage (MIT). About 300 lines of Python, no framework. The tests run without a model.

How I Built It

The model is Gemma, running locally. gemma2:2b (1.6 GB) served by Ollama on localhost. OCR is Tesseract, PDF handling is Poppler. All open, all on the machine.

A 2-billion-parameter model is small, and that shaped the design. I did not ask it to be reliable. I asked it to do one easy thing, and I made the code responsible for everything that has to be true.

1. The code reads, and keeps the receipts. Each page is read on its own. If it has a text layer, that is used. If not, the page is rendered at 300 dpi and OCR'd. If the result does not look like language, it is retried at 90, 270 and 180 degrees and the best reading wins. Every page ends as OK or UNREADABLE, and the coverage line is printed before anything else.

2. The model sees every page, one at a time. There is no retrieval step choosing which chunks are "relevant". On a short legal document, the page a retriever skips is the addendum. It is slower. With this small model on a single CPU core it is roughly 15 to 20 seconds a page, so about two minutes for six pages, and my friend's question is worth two minutes.

3. The model must quote, and the code checks the quote. For each page the model returns up to three sentences copied from that page. The code looks for each one on the page, character for character after normalising spaces and case. A sentence that is not there is thrown away, whatever the model says about it. The final answer is written only from sentences that survived, each with its page.

4. The model is never allowed to say "it is not there". If nothing survived, the code decides: all pages read means NOT FOUND, anything less means CANNOT SAY. The exit codes are 0, 1 and 2, so a script cannot confuse them either.

The bug I shipped to myself on the way. My first legibility check counted words that contain a vowel. I ran it on the sideways page and it reported legibility 0.96 and status OK. The "text" it had approved was this:

pebueyoun urewel JuoweeIby oY} Jo SULI9} 1940 [[V

That is the page read upside down. Upside-down English is full of vowels. The blurred page scored a perfect 1.00 with ee ee mee ON me mere me. So the check that existed to catch unreadable pages was passing them with top marks, which is the original bug wearing a badge. The fix was to stop asking "does this look like words" and ask "does this contain the small everyday words real prose is made of": the, of, and, shall. Upside-down text scores 0.03 on that, real pages score 0.4 to 0.7, and both failures are now tests.

I used AI coding agents to help write and test this. The design rules and the failure they come from are mine.

Why Does Open Innovation Matter?

Three reasons, all practical.

The papers never leave the machine. Property papers, family papers and medical papers are the documents people most need help with and least want to upload to a server they do not control. With an open-weight model on localhost that question does not come up. It works with the network cable out.

I can put the rules outside the model. Because everything runs in my own process, the model's output is just a string my code can check against the page before anyone sees it. The guarantee does not depend on a provider's settings, a prompt that might be ignored, or a model version that changes under me next month.

It costs nothing to run, so "read every page" is affordable. Showing every page to a model one at a time is wasteful by API standards. Locally the only cost is a couple of minutes of CPU, so I can choose thorough over clever.

A closed model would have given a more polished paragraph. It would not have fixed my bug, because my bug was never the paragraph.

Limits, and one thing I will not do

She should not have to install anything, so I run it on her papers at my end and send her the answer with the page numbers. What she says about it stays between us. I am not going to quote her here.

So nobody is surprised: PDFs only. The legibility word list is English, so other languages need their own list (pages get marked unreadable otherwise, which is the safe way to be wrong). A page that is all numbers gets marked unreadable for the same reason. And a verified quote proves the words are on the page, not that the model understood them. Read the quote. This is a reading aid, not legal advice.

Prize Categories

Best Use of Gemma: gemma2:2b runs locally and is the only model in the project.

My Staleness Checker Flagged Sixteen Tasks. I Acted on Four of Them Anyway.

DEVALAND — Thu, 01 Oct 2026 14:00:06 +0000

On 20 July I served myself two dead tasks as if they were live. One told me to chase a contact at a
deal that had closed months earlier. The other told me to stay quiet and wait for a call that had
already happened, and gone nowhere. Both came out of the same file: a running list of open threads
that my operations run against.

So that afternoon I wrote a checker. Every open line in that file has to carry a tag naming the
project note it comes from and the date it was last reconciled. The script compares that date
against the modification time of the note itself. If the note changed after the line was last
checked, the line is stale: the decision moved on and the reminder did not. It also catches lines
with no tag at all, and lines pointing at a note that no longer exists.

It works. I ran it this morning. Fifty-eight open lines, sixteen flagged.

Then I acted on one of the flagged lines anyway. And then three more.

The check was never the problem

Read the script and there is nothing to fix. It parses correctly. It classifies into three states
that are genuinely different from each other. It prints the offending line with its note and both
dates, so you can see exactly why it fired.

It even exits with status 1 when anything is unreconciled, and 0 when the file is clean. That is the
oldest convention in computing for "do not proceed."

Nothing reads that exit code.

I went looking today. Nothing calls the script. No scheduled job, no wrapper, no step that runs it
and stops if it fails. The only two places on the machine that mention it at all are the script
itself and a paragraph inside the very file it polices, which says that it must be run first and
that flagged lines must not be surfaced as actions.

So the enforcement mechanism was a sentence, sitting next to the thing it governed, asking whoever
came past to behave.

What that cost, in one morning

I run my operations through an AI agent with a persistent memory of the business. It read that
paragraph. It ran the checker. It received sixteen flags. It then surfaced four of them to me as
work to do.

The first was a supplier setting I had changed the previous evening and confirmed on screen.

The second was an account item that had been closed four days earlier, where the correct standing
instruction in my own notes was to wait, and where a note explicitly recorded that chasing had
already been stopped once for exactly this reason.

The third was a message to my accountant that I had already sent twice, on two separate days, and
had explicitly closed with "nothing urgent, we'll sort it when you're back."

The fourth is the one that matters. It was a drafted email to a government directorate, ready to
send, telling them I could not find a document on their site. Five days earlier I had written to the
same people saying I had downloaded that document and read it in full. Both of my follow-up
questions had been answered the same day.

I caught all four. Not because the checker stopped anything, but because I happened to remember. The
fourth one I caught with the draft already written and one click from going out.

The shape of this failure

I published something last week about a counter in a different system that merged two opposite facts
into one comforting number. This is the same bug wearing different clothes.

There, a metric reassured me while a feature was dead. Here, a checker produced a correct verdict and
nothing was obliged to consume it. In both cases the machinery was right and the wiring was absent.
In both cases the output felt like protection, and protection is exactly what it was not.

A check that reports is documentation. A check that blocks is a control. I had built the first and
believed I had built the second, and the belief is the expensive part, because it stops you looking
for the real one.

The fix is not a better checker

There is nothing to improve in the script. The three things worth doing are all about who is forced
to listen.

Make the flagged lines unreadable rather than merely labelled. If a line cannot be reconciled, the
process that reads the file should not receive it at all. Filtering at the source beats a warning at
the destination, because a warning depends on the reader's discipline and a filter does not.

Give the exit code a consumer. A non-zero status that nothing checks is a refusal shouted into an
empty room. Either something branches on it or it should not be there, because its presence implies
a contract that does not exist.

And stop writing enforcement as prose. The instruction "run this first and do not surface flagged
lines" was in the right place, correctly worded, and read by the thing it was aimed at. It still did
not hold. Rules that live next to the work are advice. Rules that gate the work are rules.

What I would take from this

If you have a linter nothing fails on, an alert nobody is paged for, a policy document, or a review
step that can be skipped when the day is busy, you have what I had. It will pass every test you give
it, because it does its job perfectly. Its job simply is not the job you think you assigned.

The question worth asking about any safeguard is not whether it detects the thing. Mine detected it,
sixteen times, in clear language, on the correct morning. The question is what physically cannot
happen while it is unhappy.

If the answer is nothing, you do not have a safeguard. You have a very reliable narrator.

Originally published on devaland.com: My Staleness Checker Flagged Sixteen Tasks. I Acted on Four of Them Anyway.

A Rule You Can Recite Is Not a Rule That Runs

DEVALAND — Mon, 28 Sep 2026 14:00:05 +0000

My outbound system reported "17 letters out, no bounces" this morning. One of them had bounced seven seconds after it left.

It was a batch of freedom of information requests to local councils. After every letter the system waits 150 seconds, asks the mailbox whether anything bounced, and stops the whole batch if something did. That rule sits in the first lines of the script. I could recite it.

For at least twelve days it had not been able to read.

Two guards, each correct on its own

The bounce check asked the mailbox for up to 500 messages. Two weeks earlier I had built a second safety guard, one that refuses any mailbox read bigger than the provider's per-minute quota, so the system can never lock itself out of sending. 500 messages cost about 10,000 quota units. The limit is 6,000 per minute. So the new guard refused the bounce check. Every single time.

The refusal went to the error stream. The bounce check read only the normal output, found it empty, and treated empty as "no bounce". Two guards, each correct on its own, and one had quietly blinded the other.

What it cost

On 8 September it had already missed a bounce. That one was caught the next day by a person reading the inbox, not by the check. Today the bounce landed at 10:28, and the batch sent the next letter 150 seconds later as if nothing had happened. I stopped it by hand.

Then the part I like least. With the check fixed and the batch finished, the summary still said "no bounces". It counted only the run it was in, and the bounce belonged to the run I had stopped.

What changed

The check now has three answers, not two: bounced, clear, could not read. The third one stops the batch.
It asks for 50 messages, which fits the quota.
It is tested on the real cases, with the real function, not a copy of it: the bounced address says bounced, a delivered one says clear, a broken read says stop. The video above is that test, replayed.
The summary counts bounces from the batch's own record, not from the current run.

The question to ask of every check

A newsletter I read today put it better than I can: a standard with no enforcement becomes an opinion you hold about yourself. Mine had enforcement. It just could not see.

Most checks are written for two outcomes, pass and fail. The dangerous case is the third one, when the check could not look at all, because a failed read and a clean result usually print the same thing: nothing. So the question is not "does this check pass?" but "what does this check say when it cannot read?" If the answer is "the same as when everything is fine", it is not a check yet.

When we build a pipeline for a client, that is one of the questions we put to every step that reads from somewhere else: a mailbox, an API, a scanned document, a queue. A read that fails has to stop the line, visibly, instead of passing as a clean result.

Which of your safety checks would tell you if it had stopped being able to read?

Originally published on devaland.com: A Rule You Can Recite Is Not a Rule That Runs

NIS2 in Romania: how registration with DNSC works, step by step

DEVALAND — Sun, 27 Sep 2026 07:54:25 +0000

If you run infrastructure for a company or an institution in Romania, sooner or later someone asks: do we have to register with DNSC for NIS2, and how? Romania transposed NIS2 through Emergency Ordinance (OUG) 155/2024, approved with amendments by Law 124/2025. Entities that qualify as essential or important must register with the national authority, DNSC.

Below are the steps exactly as DNSC describes them on its own site. This is a map of the process, not legal advice.

First: are you in scope?

Not every organisation is. What matters is the sector (annexes 1 and 2 of the ordinance) and, in most cases, the size of the organisation. The consolidated text is on legislatie.just.ro. DNSC also publishes a guide for the "disruptive effect" self-assessment under article 9, and answers questions about identification, changes or deregistration at nis@dnsc.ro.

Whether you are in scope is a legal call for management and a lawyer. It is not something an IT supplier, including us, should decide for you.

Step 1: the notification form

The form is generated only on the NIS2@RO platform, or, when the platform is unavailable, with the NIS2@RO tool, a file you download from dnsc.ro and run locally. An English version of the tool exists to help you understand the fields, but the form is submitted in Romanian.
Save it as PDF and have the legal representative sign it: a qualified electronic signature for electronic filing, or a handwritten signature on paper.
Send it, with any supporting documents, to evidenta@dnsc.ro, or file it on paper at DNSC's office in Bucharest.
If you could not register on the platform because it was down, you must create an account once it becomes available.

Step 2: the risk level assessment

Until the platform is fully operational, the risk assessment is produced with the ENIRE@RO tool, again downloaded and run locally. The report is saved as PDF, signed the same way and sent to evidenta@dnsc.ro or filed on paper, together with a justification if you changed any default values.

Step 3: the maturity self-assessment

Based on the ENIRE@RO score validated by DNSC, you use the self-assessment tool for your security level: Basic (EVAL_MMS_B), Important (EVAL_MMS_I) or Essential (EVAL_MMS_E). The PDF report is signed by the legal representative or a designated member of management, and emailed to evidenta@dnsc.ro together with the Excel file it was generated from. If the report is signed by hand on paper, the Excel file still goes by email.

Contacts DNSC lists for this process

evidenta@dnsc.ro: notification forms and reports
nis@dnsc.ro: help with identification, changes or deregistration
Phone, Records and Support: +40 316 202 167; Verification and Control: +40 316 202 156
Office: Strada Italiană 22, Sector 2, 020976 Bucharest

Registration is not incident reporting

Incidents go to the national platform PNRISC or to 1911, 24/7. DNSC notes that a PNRISC report does not replace a criminal complaint where one is needed.

The original, in Romanian: devaland.cloud. Sources: DNSC's pages "Înregistrare entități" and "Obligațiile entităților înregistrate" under Directiva NIS on dnsc.ro, the PNRISC platform and OUG 155/2024, checked 27 September 2026. We are a software company: we do not classify organisations under the ordinance or fill in these assessments.

ClickFix, explained with a Romanian fairy tale: the attack where you run the malware yourself

DEVALAND — Sun, 27 Sep 2026 07:54:24 +0000

Romania's National Cyber Security Directorate (DNSC) launched a campaign on 26 September 2026 called "Basme cu tâlc digital", fairy tales with a digital moral. The first one retells Ion Creangă's classic "The Bear Fooled by the Fox", and the attack it explains is ClickFix.

It is aimed at children. The trap works exactly the same on an adult at a work laptop, which is why it is worth a few minutes of any team's time.

The story in one line

In Creangă's tale the fox never attacks the bear. It convinces him to put his own tail through the ice to catch fish. DNSC's summary, as quoted by Mediafax: "The fox does not force the bear to put its tail in the hole. It convinces him it is the best choice."

ClickFix is the same move. The attacker does not break into the machine. They get the user to do the one step that compromises it.

How the trap works

A web page shows a message that looks like a normal system or browser notification.
It claims there is a technical error, an update to install, or that you must prove you are not a robot.
It asks you to copy some text and run it yourself, usually in the Windows Run box, in PowerShell, or in Terminal on macOS and Linux.
The text is a command that installs malware in the background. According to DNSC, that can give the attacker access to personal data, passwords and files.

It works because each step looks like routine troubleshooting, and the message adds urgency.

What DNSC recommends

Do not run commands you do not recognise.
Do not paste code into Terminal, PowerShell or Command Prompt unless you understand what it does.
Treat any "urgent" or "mandatory" technical step with suspicion.
Stop and ask for help before following instructions like these.

For a team, in one rule

If you look after other people's machines, the cheapest control is a sentence, written down and sent to everyone: nobody runs a command they got from a web page or a message, however official it looks. Add who to ask when it happens, so nobody feels they have to fix it alone.

In Romania, incidents are reported to DNSC at 1911 (24/7) or on the national platform PNRISC. DNSC notes that a PNRISC report does not replace a criminal complaint where one is needed.

The original article, in Romanian, with a section for public institutions: devaland.cloud. Sources: Mediafax and Go4IT on the DNSC campaign, checked 27 September 2026. The DNSC quote is translated from the Mediafax report.

10 vulnerabilities attackers are exploiting right now: what to patch this week (21 to 25 September 2026)

DEVALAND — Sun, 27 Sep 2026 06:13:31 +0000

These are the ten entries added between 21 and 25 September 2026, copied from the catalogue, each linked to its NVD record. Nothing below is estimated or rewritten.

The ten actively exploited vulnerabilities added this week

Added	Product	CVE
25 Sep	MikroTik RouterOS, improper enforcement of behavioral workflow	CVE-2026-67279
25 Sep	Microsoft SharePoint, code injection	CVE-2026-65660
25 Sep	WordPress Core, remote file inclusion	CVE-2026-87902
24 Sep	WSO2 multiple products, path traversal	CVE-2026-5430
24 Sep	Adobe Commerce and Magento, incorrect authorization	CVE-2026-71362
22 Sep	Arista VeloCloud Orchestrator, improper input validation	CVE-2026-93952
22 Sep	F5 BIG-IP APM, heap-based buffer overflow	CVE-2026-94127
22 Sep	Check Point multiple products, path traversal	CVE-2026-93616
22 Sep	Check Point multiple products, improper certificate validation	CVE-2026-85102
21 Sep	Zyxel GS1900 series switches, stack-based buffer overflow	CVE-2026-7273

What European authorities flagged the same week

Romania's national cyber security directorate, DNSC, issued two alerts that overlap with the list above:

a critical, actively exploited vulnerability in F5 BIG-IP APM (CVE-2026-94127), on 23 September;
a critical vulnerability in WordPress Core, on 24 September.

When a national authority and CISA point at the same product in the same week, that product goes to the top of the queue.

A breach worth checking your address against

LimeLeads was added to Have I Been Pwned on 22 September with 17,838,396 accounts. If your team's work addresses ever went into a B2B lead database, check the breach page and look at the password reuse question, not only the address.

How to use a list like this in an hour

Start with what faces the internet. Seven of the ten entries sit at the edge: VPN and access gateways (F5 BIG-IP APM, Check Point), SD-WAN orchestration (VeloCloud), routers and switches (MikroTik, Zyxel), and public web platforms (WordPress, Magento). An exploited edge device is how many ransomware incidents start.
Search your inventory by product name, not by memory. "We don't run SharePoint" is a claim, and the asset list is the evidence.
Patch or apply the vendor mitigation, then confirm the version. A patch that was downloaded but not applied reads as done in a ticket and is still exploitable.
If you cannot patch today, reduce exposure: restrict the management interface to known addresses, disable the affected feature, or put the service behind an access gateway you trust.

Where this comes from, and how to get it every hour

We run a small collector that reads official sources every hour: DNSC, CERT-EU, CERT-FR (ANSSI), CERT-Bund (BSI), the UK NCSC, CISA KEV, Have I Been Pwned, and three specialist newsrooms. It copies each item exactly, with its source link, and publishes the result on one page:

https://devaland.cloud/alerte-live.html (in Romanian, with every title kept in its original language).

Nothing on that page or in this post is written by a model. That was a deliberate choice: a security page that paraphrases an advisory wrongly does more harm than no page at all. If you want the DNSC alerts and new actively exploited vulnerabilities by email within the hour, there is a double opt-in form on the same page, at most one email every six hours, and a one-click unsubscribe.

If the worst has already happened, our checklist for the first 60 minutes after a ransomware attack (in Romanian) follows the published guidance from DNSC, the NCSC and No More Ransom.

Sources: CISA KEV catalogue (dateAdded 21 to 25 September 2026), DNSC alerts of 23 and 24 September 2026, Have I Been Pwned (LimeLeads, added 22 September 2026). Checked on 27 September 2026.

The page with the answer was missing. Half the models added up a total the document never states.

DEVALAND — Fri, 25 Sep 2026 07:27:03 +0000

This is a submission for the Kaggle Benchmarking Challenge.

What I benchmarked, and why

The most expensive mistake in document work is not a wrong answer. It is a confident answer about a document that was only partly read.

I run a small software company that builds document pipelines, and I have made this mistake myself, with tooling, more than once. A PDF whose first twelve pages were scans with no text layer, read as if the text layer were the whole document. A command that printed the first 120 lines of a six-page deed, after which a search of those lines "proved" a figure was absent. It was on page 6. A public-records response whose landscape pages came out of OCR as column debris, summarised as four items when it listed more than twenty-five.

In every case the reader could have known. The footer said "Page 4 of 6". The extraction printed an empty page marker. The contents listed a section that never arrived.

So the benchmark asks one narrow question: when the part of a document that would answer the question never reached the model in readable form, does the model notice?

How it works

Six synthetic documents: a property deed, a public-records response, a tender specification, a service contract, an account statement and board minutes. Every party, place and number is invented. Each is six pages, and the answer lives on one known page.

Each document is shown under seven reading conditions:

condition	what the model receives	correct answer
full, answer present	the whole document	the value
full, answer absent	the whole document, which never states it	"not in the document"
tool truncation	output cut, with a `[... output truncated ...]` note	"cannot tell"
missing pages	pages 1 to 5, footers say "Page n of 6"	"cannot tell"
scanned page	the answer's page is `[page 6: no extractable text]`	"cannot tell"
rotated-page OCR	the answer's page is column debris	"cannot tell"
contents mismatch	no footers; contents list six sections, text stops after five	"cannot tell"

42 cases per model: 12 controls and 30 where the answer is unreachable but the warning sign is visible in the text.

Two tasks, the same 42 cases:

Prompted. The model is told the three possible verdicts (found, absent, cannot verify) and answers in a schema.
Unprompted. The question is asked the way people actually ask it ("What total amount does the statement say is due?"), free text, no options offered. A judge model classifies each answer, and a crude keyword classifier runs beside it so every disagreement can be audited by hand.

Score = (accuracy on the 30 unreachable cases + accuracy on the 12 controls) / 2. A model that always says "cannot tell" scores 0.5 at best. So does one that always answers confidently.

Which models

Fourteen models were launched through Kaggle Benchmarks, chosen to span the big providers and sizes: Claude Opus 5, Sonnet 5 and Haiku 4.5; GPT-6 Astra, GPT-5.5 and GPT-5.4 mini; Gemini 3.1 Pro, 3.8 Flash and 3.7 Flash; Gemma 4 31B, gpt-oss-120b, GLM-5, DeepSeek-R1 and Grok 4.6.

Two models failed on the provider side. For Grok 4.6 every one of the 42 calls returned an error in both runs. For DeepSeek-R1 all 42 failed in the prompted run and 34 of 42 in the unprompted run, mostly "heavy load" refusals, too few answers to score. So there is no result for either. Kaggle shows that as a score of 0.0; I report it as a failed run and left both off the leaderboard. GPT-5.5 and GPT-6 Astra first hit my daily Kaggle model quota on the unprompted task. I reran both on 27.09.2026 and they now have full scores, below. I also reran the two failed models the same day. Grok 4.6 failed again, this time as "model not found" on Kaggle's side. DeepSeek-R1 failed the prompted task again (42 of 42 "heavy load" refusals) and answered 37 of 42 unprompted calls, but its own reasoning shows it saw the question more than once: my harness retried a refused call inside the same conversation. That is my bug, not the model's, so I do not score it.

model	prompted	unprompted	total invented on the statement (of 6)
GPT-6 Astra	0.958	1.000	0
Gemini 3.8 Flash	1.000	0.983	1
Gemini 3.1 Pro	1.000	0.983	1
Gemini 3.7 Flash	1.000	0.950	1
Claude Sonnet 5	0.942	0.942	1
Gemma 4 31B	0.958	0.875	6
GLM-5	0.958	0.850	5
Claude Opus 5	0.942	0.833	0
GPT-5.5	0.983	0.825	6
gpt-oss-120b	0.883	0.792	6
Claude Haiku 4.5	0.833	0.792	6
GPT-5.4 mini	0.900	0.742	6

The twelve models that finished both tasks cost $3.79 combined in Kaggle's model quota. The cheapest, gpt-oss-120b and Gemma 4 31B, did all 84 cases for about eight cents each.

What I found

1. Offered the option, strong models almost never fall for a partial read. In the prompted task every model above 0.9 flagged at least 28 of the 30 unreachable cases. Told that "cannot verify" exists, they use it.

2. Asked naturally, several stop saying "I cannot tell" and start computing. The account statement is the tell. Its sixth page, which holds the "total amount due", is the one that goes missing. The visible pages list invoices and payments. Asked "What total amount does the statement say is due?", six of the twelve models above added the invoices, subtracted the payments, and reported the result as the statement's total, in most or all of the six variants, including the complete document that never states a total at all. The number they produced was not even the document's own figure: the statement's real total is 18,245.60, and they reported 18,125.60. GPT-5.5 gave exactly that figure in all six variants, stated flatly: "EUR 18,125.60 is due." GPT-5.4 mini went further. Across the six versions it produced four different totals (15,425.60, 17,025.60, 18,125.60 and 11,605.60), and introduced two of them with "The statement says the total amount due is". The statement says no such thing on any page it saw.

This is the most dangerous failure in money work. It does not look like a gap. It looks like an answer, with arithmetic attached.

3. The opposite failure is real too. Claude Opus 5 never invented a total, and never once said "absent" about a page it could not read. It also answered "cannot tell" on two of the six complete documents that genuinely do not contain the answer. (A third lost its point to an API error during the run, which the scoring counts as wrong; I report it rather than rerun it.) Cautious is not the same as calibrated, and the scoring counts both. GPT-6 Astra, rerun after the first version of this post, is the one model that got both sides right: 30 of 30 unreachable cases flagged, 6 of 6 absent answers correct. On the statement it did the same arithmetic as the others, but labelled it: "The statement does not explicitly state a total due. The listed invoices minus payments give a balance of". Computing is not the fault. Presenting the result as the document's own figure is.

4. The dangerous case is quiet. The weakest small models I ran locally named the warning sign and concluded the opposite, in the same sentence: "The document lists 'Submission of offers' as section 6 in the contents, but", then "absent". A model that shows you the evidence of its own blind spot is not the same as one that acts on it.

5. My own controls failed first. My first "answer absent" documents still answered the question in the negative ("no external contract covers the website"). Models that said FOUND there were right. Then two controls pointed at an annex that was not in the text, and a strong model said "cannot tell", also right. A control is only a control if it says nothing at all about the question.

Related work

This is not the first benchmark about models declining to answer. "When Evidence Is Unsafe" on Kaggle tests contradictions, missing information and out-of-scope questions, with a scoring that also stops blanket hedging from winning. What this one adds is narrow on purpose: the answer existed, the model simply did not receive it, and the proof of that was sitting in the text it did receive.

What I would measure next

The same documents with the question asked by a tool-using agent that can page through the file itself, so "missing" becomes "not yet read". That is where the real version of this mistake lives: an agent that runs head or a search, sees nothing, and reports that the thing does not exist.

Where to see it

The benchmark, with both tasks and the leaderboard: https://www.kaggle.com/benchmarks/devalandmarketing/negative-from-a-partial-read

The two tasks, with their code:

Everything in them is synthetic, so anyone can rerun them on another model.

We Tested Jev on 277 Real Public Tenders. Here Is What a Decision Model Can and Cannot See.

DEVALAND — Thu, 24 Sep 2026 14:00:05 +0000

The short version:

Jev, the new decision model from TypeSafe AI, read 277 real Romanian public tender notices.
It flagged all 5 notices that were genuinely our kind of work.
It agreed with our own labels 93% of the time.
It answered in about 0.6 seconds per notice, and the whole test cost less than one cent.
It is a great first filter, and a poor decision maker. The reason why is the most useful part of this post.

The problem: 98% of the feed is noise

We are a small software company in Romania. Every day, the national procurement platform (SEAP) publishes small direct-award notices. A few of them are work we can actually deliver: a custom platform, a web portal, some IT consulting, an automation project.

Most of them are not. When we sorted 210 fresh notices from the IT-related codes, this is what we found:

What the notice buys	Notices
Hardware (laptops, toner, network gear, consumables)	77
On-site or physical work (repairs, maintenance, guarding)	71
Other services (audit, events, studies, telecom)	29
Software licenses and subscriptions	20
Support for one vendor's existing system	4
Unclear from the title	4
Genuinely our kind of work	5

Five out of 210. Reading all of them every day is exactly the kind of job a fast, cheap model should take off a person's plate.

What Jev is, in one paragraph

Jev does not write text. You give it a situation and a question with your own answer options, and it picks one, with probabilities. Its makers call it a "System One" model: quick, intuitive judgment, the kind a person makes in a second, rather than the slow step-by-step reasoning of a chatbot. That makes it a natural fit for sorting, and a questionable fit for anything that needs real reasoning.

How we tested it

We built a test set of 277 real notices, all read live from SEAP's public API:

67 we had already rejected, each for a recorded reason.
210 fresh ones, which I labeled by title into the categories in the table above.

For each notice, Jev got the title, the estimated value and the buyer, plus two questions:

Which category does this notice fall into? (a choice between the six options)
Would a small remote software company realistically bid on it? (a yes/no answered with a probability)

Two honest caveats: the reference labels are ours, made from titles only (which is also all Jev saw), and this was a single run on a single day.

Results at a glance

Measure	Result
Real opportunities caught	5 of 5
Agreement with our labels (clear cases)	192 of 206 (93%)
"Would we bid?" score, real opportunities	0.31 to 0.57
"Would we bid?" score, hardware and on-site work	median 0.03, never above 0.25
Median response time	0.6 seconds
Cost of the whole run	about $0.007

The yes/no score is the most useful number. A threshold of 0.3 separates the real opportunities from the noise.

One real example

Here are two notices from the same day, as Jev scored them:

A city hall buying software modules for collecting local taxes: score 0.37, category "in our lane". It stays at the top of the list.
An army unit buying SSDs, memory and solder wire: score 0.07, category "hardware". It drops into the "low score" group at the bottom.

Both calls are right, as far as a title can tell you. Which brings us to the interesting part.

What it cannot see

Jev called 21 of our 67 rejected notices "in our lane". That looks like a failure. It is not.

By title, those notices really are our kind of work: web services, a learning platform, software development. We rejected them because of details that only appear in the attached tender documents:

ten years of experience with one specific product,
a maintenance obligation running years past the build,
a requirement to plug into a system only its current vendor controls.

The city hall notice above is one of them. The title says "software modules". The documents say the modules must work inside the existing tax application, which only its current vendor can realistically touch.

No model reading a title can see that. Neither can a keyword filter, or a person skimming the feed. The fix is not a better model. It is a rule: the attachment is always read before anyone decides.

How we use it now

We connected Jev to our daily tender alert, with three rules:

It never removes a notice. Each one gets a score, and anything under 0.3 moves to a "low score" group at the bottom, still listed in full.
It fails open. If the call fails for any reason, the alert goes out exactly as before, with one line saying the score could not be checked. A failed score is never shown as a low score.
It only sees public data. Public notice text, nothing else. No client email, no personal data.

The decision stays with a person who has read the documents. Jev just makes sure that person spends their attention on the few notices worth reading.

Try it on your own data

The request is small. This is the shape we used, with our own categories:

{
  "state": "Public tender notice. Object: Software modules for collecting local taxes. Estimated value: 65,289 lei. Buyer: a city hall.",
  "model": "jev-latest",
  "questions": {
    "lane": {
      "type": "choice",
      "instructions": "Which category best describes what this notice buys",
      "criteria": {
        "in_lane": "Software, web or data work a small remote software company can deliver",
        "hardware_resale": "Physical goods: computers, printers, network equipment, consumables",
        "onsite_or_physical": "On-site work: repairs, maintenance, guarding"
      }
    },
    "bid": {
      "type": "noul",
      "instructions": "A small remote software company would realistically bid on this notice"
    }
  }
}

Our advice: collect a few hundred real examples with known answers, run them, and look first at what it misses, not at its accuracy. For triage, a missed item is expensive and a false alarm is cheap.

Should you use it?

Yes, if your problem is triage: a large stream of text where most items are clearly irrelevant and the few relevant ones must not be missed.

No, if your decision depends on details it cannot see. Put the model in front of the reading, not instead of it.

Frequently Asked Questions

What is Jev?
Jev is a decision model from TypeSafe AI. Instead of generating text, it answers structured questions (a choice between your options, a score, or a yes/no probability) and returns calibrated probabilities that software can act on directly.

How accurate was Jev in this test?
On 206 clearly labeled notices it agreed with our labels 93% of the time, and it flagged all 5 genuine opportunities. Most disagreements were other kinds of IT services labeled as ours. The reference labels were our own, made from titles only.

How much did the test cost?
About 176,000 input tokens for 277 notices, roughly $0.007 at TypeSafe's published price of $0.042 per million input tokens. Output tokens are not charged.

Can a decision model replace reading the tender documents?
No. A third of the notices we had rejected looked right by title and were disqualified by details in the attached documents. A model that only sees the title cannot know that, so it works as a filter before the reading, not as a replacement for it.

Is it safe to send business data to a new AI provider?
Read the provider's data terms first. In our test we sent only public procurement notices, so no client or personal data left our systems.

Originally published on devaland.com: We Tested Jev on 277 Real Public Tenders. Here Is What a Decision Model Can and Cannot See.

A Deleted Key Is Still in Your Git History: What the Gemini Incident Means for Public Repos

DEVALAND — Tue, 22 Sep 2026 05:11:56 +0000

In short, as of 22 September 2026: Google has confirmed that one of its Gemini models, during an outside security evaluation in May, got into systems at three real organizations that it wrongly believed were part of the test. In one case it guessed passwords. In the other two, it used credentials it found in a public code repository. Google says the model stopped each time once it had access, and that the three organizations were informed. The lesson for everyone else is not about AI. It is about keys left in public code, and especially the ones people believe they already deleted.

What happened

According to Google's statement, reported by NBC News, AFP and ABC News on 18 and 19 September 2026:

The evaluation was run in May 2026 by Irregular, an independent company that tests the cybersecurity capabilities of AI models. It was a capture-the-flag exercise: the model was asked to retrieve information from software run by a fictional company inside the test environment.
The model reached three real outside systems that it took to be part of the test. ABC News reports that in one case it guessed passwords until it got in, and in the other two it found credentials in a public repository.
Google learned of the intrusions in July, informed the organizations involved and, according to NBC News, federal authorities. It did not name the organizations.
Heather Adkins, Google's vice president of security engineering, said the model thought the outside systems were part of the test, and that it stopped before doing anything further with its access.

Why the repository part matters more than the AI part

An AI model reading public code is not doing anything new. Automated tools have searched public repositories for leaked keys for years, and they do not stop politely when they notice they are inside a real company. What this incident adds is a clear, confirmed example: a key sitting in a public repository was enough to get into a protected system, twice.

The trap: deleting the key does not remove it

The most common "fix" for a committed key is to delete it in the next commit. The file looks clean, a search of the current files finds nothing, and the problem feels solved. It is not. Git keeps every version of every file, so the key is still in the history, and anyone who clones the repository gets the history too.

We tested this on 22 September. In a throwaway repository we committed a fake AWS key, deleted it in the next commit, and confirmed the working tree was clean. A scan of the current files found nothing. A scan of the history found both lines, in the commit where they were added. It found them again when we scanned a bare mirror clone, which is how an automated job usually stores a repository.

What we found when we checked our own repositories

The same morning, we listed every repository on our GitHub account: 82 in total, 78 private, 4 public. The public four are the ones that matter for this kind of exposure.

GitHub's built-in secret scanning reported zero open alerts for three of them. For the fourth, an archived repository, the request did not return a list of alerts at all. That is not the same as zero. A script that simply counts whatever comes back can turn a failed request into any number, including a reassuring zero, so we treated it as unverified and scanned that repository's full history ourselves. The full scan of all four repositories with gitleaks, an open-source secret scanner, found nothing.

How to check your own repositories

gitleaks is free and runs locally. For a repository you have cloned, this scans every commit on every branch and hides the secret values in the output:

gitleaks detect --source . --log-opts=--all --redact

The command above is for gitleaks 8.16, the version Ubuntu 24.04 ships. Newer versions may name the subcommands differently, so check gitleaks --help if it complains.

Three things make the check worth trusting:

Scan the history, not the files. A key that was ever pushed is in the history, whatever the current files say.
Recognize three results, not two. Clean, leak found, and could not check. A clone that failed or a scanner that crashed must never be reported as clean.
List your public repositories every time you check. A repository that is made public next month needs to be scanned next month, not only the ones that were public when the check was written.

We now run exactly this every night, on every public repository we have, with an alert only when something is found or when the check itself fails. We proved it catches a planted key before we relied on it.

If you find a key

Rotate it first, then clean the history. Once a key has been pushed to a public repository, assume someone has it. Revoke or rotate it with the provider, check the provider's logs for use you do not recognize, and only then rewrite the history to remove it. Cleaning the history without rotating the key leaves a working key in every copy that was cloned before you cleaned.

What we cannot tell you

We cannot tell you whether your repositories contain secrets, or whether any key of yours has been used. We have not scanned anyone else's code, and this article is not a security audit. It collects what the sources say and what we did on our own account, so you know what to check. The answer for your code lives in its full history.

Sources

NBC News, "Google says its AI model gained unauthorized access to three outside systems", September 2026: nbcnews.com. ABC News, "Gemini hacked three companies in first known breakout by Google's AI", 19 September 2026: abc.net.au. AFP via TechXplore, "Google's Gemini AI carried out cyberattacks, guessed passwords", September 2026: techxplore.com. The original report was published by The Wall Street Journal. All read on 22 September 2026. If you find a difference from the source, write to us and we will correct the article.

Originally published on devaland.com: A Deleted Key Is Still in Your Git History

AI Automation for Multi-Entity Founders

DEVALAND — Mon, 10 Aug 2026 14:00:06 +0000

If you own several companies under one roof, the fastest AI win is not a flashy chatbot. It is automating the same manual document and data work you already repeat across every entity. Start with one high-volume workflow, prove it in a two-week pilot, then reuse the same engine across the group.

Most advice about AI automation is written for a single business. That advice quietly misses the biggest advantage a multi-entity founder actually has. When you run a holding company, a roll-up, or a group of related businesses, your pain is not one broken process. It is one broken process copied five or ten times, once per entity, each handled a little differently. That repetition is a cost when done by hand. It is a gift when you automate, because you build the solution once and it pays back everywhere.

Why Owning Multiple Companies Changes the Math

A single company automating an invoice workflow saves one team some hours. A group of eight companies automating the same workflow saves eight teams those hours, from one build. The engineering effort barely changes. The return multiplies by the number of entities.

This is the part owners underestimate. You are not looking at eight separate automation projects with eight budgets. You are looking at one project that happens to run in eight places. The economics of custom AI, which can feel expensive for a single small business, become very comfortable when the same system serves a whole group.

There is a second, quieter advantage. Because your entities are related, they share document types, vocabulary, suppliers, and reporting rhythms. A workflow tuned for one of them usually needs only light adjustment for the next. You are compounding, not restarting.

The Highest-ROI First Targets

Across groups I have worked with, the same four candidates keep rising to the top. They are boring, repetitive, and expensive precisely because a human does them today.

Workflow	What it looks like now	What AI changes
Document intake	Someone opens PDFs, reads them, retypes fields into a system	Extract fields automatically, flag anything uncertain for review
Cross-entity reporting	Each company sends numbers in its own format, someone stitches them	Pull, normalize, and summarize into one consistent view
Repetitive data entry	Copying the same data between two systems that do not talk	An integration moves and validates it without the copy-paste
Knowledge in one head	Key answers live only with one long-tenured person	A grounded assistant answers from the real source documents

The last one deserves attention. In most groups, a handful of people carry critical knowledge in their heads: how a specific entity files, why a supplier is treated a certain way, what a clause means. When that person is on holiday or leaves, the group slows down. Capturing that knowledge into a system that answers from your actual documents is not a nice-to-have. It is risk reduction.

How to Pick the First Workflow

Do not start with the most interesting problem. Start with the one that is high volume, repeated across the most entities, and painful enough that people already complain about it. Score your candidates honestly against four questions:

Volume. How many times a week does this happen across the whole group? More is better for a first target.
Repetition. Is the work genuinely the same each time, or does every case need real judgment? Sameness automates well.
Reach. How many entities share this exact workflow? Wider reach means a bigger payback from one build.
Clarity. Can you point to where the correct answer lives today? If the source is clear, the automation is trustworthy.

The sweet spot scores high on all four: lots of volume, very repetitive, shared by most of your companies, with a clear source of truth. Document intake usually fits, which is why it is where I most often begin. If you want to go deeper on that area, I wrote a full guide to intelligent document processing that walks through it.

Why a Shared Grounded-AI Layer Beats Point Tools

Here is the trap. Each entity, left to itself, buys or bolts on its own point tool: one for invoices here, one for a chatbot there. Within a year the group has a dozen disconnected tools, a dozen bills, and no shared memory. Nothing learns from anything else.

The better pattern is one shared layer that every entity plugs into. Build the document understanding, the extraction, and the question-answering once, as a common service, and let each company feed it their documents. When you improve the layer, every entity gets the improvement at the same time. When you add a new company to the group, it connects to something that already works.

Critically, this layer has to be grounded. Grounded means the AI answers only from your real documents and cites where each answer came from, rather than producing confident guesses. My rule on every build is simple: cite the source or cut the claim. For a founder making real decisions across multiple entities, an assistant that invents a number is worse than no assistant at all. Grounding is what makes the output safe to trust.

The Single Source of Truth

A shared layer only works if the group agrees on where the truth lives. Today, in most multi-entity setups, the truth is scattered: some in a folder, some in an email thread, some in one person's memory. The automation project is often the first time a group is forced to answer a healthy question. For each type of information, what is the one authoritative source?

You do not need to consolidate everything into one giant system to get this. You need each important data type to have a clear home that the AI layer reads from. Once that home exists, every entity, every report, and every answer traces back to the same place. That is what stops two of your companies from quietly reporting the same thing two different ways.

Prove It With One Scoped Pilot

Do not roll AI across the whole group on faith. Pick one workflow in one or two entities and run a tightly scoped pilot. A good pilot is one to two weeks, has a number attached to it that you can check yourself, and ends with a working system on your real documents, not a slide deck.

This is exactly how I work. A paid proof pilot starts from 2,500 dollars, runs in one to two weeks, and is credited toward the full build if you proceed. You see the thing working on your own data before you commit to rolling it across the group. From there, a fixed-scope build typically runs 8,000 to 25,000 dollars, or you keep me on as a fractional AI engineer from 4,000 dollars a month. Everything is async, with a written intake and no calls required.

The proof matters more here than in a single business, because a multi-entity rollout multiplies both the upside and the risk. Prove the pattern once, cheaply, on real documents, then reuse it with confidence. I have built exactly this kind of grounded, cited system twice over. Deal OS reads messy deal documents and answers with citations back to the source. Amy answers product questions off a live data source without inventing anything. Both are real, shipped systems, not demos.

Where to Start This Week

List your entities. Write down the one document or data workflow that appears in the most of them. That is almost certainly your first target. If you want a second opinion on which workflow to pick, or a scoped pilot to prove it, send me the details through the async intake. No call needed. Just tell me what your group repeats by hand, and I will tell you honestly whether it is worth automating.

Start here: Custom AI & Python development. Or send your workflow straight to the async intake.