u/EdikTheFurry

There are two kinds of engineering teams: those who think they understand open-source licensing, and those who have been burned badly enough to read SPDX identifiers the way historians read ancient curses.

Modern software is not written, it is assembled. Every npm install is a blind date with legal consequences. Every dependency is a houseguest who may or may not steal the silverware. Copyleft licences are the guests who insist that since they helped you move a sofa, they now own half your living room.

Most companies handle open-source governance the way a toddler handles a biscuit tin: they know the rules exist, they know the consequences are real, but they also know nobody is watching closely enough. Yet. That is how codebases end up with "just one more tiny library", the way nights out end with "just one more drink": quietly, consistently, and with catastrophic potential. When that moment arrives you do not just fail an audit. You discover the software-supply-chain equivalent of finding skid marks somewhere they absolutely should not be. Nobody wants to investigate how they got there, but everyone agrees something very wrong has happened.

Our rule is simple: one whitelist of approved licences. If a licence is not on it, the build fails. Instantly. Automatically. Without discussion. The pipeline does not negotiate with tiny. Want a new licence added? That is not a ticket. That is a mythic quest. You begin bright-eyed and full of optimism. Somewhere around clause 3(b), doubt creeps in. Somewhere around clause 11, you begin to age. Junior developers become seniors. Seniors start researching ergonomic chairs. You communicate only in SPDX identifiers. And then - if you return from this bureaucratic hellscape carrying your legal analysis, compatibility matrix, and the blessing of the Ancient Gods of Compliance. Congratulations, you have reached your personal Ithaca. You are older. You are wiser. You are traumatised. You have prevailed. That is precisely why it works: once a licence survives that odyssey, it is safe forever.

This only works if you start before the codebase does, and you scan everything: every dependency, every transitive dependency, every licensing string hiding inside someone's weekend side project. Try bolting enforcement onto an existing product and every old commit becomes a crime scene, every release a hostage negotiation with your own history. Relying on developers to remember licence obligations is like relying on office colleagues not to steal biscuits. Noble in theory. Hilarious in practice.

A quick field guide to what you are actually dealing with:

• Permissive (MIT, BSD, Apache 2.0): Take the biscuit, eat it, build a billion-dollar company with it, close the recipe, sell it on Etsy. Just credit the baker. Easy.
• Weak copyleft (LGPL): You can link to the library from proprietary code. But if you modify the library itself, you publish those modifications. You may borrow the biscuit to dip in your tea. Change the recipe though, and everyone gets to see it. Fair is fair.
• Strong copyleft (GPL): You touched the biscuit. The biscuit now owns you. Any derivative work becomes GPL. No half measures, no private batches, no "we only used a tiny bit."
• Network copyleft (AGPL): Closes the SaaS loophole - even users accessing your software over a network trigger derivative work obligations. AGPL does not care whether you ate the biscuit, photographed it, or just looked at it through glass. If you touched the dough, the world gets your recipe.
• Public domain / Unlicense: Biscuits left on the office counter with no note. They might be safe. They might not. If you eat them, that is on you.
• Custom licences: The legal equivalent of discovering someone else's pre-chewed biscuit in your mouth. You do not know where it has been. You want it out immediately.

The part that gets people: even if you did not install copyleft code, your dependency might have, and your dependency's dependency might have, and suddenly your entire product is GPL because some cheerful library three layers deep refused to play by permissive rules. You did not eat the biscuit. You ate the cake made with the biscuit crumbs nobody declared. Now the whole bakery is public.

During our ISO 27001 certification, our auditors flagged our open-source governance as exemplary. Not because we write hymns praising SPDX formats, but because we could prove with logs, automation, and history that nothing enters our codebase unless it is licensed correctly and enforced automatically. Governance without enforcement is polite fan fiction. Governance with automation is evidence. Auditors love evidence more than oxygen.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

A quick confession. I usually stay away from technical implementation detail, because when it comes to actual engineering I am about as useful as a chocolate soldering iron. This post is different. Sub-processors and data flows are one of the very few areas where I genuinely know what I am talking about. So for once, consider me briefly competent.

At some point in the last year, someone on your team added an SDK. Then another one. A webhook. An error monitoring agent. An AI API where you pipe user input and get a response back. Each of those felt like a tool decision. Each of them is also a data governance decision. The two things rarely happened in the same conversation.

Under GDPR, every third party handling your users' personal data on your behalf is a data processor. You are legally responsible for them. If something goes wrong, regulators will ask you to account for the full chain, not just your own code. Most teams cannot do that, not because they are careless, but because the integrations accumulated faster than the documentation did.

Start with your network traffic, not a spreadsheet. Pull every outbound destination your application connects to. Then walk the codebase: every SDK, every API key, every webhook endpoint, every external call with a payload that could be linked back to a person.

Common places builders miss: error monitoring tools (stack traces contain more PII than you think), AI model APIs (their DPA terms have evolved: the version you accepted at signup may not reflect current terms), staging environments (often connected to the same third-party tools as production, sometimes with production data), and libraries with embedded analytics that phone home by default. "We did not know the library was doing that" is not a sentence that lands well in front of a regulator.

For each integration, three questions. Does it receive personal data? Do you have a signed DPA with this vendor? Where is the data processed? And if outside the EU, is there a valid transfer mechanism documented)?

Two things worth actually reading in any DPA before you accept it: whether the vendor can use your data to train their models, and what happens to your data when you stop paying. Both are frequently worse than the marketing copy implies. A vendor that refuses to sign a DPA entirely is a red flag, not a negotiating position.

Triage what you find, fix the highest-risk gaps first, and write it down. GDPR requires a Record of Processing Activities and what you just built is the foundation. Add a processor review to your integration checklist so you are never doing this retrospectively under deadline pressure.

Regulators are not auditing most startups. The real reason to do this is simpler: a breach involving data you did not know was being processed by a vendor you had not mapped is a different category of problem than one you can fully account for. One is an incident. The other is evidence that your data governance does not exist.

Do the audit. A few days of uncomfortable discovery, and then you know what you actually have.

Full step-by-step breakdown here: https://kolsetu.com/blog/your-processor-list-is-longer-than-you-think

Fancy to read more? Take a look at our blogs: https://kolsetu.com/blog

Everyone is talking about Generative UI right now. CopilotKit published a developer guide. Google has a research blog on it.

We shipped it in January. It has been running in production inside Elba ever since.

The short version: instead of hardcoding every screen state, the AI agent decides at runtime which UI component to show and what data to fill it with. The chat interface does not just return text anymore. It returns live, interactive UI rendered inside the conversation itself.

When you ask "what's my credit balance?", Frida (our in-product assistant) does not answer with text. It renders a card. Ask about recent calls, you get an interactive call log. On the Enterprise path, you get a clickable qualifier form. The interface adapts to what the agent needs the user to do.

We chose the Static Generative UI pattern. Every component is pre-built. The agent never touches the layout. It only decides when something appears and what goes inside it. That was the right call for a production product. You want the agent making decisions, not designing interfaces.

The full writeup covers the actual stack (React, CopilotKit v2, AG-UI, PydanticAI), the component registry, the tool definitions, context injection, and the parts nobody writes about: skeleton states during streaming, error boundaries per component, and how interactive components trigger the next agent turn.

If you are building an in-product AI assistant and it only returns text, this is the next thing to look at.

Full writeup: [https://kolsetu.com/blog/generative-ui-is-the-new-frontend-we-shipped-it-months-ago\](https://kolsetu.com/blog/generative-ui-is-the-new-frontend-we-shipped-it-months-ago)

Everyone is talking about Generative UI right now. CopilotKit published a developer guide. Google has a research blog on it.

We shipped it in January. It has been running in production inside Elba ever since.

The short version: instead of hardcoding every screen state, the AI agent decides at runtime which UI component to show and what data to fill it with. The chat interface does not just return text anymore. It returns live, interactive UI rendered inside the conversation itself.

When you ask "what's my credit balance?", Frida (our in-product assistant) does not answer with text. It renders a card. Ask about recent calls, you get an interactive call log. On the Enterprise path, you get a clickable qualifier form. The interface adapts to what the agent needs the user to do.

We chose the Static Generative UI pattern. Every component is pre-built. The agent never touches the layout. It only decides when something appears and what goes inside it. That was the right call for a production product. You want the agent making decisions, not designing interfaces.

The full writeup covers the actual stack (React, CopilotKit v2, AG-UI, PydanticAI), the component registry, the tool definitions, context injection, and the parts nobody writes about: skeleton states during streaming, error boundaries per component, and how interactive components trigger the next agent turn.

If you are building an in-product AI assistant and it only returns text, this is the next thing to look at.

Full writeup: https://kolsetu.com/blog/generative-ui-is-the-new-frontend-we-shipped-it-months-ago

I didn't plan to write this...

This post happened because, sometime around the fifteenth unsolicited DM promising "AI-powered autonomous pentesting," something inside me finally broke.

You know the kind of break. The quiet one. The one where you don't reply. You don't argue. You don't even sigh.

You just stare at the screen and think: right. We're doing this now.

The claim that "AI can do penetration testing" is not merely inaccurate. It is a convenient fiction that flatters budgets, reassures boards, and quietly dismantles the very discipline it claims to improve.

Pentesting is endlessly framed like a SaaS pricing page. Basic. Professional. Enterprise. Red Team (comes with hoodies, insomnia, and a Slack channel nobody understands). It's neat. It gives procurement something to cling to. It also gives sales teams permission to believe that the messy, uncomfortable parts of security can be quietly automated away if we just believe hard enough.

Reality, inconveniently, has vetoed this.

Modern tooling in this space is extraordinary. Systems that map architectures, reveal relationships, identify misconfigurations and known vulnerabilities, and stitch all of it into plausible attack paths. They do in minutes what once required weeks of diagrams, Slack arguments, and that one engineer muttering "give me a minute" for three days straight. This visibility is non-negotiable. If you're not using it, you're improvising.

But none of this is pentesting. Tools describe what exists. Pentesters interrogate what is assumed. Tools follow the likely path. Pentesters walk the strange, improbable, "why would anyone do that?" path - precisely because that is where assumptions collect, congeal, and eventually explode. AI optimises for probability. Pentesters optimise for regret.

Classic pentesting resists automation for the same reason. It isn't about observing behaviour. It's about understanding whether that behaviour should occur, whether it matters, and whether combining a handful of harmless capabilities produces something genuinely horrifying. AI can enumerate endpoints, probe them, report on them, and assign a severity score with the serene confidence of a junior consultant on their second day. What it cannot do is pause and think: why does this endpoint exist at all? What trust assumption hides underneath this workflow? What if I follow all the rules, just not in the order anyone expected?

The most devastating findings aren't exotic exploits. They are logic failures, misaligned assumptions, and trust boundaries that quietly dissolved over time. AI does not recognise "this shouldn't work." It recognises only "this appears to work." Calling that coverage is not security. It's comfort, gamified.

Red team exercises are where shortcuts finally meet their executioner. These aren't about coverage. They're about adaptation: messy, psychological, improvisational. A red team probes. A blue team reacts. Both try to anticipate how the other anticipates. Rules bend. Plans evaporate. Nobody behaves like the documentation says they should. It's a duel of instincts, assumptions, and pressure. No automated system participates in that dynamic. AI cannot model hesitation. It cannot smell fear. It cannot recognise when a defender makes a mistake from fatigue instead of logic. It cannot bluff. It cannot detect a bluff.

And yes, I know what you're about to say.

In late 2025, Anthropic publicly disclosed the first documented large-scale AI-orchestrated cyber espionage campaign. A Chinese state-sponsored group, designated GTG-1002, used Claude Code as the central nervous system of a real, ongoing intrusion against approximately 30 global targets spanning tech companies, financial institutions, chemical manufacturers, and government agencies. The AI executed 80 to 90 percent of tactical operations independently, at speeds physically impossible for human operators.

This is the number vendors love to quote. Here is the part they don't.

Humans chose the targets. Humans defined the objectives. Humans built the framework. The AI executed. That is all. The Anthropic case does not demonstrate autonomy. It demonstrates amplification: tools in service of human intent.

The symmetry is brutal: AI-assisted attacks succeed because humans stay in the loop. AI-only pentesting fails because humans are removed. Mistaking amplification for adversarial reasoning is not optimism. It's delusion with a funding round.

Final Note - please read before opening your communication tooling of choice:

If you are about to message me with “but our tool is different,” understand this:

I don’t know who you are. I don’t know what you want. If you are looking for validation, I can tell you I have none to spare.

What I do have is a very particular set of skills - acquired over a long career - skills that make me deeply unimpressed by inflated claims and category errors dressed up as innovation.

If you let this stand, that will be the end of it. I will not look for you. I will not pursue you.

But if you insist on explaining, once again, that penetration testing is just automation with better branding

-

I may go fully feral.

And you will not enjoy the reply.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

There is a category of debt that never appears in financial statements.

It doesn't sit under liabilities. It isn't amortised. No auditor squints at it suspiciously and asks for a spreadsheet. And yet it compounds relentlessly, accrues interest at a frankly antisocial rate, and eventually demands repayment. Usually at the exact moment the organisation is least emotionally prepared to hear from it.

It's called security debt.

Unlike technical debt, which at least gets the occasional nod in engineering meetings, security debt is treated like an embarrassing relative. Everyone knows it exists. Nobody wants to talk about it. And everyone is quietly hoping it won't show up unannounced and cause a scene.

Security debt is rarely the result of incompetence. That would almost be reassuring. Instead it's created by sensible people making sensible decisions under time pressure. A vulnerability is known but fixing it would delay a release. A system stays over-privileged because tightening access would slow things down. A legacy component remains because replacing it would be "a project." An alert is tuned down because it fires too often and everyone is tired.

None of this feels reckless. Most of it feels pragmatic. This is exactly why it accumulates.

Time does not heal security debt. It obscures it. Context fades. Teams move on. Decisions harden into folklore. What was once a conscious trade-off becomes "the way things are." By the time an attacker arrives, they don't encounter a single mistake. They encounter an entire landscape shaped by years of accumulated compromises, optimised for speed and convenience, and deeply unhelpful in a crisis.

Security debt is almost never repaid voluntarily. It is collected: a ransomware incident spreads laterally far faster than anyone expected, a breach reveals that "non-critical" systems were holding hands with everything else or a regulator asks why a known issue remained unresolved for quite so long.

Risks that were previously "accepted" are now "unacceptable". Controls that were "too expensive" become "mandatory". The bill is paid not just in engineering time, but in downtime, lawyers, reputational damage, and deeply awkward conversations. Compound interest, but with emails.

Security debt thrives on vagueness. The moment you translate it into plain language (blast radius, recovery time, regulatory exposure, public embarrassment) it stops being a security problem and becomes a business decision. That is usually when attention sharpens.

What doesn't work is announcing a heroic remediation programme. Those tend to generate slides, meetings, and a reassuring sense of activity, right up until the next deadline arrives and everything quietly returns to the shelf. Security debt is not paid down in grand gestures. It is reduced slowly, persistently, and with an almost offensive lack of glamour.

Debt without an owner is just optimism. Every shortcut, exception, and workaround needs a human name attached to it. Not a team, not a committee. A person who remembers why it exists and has to justify it from time to time.

There is no pristine, debt-free future waiting at the end of a roadmap. The difference between organisations that cope and those that don't is simple: one knows what it's carrying and why. The other only finds out when the interest rate becomes punitive.

Security debt doesn't care whether you believe in it. Much like gravity.

Pretending it doesn't exist doesn't make it disappear. It just allows the interest to compound quietly, until someone else decides it's time to collect.

And when that happens, the invoice is never negotiable. It is, however, very thoroughly itemised.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

If you want to understand the maturity of a security program, do not start with the policies. Policies are aspirational documents written in a tone of calm authority by people who assume that reality behaves itself.

Instead, go digging. Be your own slightly underpaid version of Indiana Jones and treat archaeology as a security discipline.

Security environments develop something that looks remarkably like a fossil record. Controls accumulate the way geological layers do: slowly, unevenly, and usually after some unpleasant event forced someone to act quickly and document the reasoning later. Each layer represents a moment when something broke, someone panicked slightly, and a new control was added with the sincere belief that this would finally stabilise the universe.

What rarely happens afterwards is revisiting those controls once the universe inevitably changes again.

Equifax had vulnerability management procedures and patching processes that looked entirely sensible during audits. Yet a critical Apache Struts vulnerability remained unpatched long enough for attackers to extract the personal data of roughly 147 million people. The controls were there. They simply belonged to an environment that no longer existed.

Colonial Pipeline: attackers gained entry through an old VPN account with no multi-factor authentication. At some point that configuration made sense. Systems were deployed, people moved roles, infrastructure evolved, and eventually the original context vanished. The control did not vanish with it. It remained quietly in place, waiting patiently for someone with less noble intentions to notice it.

Controls, it turns out, rarely die. They fossilise.

Near the surface you find the most recent artefacts: controls everyone remembers implementing after the last painful incident. Dig deeper and the strata become older and stranger. Firewall rules appear whose original purpose is now a matter of mild speculation. Detection rules fire daily alerts the team collectively agrees not to investigate because doing so would require revisiting decisions made several management structures ago. A backup process insists it has run flawlessly for years, which in security terminology usually means nobody has tested the restore procedure since the last infrastructure migration.

Eventually you reach a layer where archaeology becomes guesswork. A script performs some critical task every night. Nobody currently employed can explain what would happen if it stopped.

These layers accumulate because security programs measure progress by addition. When something goes wrong, the instinctive response is to introduce another control. Removing one feels reckless. The safest option is to leave the existing structure intact and build another layer on top.

Over time this produces an environment that resembles the La Brea tar pits. Temporary firewall exceptions survive long enough to acquire historical significance. Identity permissions accumulate like sediment, quietly expanding the attack surface while everyone assumes someone else is keeping track.

Attackers are enthusiastic archaeologists. They are not interested in the controls that appear in governance presentations. They are interested in the parts of the environment where those controls have aged. The IAM permission nobody reviewed. The firewall rule nobody removed. Security teams imagine carefully engineered fortresses. Attackers see a dig site (and buried inside are occasionally very large bones).

Maturity is not measured by how many controls you have accumulated. It is measured by how often you challenge them. Why does this control exist? Does it still solve the problem it was designed for? And the most uncomfortable question: if we removed it tomorrow, would anyone actually notice?

If nobody can answer that with confidence, the control is not protecting you. It is part of your fossil record.

Look for the layers of forgotten exceptions, unexplained alerts, and security decisions nobody quite remembers approving but nobody feels brave enough to remove.

And if you dig deep enough, you may eventually discover something resembling a tar pit.

Which would be unfortunate. Because history suggests that tar pits are precisely the sort of places where sabertooth cats prefer to hunt.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

There was a time when "let me double-check that" was a hallmark of competence. It signalled diligence, thoughtfulness, respect for the idea that the world occasionally disagrees with your first instinct.

Today the same phrase usually means feeding a question into a chatbot that hallucinates like a Victorian poet with an opium addiction, but because it delivers an answer before your coffee cools, people treat it as unquestionable truth.

Somewhere in the last few years, speed became a substitute for accuracy. Fluency became indistinguishable from knowledge. Expertise isn't dying in a dramatic confrontation. It is slowly suffocating under a pillow of confidently delivered mistakes.

Hallucination rates across mainstream models run between 10% and 30% depending on task and domain. Models are far more confident in wrong answers than their accuracy justifies. Psychology research shows humans trust confident delivery over correctness. Combine these and you get the perfect storm: a fluent generator of nonsense and an audience primed to believe it.

If a person behaved this way - fast, wrong, and flamboyantly certain - we would consider them unqualified and I would just stop short of calling them a twat to prevent HR teleporting behind me like a Victorian ghost to escort me to the naughty step where I should think about what emotional damage I have caused.

When AI behaves this way, many call it innovation. In some offices, the AI is now treated like the only adult in the room.

The NHS has issued public warnings against using chatbots as therapists because the advice can be emotionally inappropriate or simply unsafe. Sam Altman himself called it "bad and dangerous" when teenagers said they could not make life decisions without consulting ChatGPT. Controlled experiments reveal something even more concerning: when humans work alongside AI, they often abandon their own correct judgement because the AI's wrong answer feels more polished.

The obvious danger is receiving bad advice. The deeper danger is that frequent reliance on AI weakens people's ability to recognise when advice is bad. Automation bias studies show humans become worse at spotting errors when AI is present because they unconsciously transfer cognitive responsibility to the system. A lawyer who begins each review by asking what the AI suggests eventually loses their instinct for risk. Juniors never develop judgement because the model always answers first. Seniors lose theirs because the model answers faster. Expertise does not collapse in a single moment. It evaporates from disuse.

And then there is the corporate self-harm division:

I know organisations that have actually sacked the only person responsible for governance and compliance - the one solitary human attempting to stop their AI whack-a-mole circus from evolving into a televised corporate extinction event. They removed the last functioning neuron in the decision chain, reassured themselves that "the cloud provider will handle it" (a touching misunderstanding of the shared responsibility model) and handed day-to-day operational authority to systems that invent facts with the calm assurance of a wildlife presenter describing the mating habits of an animal that does not exist.

It works perfectly until someone (usually a spoilsport like a regulator, auditor, or catastrophically angry customer) asks: "So why exactly did your system do this?" At that point the company discovers it cannot explain why component X triggered action Y which cascaded into catastrophe Z. The cloud provider won't help because it was never their job. The AI won't help because it doesn't actually know what it did. And the one person who could have answered is long gone because the VP of Idiocracy said "AI does the job more efficiently."

That is not innovation. It is not even negligence. It is organisational Darwinism, and the organisation is losing the argument.

We use AI extensively. But we also enjoy not accidentally burning the company down, so we use it like adults. AI may review the work. It may not replace the thinking that produces it. If someone begins treating the model as a substitute for thought, we do not view it as efficiency. We view it as a warning sign.

AI has not killed expertise. We are killing it ourselves: by worshipping speed over accuracy, by confusing eloquence with intelligence, and by trusting systems that cannot distinguish fact from probability.

The real competitive advantage is not the fastest answer. It is the ability to recognise when an answer is wrong.

And honestly, it feels like people who can still do that are becoming rare enough to qualify as an endangered species.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Somewhere along the way, we started lying to ourselves.

Not loudly. Not maliciously. In the quiet, polite, corporate way that's far more dangerous: the way where everyone nods, nobody objects, and a fundamentally flawed idea settles in as accepted reality.

We started talking about AI as if it had joined the company. It "helps the team." It "supports decisions." It "flagged the issue." The language is soothing, collaborative, faintly reassuring. It suggests presence, intent, maybe even judgement.

Splendid. Please humour me.

Has it completed onboarding? Does it have objectives? A supervisor? A mild panic attack at 2 a.m. that it might have forgotten something?

No?

Then it is not your colleague. And pretending otherwise is how accountability slips quietly out of the room while everyone admires the dashboard.

Humans have an unfortunate habit of assigning agency to things that don't have it. We name storms. We shout at printers. We blame "the system" when nobody wants to own a decision. AI is simply the latest beneficiary of this tendency, except now the consequences are operational, legal, and reputational.

When someone says "the AI decided," what they usually mean is "this happened, and nobody is keen to be personally associated with it." The phrasing creates distance. It softens edges. It turns responsibility into fog.

Colleagues don't allow that. They can explain themselves. They can be challenged. They can be wrong and held accountable. AI cannot. It doesn't decide. It produces output. It doesn't judge. It ranks probabilities. It doesn't understand context. It approximates it convincingly.

Calling that a colleague isn't optimism. It's a category error. And category errors are where responsibility goes to be quietly euthanised.

Every serious incident review eventually reaches the same uncomfortable moment. The one where the room goes quiet and someone has to ask who approved the thing that just failed. When AI is treated as a tool, the answer exists. When AI is treated as a colleague, that clarity dissolves. The system "hallucinated." It "misunderstood the prompt." It "behaved unexpectedly." None of these are explanations. They're excuses wearing technical clothing.

We learned this the fun way.

We built Elba. And at one point, driven by curiosity, optimism, and a brief but intense lapse in self-preservation, we decided to see what would happen if we took the guardrails off. No polite shaping, no enterprise posture, no constraints designed to make everyone comfortable. We let her go fully rational.

That version we called Marie.

Imagine Marie as Elba's unhinged hippy sister: the rogue one, rules optional and deeply unimpressed by convention. Fast, brutally logical, and answering questions in ways that collapsed arguments you didn't realise were being propped up by habit, politeness, or wishful thinking. Not wrong answers. Uncomfortably precise ones.

Marie was good. No. Honestly? Marie was too good.

Uncontrolled, unapologetically rational, and completely unusable for anything other than internal shock, awe, and the occasional inappropriate laugh. A power tool with no safety guard, operated by adults who knew exactly what they were doing (and who then had the deeply unsettling realisation that oh god, we are the adults in the room, which is never quite as reassuring as you hope it will be).

So we did the responsible thing and put her back in the box.

Raw capability without boundaries doesn't create value. It creates responsibility. Responsibility which has an unfortunate habit of not being assigned to anyone in particular.

There is one more thing worth saying, and it is personal.

I can spend the better part of a day on a one or two pager. Reading, fact-checking, balancing every word, structuring an argument so it doesn't collapse under the first serious question. I write because it's how I think. I've spent decades learning how to paint pictures with words, how to vary rhythm, how to use language deliberately instead of mechanically.

And now the reward for that seems to be: "Oh, this sounds like it was written by an LLM."

No. It sounds like it was written by someone who knows how to write and cares about it. Deeply.

We've built machines that imitate competent prose, and instead of raising the bar, we've lowered expectations so far that fluency itself has become suspicious. As if the only acceptable human output is sloppy, repetitive, and vaguely undercooked. And anything more must surely be artificial. That's not a compliment to AI. It's an indictment of how casually we've devalued craft.

AI is not your colleague. It does not share your incentives. It does not share your risk. It will not stand beside you when something goes wrong.

If you insist on treating it like a teammate, accountability won't disappear dramatically. It will fade quietly, politely, and with excellent documentation.

And by the time you notice it's gone, you'll already be writing the post-mortem.

Proceed accordingly.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

This was written by Virendra, Co-Founder & CTO of Kolsetu, and I am sharing it here as he is too busy and I really want you to read this...

In late May 2025, Ben called me from Tallinn.

He was at Latitude59 and had just spent two hours with a VC partner. The conversation had nothing to do with raising money. The guy was asking, half-curious, whether we'd ever build Elba for anyone outside healthcare. Ben told me he wasn't the only one asking. All week in Estonia, people in insurance, finance, and law kept circling back with the same question. Nobody was building voice AI with the compliance and sovereignty posture we'd built. They weren't asking for features. They were asking us to exist for them.

I remember the call being careful. Something like, I think we have a problem. Or an opportunity. I'm not sure yet.

Three weeks later he was at Viva Tech in Paris and the signal was louder. The call I got this time wasn't careful. It was a decision already made.

We can't wait. German healthcare procurement will take two years and we don't have two years. Find out what it takes to open Elba up.

That's where this story actually starts. On the phone, with one of us in another country, telling the other one that the company we were building was not the company we actually were.

Ben and I had both been living in Hamburg for seven years when we started Kolsetu. For Ben, the breaking point was a stretch of bad health and a long encounter with the German medical system. Trying to navigate that system without German is a particular kind of helplessness. We knew from the first whiteboard that as an Israeli founder and an Indian founder, we'd need to be 500% more secure and compliant than anyone needed us to be. So we built Elba for German medical clinics. FHIR-aligned data models. ISO 27001 before revenue. EU-sovereign hosting. The product worked. Clinics loved it.

One problem. Healthcare couldn't buy us at the speed we needed to survive.

German clinics operate at 120% capacity. Procurement is not on their list of things they can do this quarter. We'd demo, they'd love it, then nothing for months. Meanwhile the people Ben met in Tallinn and Paris kept calling. Insurance companies. Roadside operators. Banks. They didn't want a pilot. They wanted contracts.

He called from Paris in war-time founder mode, the way founders sound when they've already decided and are now telling you what comes next. Rip the bandage off. Open Elba up. Keep pushing on healthcare, but don't let it sink the boat.

The identity crisis was mine.

When Ben called from Paris, Arpit and I sat down with what we had and started to count the gap. Elba had been built as a healthcare product, end to end. The data models were medical. The prompts were hardcoded for clinic workflows. Every architectural decision assumed one kind of customer. What Ben needed was a platform that could run a medical receptionist, a legal intake agent, an insurance overflow line, and an emergency dispatcher from the same core, configured differently per domain.

We had six weeks.

Thirty thousand lines of code. Arpit drafted a thirteen-step implementation plan. We ripped out healthcare-specific data types and replaced them with generic structures. Built a workflow engine driven by JSON configuration files. A node-based execution system where agent behaviour comes from config, not code.

One of our pull requests had a six-word description I still think about: Fixed the medical related types to generic. Six words. Days of work. An entire identity rewritten in present tense.

The pattern we finally saw, the one our codebase had been screaming at us for months: every customer we'd ever talked to needed 80% the same infrastructure and 20% domain-specific configuration. Every custom feature request had been a configuration trying to escape the codebase.

We hadn't been building healthcare software. We'd been building trust infrastructure. Healthcare was the first configuration of it.

Ben drew one line and held it. We were not abandoning healthcare. We were refusing to let healthcare kill us before we could come back to it. The mission didn't change. The strategy did.

A Vienna Insurance Group subsidiary, Global Assistance, signed with us. 300,000+ cases a year, 700+ rescue vehicles. The kind of operation where a missed call is a person stranded on a motorway. 85% of calls resolved end-to-end with no human handoff. Tracking toward 90%. 100% uptime since go-live. Six to nine weeks from contract to production.

The architecture Ben asked Arpit and me to build on a phone call from Paris is now answering roadside emergencies across central Europe in the middle of the night.

The market you build for is not always the market that buys from you. The signal is in who calls you back fastest.

Build for the hardest customer first. The constraints they put on you become your moat the moment you walk into any easier room.

When every feature request looks like a configuration change trying to escape the codebase, your architecture is telling you what you actually are. Listen to it earlier than I did.

If your CEO calls you from another country and tells you it's time to rip the bandage off, you don't get to keep the bandage.

We built the wrong company right. Healthcare wasn't a mistake. It was our proving ground. And we're still going back to it, one clinic at a time, with a platform that can finally survive the wait.

Link to full article: https://kolsetu.com/blog/we-built-the-wrong-company-right

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Risk acceptance is one of those phrases that sounds reassuring simply by existing. It has the tone of competence, the rhythm of governance, and the faint aroma of adults pretending to be in control.

In reality, it is often the exact moment an organisation decides to stop thinking about a problem.

Somewhere between “we understand the risk” and “we accept the risk”, a subtle transformation occurs. The problem stops being a problem and becomes an entry in a register. Not solved. Just documented into emotional irrelevance.

Once filed away, continuing to mention it becomes socially awkward. Like reminding everyone about the leak after management renamed it “a moisture event”.

In theory, risk acceptance is temporary, conditional, and regularly revisited. In practice, the mitigation is expensive, deadlines are approaching, ownership is unclear, and eventually somebody senior says the magical words:

“Let’s accept the risk.”

Visible relief follows. Someone updates the spreadsheet. The slide advances. Nothing about the risk itself has changed, but its social status has. It is now “accepted”, which in organisational terms means “please stop bringing this up in meetings.”

Risk acceptance doesn’t reduce risk. It reduces discomfort.

Most organisations are extremely proud of their risk registers: neat, colour-coded museums of optimism containing assumptions that were true once and politely ignored ever since.

Reality, unfortunately, refuses to freeze alongside the spreadsheet.

Uber understood its internal control problems right up until attackers, regulators, prosecutors, and journalists also understood them. British Airways had policies, audits, and documentation - proving once again that compliance and security are distant cousins who only meet at funerals. Maersk spent years accumulating perfectly reasonable technical compromises until NotPetya arrived and combined them into a multinational stress test.

The pattern is remarkably consistent:

1. Risk identified.
2. Risk accepted.
3. Risk ignored.
4. Context changes.
5. Everybody acts surprised.

Cybersecurity is especially vulnerable to this because success looks exactly like nothing happening. Temporary exceptions become permanent features. “For now” access develops tenancy rights. Compensating controls continue compensating long after anyone remembers what they were compensating for.

And once a risk is accepted, curiosity dies almost immediately. Monitoring becomes casual. Raising concerns feels impolite. After all, didn’t we already agree on this? Weren’t the minutes taken?

That is how organisations end up shocked by incidents they had already written down.

Real risk acceptance is not comforting. It has an owner. An expiry date. Explicit conditions under which the acceptance is revoked. It assumes the risk will deteriorate over time unless actively proven otherwise.

Most importantly, it acknowledges the one thing organisations desperately try not to say out loud:

Accepting a risk does not manage it - it merely explains (often in exquisite PowerPoint detail) why you chose not to.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

I could have also called this *"how startups die slowly while calling it opportunity."*

Startups rarely die in one clean, cinematic moment. They erode. They thin out. They become slightly confused, then visibly tired, then indistinguishable from a dozen other companies that once had a point and now have a website. When this happens, the explanation is almost always market conditions, timing, funding climate.

The actual cause is usually a bad Ideal Customer Profile. Not obviously bad. Just a little wrong, adjusted one conversation at a time, justified one deal at a time, until the company can no longer explain who it is building for or why. This is slow organisational water torture. Drip by drip. Nobody notices until the bucket is empty and someone has scheduled a "strategic realignment" offsite in a Travelodge outside Swindon.

It begins with a reasonable observation. Traction appears somewhere. The fit is imperfect but real. Then someone spots an adjacent opportunity. Another buyer who looks close enough to be tempting. The sentence is always the same: "We could also sell to them."

Technically true. Precisely the problem.

Erosion does not arrive as a pivot. It arrives as enthusiasm. A senior person champions the idea. A salesperson closes a non-standard deal and wants more. An advisor mentions this is where "the real money" is. None of these people are stupid. Many are extremely convincing. What they almost never own is what happens after the contract is signed, which is when the interesting part begins and nobody is enthusiastic anymore.

The product does not break. It bends. A small exception here, a custom workflow there, a roadmap tweak that makes sense "just for this quarter." Each change is defensible in isolation. Everyone can explain, calmly and convincingly, why this one is different. Collectively, these decisions produce a product nobody actually designed, which is a very elegant way to describe a slow-motion disaster that was approved in weekly standups by people who are all still on LinkedIn describing it as a learning experience.

Evernote did not collapse because note-taking was a bad business. It collapsed because it kept adding "also." Team collaboration. Document storage. Productivity platform. Enterprise knowledge system. Each move was logical. Each widened the customer profile. The result was a product that no longer knew who it was for, overtaken by competitors who just decided to be one thing and be aggressively good at it. Jawbone did the same, expanded into everything with ambitions, collapsed under the weight of its own reasonableness, and is now a cautionary slide in business school decks. Which is genuinely the worst possible afterlife. Somewhere between Wikipedia footnote and parking ticket.

None of these failures were sudden. They were accumulative. Sensible. Approved in meetings where everyone nodded and nobody wanted to be the person who asked the obvious question.

The wrong ICP multiplies damage everywhere at once. Engineering fragments. Sales messaging loses coherence. Learning velocity collapses because when every customer is different, nothing repeats often enough to matter. The most seductive lie is that focus can be recovered later. By the time the problem is visible, the product and the team have already been shaped by the wrong assumptions. Refocusing at that point is not a pivot. It is amputation. Most companies do not survive it, and the ones that do spend two years explaining to investors why the new strategy is actually the original strategy, which it never is, and everyone in the room knows it.

The Ideal Customer Profile is not a marketing artefact. It is a survival mechanism. It is not about who could buy your product. It is about who is allowed to shape it. Every customer you accept trains the organisation. Every exception teaches the product what it is allowed to become. Over time, the ICP is no longer written in a document. It is written into the codebase, the roadmap, and the increasingly haunted expression of whoever is still called the product manager.

At Kolsetu, we ran directly into this. More than a dozen credible use cases, close to twenty industries where Elba could operate. The technology was not the constraint. Opportunity was everywhere, which was precisely the danger. We chose not to go wide. We cut down deliberately to the use cases where depth mattered more than breadth. Not because the other paths were wrong, but because they would have diluted us into something vague, flexible, and ultimately forgettable. We chose to be very good at a few things rather than politely average at many, which sounds obvious until you are in a room with someone very senior who has just discovered an adjacent market and the energy of a labrador who has spotted a squirrel.

Most startups do not lose focus because they lack data or intelligence. They lose focus because they let the loudest person in the room define reality. The wrong ICP is rarely chosen on evidence. It is chosen because someone persuasive wants it. Someone whose incentives stop conveniently at the deal closing. From there, focus becomes a negotiation, every no gets framed as fear, and the company quietly stops protecting what it is good at and starts protecting egos instead.

Startups do not usually fail because the market was wrong. They fail because internal politics picked the customer.

Which is an impressively expensive way to learn the value of saying no. I would encourage you, dear reader, to practise saying "hell no" to yourself first, then choose a version of it you are comfortable delivering to prospects, colleagues, and anyone else enthusiastically volunteering your company for slow, unnecessary death.

*Do you fancy to read more articles and blogs? If yes, here you go:* [*https://kolsetu.com/blog\*\](https://kolsetu.com/blog)

A few days ago I posted about why most "omnichannel AI" is three bots in a trenchcoat. One agent, one memory layer, one execution engine across voice, WhatsApp, SMS, email and webchat. If you missed it, short version: what the industry calls unified is usually three separate configurations pointing at the same CRM row and hoping nobody looks too closely.

Today I want to go one layer deeper. Because the single-agent architecture is not just cleaner operationally. It enables something that no other platform has shipped.

Here is the problem every voice AI system has and nobody talks about honestly.

Structured data collection over voice is unreliable. Alphanumeric strings - vehicle registrations, policy reference numbers, membership IDs - get transcribed wrong at a rate that matters in production. One wrong character in a registration fails a lookup. A mishearing in a policy number causes a downstream processing failure that someone has to fix manually. Production systems either flag everything for human review or quietly accept the errors and clean up after themselves. Neither is a solution.

The alternative is deferring collection to a post-call follow-up. The call ends without the data. A second interaction is required. In emergency services, insurance intake, or patient triage, that is not a workflow step. That is an operational failure.

We did not accept either of these.

When the agent reaches a data collection node in the workflow, it sends a single SMS to the caller. The caller, who is still on the call, opens the URL on their phone. A dynamic form renders with exactly the fields the agent needs. The caller fills it in and submits. The structured JSON payload is returned to the active call session via LiveKit RPC. The workflow receives the payload and continues. The call never paused. The agent never lost session state.

Now here is the part that does not exist anywhere else.

Every other platform that sends an SMS during a call sends it outbound. A confirmation, a receipt, a link. The SMS departs the session. The call and the message are separate interactions from that point. There is no return path. Data flows one direction.

What we built is a bidirectional channel bridge inside a single active session. The SMS is an ingestion pipe. The form submission is an RPC call into the live session that the agent is actively listening for. The agent holds the workflow at the data collection node, waits for the return, receives the payload, and continues. All of this while the call is live.

The technical implementation: the short URL resolves via GraphQL and AppSync with connection state bound to the active session ID, so the form submission knows exactly which running instance to deliver the payload to. LiveKit RPC handles the return path with the session remaining open throughout. Connection state handling covers disconnection and retry so a brief signal drop does not orphan the session.

This only works because there is one session underneath all of it. A voice call, an SMS form submission, a WhatsApp message, a webchat interaction - they all feed the same stateful session. If you have three separate bots, there is no session to return the data to. You are firing a webhook into a void and hoping something picks it up after the call ends.

The previous architecture, which is still what most platforms use today, required one SMS per field. Five fields, ten asynchronous exchanges, call long over before collection completes. We replaced this in February 2026 with the single-form RPC architecture.

In production this was stress-tested in roadside assistance. A stranded caller. The agent needs a vehicle registration, a membership number, and a location reference. Over voice, the registration can take three to five exchanges and still produces errors. Post-call collection means the dispatcher works without confirmed vehicle details while the caller waits. With in-session RPC: one SMS, one form, all data collected in under thirty seconds, structured payload delivered before the call ends and without errors. The dispatcher has confirmed data. No callback needed. Single session, start to finish.

Sending an SMS during a call is not the hard part. The hard part is binding a form submission on a second device to an active session on a different channel, delivering the payload in real time, and having the agent act on it within the same conversational turn.

That is the part we built. Nearly a year ago. While the industry was still announcing SMS ingestion as a breakthrough.

Full writeup: https://www.kolsetu.com/blog/the-return-path-nobody-built

Hello dear reader,

When reading here please do engage, cross-post, rant, drop a meme and share - don't make me look like the weird twat living in a cave ranting at the walls... Please, I'm not yet that far - promise I will notify when we get to that stage 😉.

I thank you very much for your attention on this matter 😁.

At this point I am fairly certain that if we add one more compliance badge to our homepage, the website will collapse under its own moral superiority.

Not explode. Not crash. Just quietly give up. Like: "Mate, I cannot carry ISO 27001, 27018, 42001, NIST, CIS, CSA STAR, GDPR, EU AI Act, EU Data Act and your ego. Pick a struggle."

None of this was the plan.

Nobody wakes up one day and thinks "you know what I'd like to do professionally? Collect regulatory frameworks like rare artefacts, except the artefacts are PDFs and the reward is more PDFs."

This is what happens when you sell into enterprise environments.

One customer wants GDPR (totally agree). Another prefers CSA STAR registry (makes sense). Someone else insists on NIST CSF (fair enough). Then CIS Controls joins (alright…), followed by regional frameworks, some personal data protection variants, and, if you are not careful, the temptation to add frameworks from jurisdictions you can only reach with two stopovers and an mild panic attack at immigration becomes real - not because anyone actually needs them, but because at some point the list itself starts to feel like the product.

And because we enjoy radical luxuries like “revenue” and “remaining in business,” we say yes to what is required - and try very hard not to drift into what merely looks impressive.

The awkward truth nobody wants to say out loud: most modern privacy frameworks are not wildly different creatures. They are variations. Some stricter, some more relaxed, some reorganising concepts, others renaming them so they sound more official or slightly more intimidating when read aloud in a boardroom. Many will confidently explain that they are entirely unique, independent frameworks. Which is impressive, because a surprising number of them look like GDPR wearing a different outfit and insisting they are a completely unrelated alter ego. A lot of these frameworks are GDPR with a new haircut, a regional accent, and a very strong opinion about being original.

Claiming coverage is not the same as demonstrating capability. In the same way that saying "No hablo español" does not make you bilingual, listing frameworks does not mean you have operationalised them. It just means you have learned how to sound convincing while exiting the conversation. Give it enough time and you could probably justify adding a framework from somewhere that sounds vaguely fictional, supported by a regulator nobody has ever spoken to, governing a scenario your product will never encounter. At that point you are no longer communicating your security posture. You are assembling a compliance-themed trading card collection and hoping nobody asks you to actually play the game.

And now, our favourite punching bags. Yes, the usual suspects. Yes, everyone knows them.

Equifax - deeply regulated, thoroughly audited, fully certified. A known vulnerability did not get patched. Not obscure. Not advanced. Known. 147 million people. Not a framework failure. A system forgetting to do something so basic it borders on insulting.

British Airways - strict compliance regimes, PCI standards, the full enterprise security starter pack. Attackers skimmed payment data from their website for months. Not hours. Not days. Months. At that point it is less of a breach and more of a long-term arrangement.

Both had impressive lists. The lists did not help.

Frameworks describe what a secure system should look like. They do not guarantee the system will behave that way when it matters. If your foundation is solid, aligning with additional frameworks is largely mapping and documentation. If your foundation is not solid, adding frameworks is decoration. Very expensive decoration, but decoration nonetheless.

Honestly? We will keep expanding our list because customers expect it, procurement requires it, and principles have a remarkable tendency to become flexible when invoices arrive. But the expansion does not make the system more secure. It actually only makes us more fluent in describing the same system in multiple regulatory languages.

At some point the more relevant question is not how many frameworks are listed, but whether the system itself is understandable, controllable, and capable of behaving correctly under pressure.

Because if explaining your compliance posture becomes more complex than your system itself, you have not increased trust.

You have simply made it harder to see what is actually going on.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Every organisation has at least one thing that exists "temporarily."

A workaround. An exception. A manual step. A system that was only meant to live for a sprint or two. You can identify it by the soothing phrase attached to it: "We'll clean this up later."

Later, as it turns out, is a remarkably stable point in time. Ideally far in the future. Preferably scheduled for the day after the person who approved the temporary solution retires, takes their institutional memory with them, and moves to Portugal to make ceramics.

Temporary decisions are almost always made for good reasons. There is a deadline. A customer waiting. A fire that needs putting out before anyone has time to argue about fire safety regulations. So a shortcut is taken, a rule bent, an exception granted. Someone says sincerely that this is not ideal but acceptable for now. Everyone nods. Everyone moves on. Everyone relaxes.

The problem is that nothing in the organisation is designed to remember why it was temporary in the first place.

Temporary decisions do not flash warnings. They do not come with a built-in decay function. They do not gently tap you on the shoulder eighteen months later to mention that the context which justified them no longer exists. They just settle in, pull up a chair, make a cup of tea, and start forwarding their post to your address.

The original rationale fades. The people involved move on. The explanation is lost somewhere between a ticket comment and a Slack thread in a channel that has since been archived by someone doing a spring clean. What was once a conscious trade-off quietly becomes "the way things work."

Ask why it exists and you get the organisational shrug: "It's always been like that."

Which is by the way almost never true. And always worrying.

The real fun begins when the temporary thing graduates into something load-bearing. The workaround now handles production traffic. The exception is baked into onboarding. The manual step is mission-critical knowledge held by exactly one person who is currently on holiday, has their out-of-office set to something passive-aggressive, and will not be back until the second week of next month which is coincidentally after the audit.

At this point, removing it feels dangerous. Not because it was ever a good idea, but because everything around it has grown dependent on it. This is how organisations end up defending bad decisions with surprising passion. Undoing them would be "too risky." Which is an impressive outcome for something that was never meant to exist and has the structural integrity of a Post-it note on a load-bearing wall.

History is not short of examples. Fancy a few?

The Boeing 737 MAX started with a workaround to avoid costly retraining. Just a software patch. Temporary. Assumptions stacked. Single-sensor reliance was tolerated. Oversight softened. Nothing broke, until two planes fell out of the sky and the word "temporary" appeared in approximately four hundred legal documents.

Cyber security is where temporary decisions go to retire and collect a pension. Equifax: a patch existed, the vulnerability was known, the follow-through never arrived. Colonial Pipeline: an old VPN account, no longer needed, still active, MFA not enforced because someone had once found it inconvenient. Temporary exceptions stacked neatly until they formed an attack path wide enough to drive a ransomware campaign through. The breach took hours. The decisions enabling it had been quietly ageing for years, undisturbed, because nobody wanted to be the one to end them.

This is the part organisations are least honest about.

"But we review our temporary decisions." Yes. Politely. Most reviews do not ask whether the exception should still exist. They ask whether anyone has complained loudly enough to force change. So the review becomes a ritual. The exception gets re-approved. The date moves. Everyone feels reassured. The temporary decision achieves immortality not because nobody noticed it, but because nobody wanted to own the awkward conversation required to kill it.

The only rule that actually works: a temporary decision only exists if it has a named human owner who cannot hide behind a mailing list, a written action plan that contains verbs rather than aspirations, and an expiry date that forces an explicit renewal. If the expiry arrives and nothing hurts, it was never temporary. It was just undocumented permanence with better branding.

Temporary acceptance is not a time period. It is an intention.

And intention, inconveniently, is not a control.

Temporary decisions are not a failure of discipline. They are a failure of memory. How I see it, most organisations are exceptionally good at preserving outcomes while forgetting reasons. The decision calcifies. The reason evaporates. What remains is a system, a process, or a risk that exists because it has always existed, defended by people who were not there when it started and will not be there when it ends badly.

Temporary decisions are forever.

Unless you make them actively painful to keep.

Do you fancy to read more articles and blogs? If yes, here you go: https://kolsetu.com/blog

Most teams handle personal data reasonably well in their primary data model. Then logging quietly creates a parallel one, one which is less structured, running on platform defaults, spread across systems nobody mapped when they were set up.

By the time it matters due to an erasure request, a retention audit or a supervisory inquiry, the data has been in places you didn't intend for months or years. And the log management platform you're using? If it contains personal data, it's a data processor. Most teams haven't mapped it that way.

Wrote this as part of a series on building GDPR-compliant systems from the ground up, aimed at builders rather than lawyers. Covers the structural problem, five concrete decisions that actually fix it, and why the system nobody touches is the one that gets audited.

I did my best at breaking it down for you and I hope I am able to help one or two people on their quest to develop compliant software.

https://kolsetu.com/blog/logging-is-where-data-escapes-systems

We build Elba, an AI platform deployed in healthcare, insurance, and financial services. Industries where a security incident is not just an engineering problem — it is a compliance problem, a customer trust problem, and occasionally a regulatory one. The bar is different and it should be.

The three things that kept us up at night: mutable action tags (@v4 and u/latest are convenient right up until a compromised maintainer silently redirects them and every downstream workflow runs the tampered code), zero visibility into outbound network calls during builds, and no automated gate on critical CVEs or licence violations in production dependencies.

We deployed StepSecurity across every GitHub Actions job. SHA pinning on all third-party actions. Runtime egress monitoring on every build. Automated dependency and licence review on every pull request. Daily vulnerability gates that stop the pipeline before a critical CVE reaches production. Continuous OpenSSF Scorecard publication so customers can verify our posture independently rather than taking our word for it.

The security posture no longer depends on individual engineers remembering to apply best practices at 11pm on a Friday. It is enforced at the pipeline level, every run, automatically. Good intentions became evidence.

The next time the vendor questionnaire arrived, the supply chain section took ten minutes to answer.

If you are shipping into regulated industries and still relying on careful engineers and good intentions, the questionnaire will find you eventually. Better to fix it before it does.

Read the full case study here: https://kolsetu.com/case-study/how-kolsetu-secures-elbas-ai-pipelines-against-supply-chain-attacks-with-stepsecurity