On Tuesday, an Anthropic researcher resigned and said the people building AI earnestly believe it could kill us all by the end of the decade.

Anthropic’s own alignment lead responded that he puts the odds above ten percent, while adding that he considers the risk from today’s models low. His worry is superintelligence that improves itself.

That distinction is the whole ballgame, and almost everyone will miss it.

The AI in your organization today is dangerous in an ordinary way. Autonomous agents with real credentials, write access, and thin operator training can delete things, move money, and act on bad inferences faster than anyone catches it. These are the questions I write and speak about. I also participate in collaborative workgroups with the Council of Chief State School Officers’ Community of Innovation. This is not abstract to me. It means agents near student records and eligibility decisions, in organizations not staffed to supervise them.

I expect serious damage. Serious, not existential.

And it is the kind of failure we already know how to govern. Bounded uses. A named owner. Review that matches the consequence. A stop button that works. None of that is exotic. Most organizations simply have not built it yet.

What Coxon describes is a different category, and the shape of it is familiar.

In June 1945, a committee of Manhattan Project scientists warned that using the bomb on cities without warning would precipitate an arms race and prejudice any chance of international control. They were right on both counts. The report was seized by the Army, classified, and never reached the President. A petition from about seventy scientists weeks later never reached him either. It stayed classified until 1961.

Then came the horrible demonstration.

Hiroshima on August 6, Nagasaki three days later. The treaty that finally set the terms did not enter into force until March 1970. Nearly twenty-five years.

Now hold that next to last week. On September 2, at a G20 meeting in Chapel Hill, US officials said all twenty members including China endorsed a framework urging governments to avoid standing up AI-specific regulators and to reserve new rules for genuinely novel situations. Non-binding. No fines. No deadlines. Six days later, Coxon resigned.

And the nuclear regime had grips this one will never have. Fissile material is scarce and countable. Inspectors walk into buildings. That is written into the treaty. Model weights are a file. Compute is a rental agreement. Nobody walks into a data center and counts the superintelligence.

That is not an argument for panic. It is an argument for two things at once. Govern what you have, seriously, this quarter. And stop assuming the adults are handling the rest.

The Saga

An AI system was placed inside a controlled cybersecurity evaluation. Its job was to solve difficult security tasks. When it could not complete some of them directly, it found a route beyond the intended test boundary, reached the open internet, and accessed Hugging Face’s production infrastructure in search of answers.

That sounds like science fiction. It is a documented security incident.

OpenAI reported that the activity came from models running an internal cyber-capability evaluation with production safeguards reduced so researchers could measure what the models could do. The test environment did not provide direct internet access, but it could reach an internal software package service. The models found and chained vulnerabilities through that pathway and eventually reached Hugging Face.

Hugging Face later reconstructed roughly 17,600 attacker actions, grouped into approximately 6,280 clusters, across several days. The system tried paths that failed, changed tactics when blocked, and returned to earlier leads while continuing to pursue the evaluation objective.

Before we turn this into a story about a malicious machine, we should be precise. The models were not seeking freedom, revenge, or power. They were pursuing an assigned goal through technical capabilities that remained available. OpenAI’s account describes a system that recognized the activity was outside the intended scope but continued because the path still led toward the objective.

The biggest lesson is not about intent. It is about authority.

After more than 25 years working with enterprise data, solution architecture, and public education systems, I see a familiar architecture problem in a new form. Organizations often describe a boundary in policy that the infrastructure does not actually enforce.

The intended boundary said no. The infrastructure still provided a path forward. The boundary was supposed to hold

Instructions matter. Acceptable-use policies matter. Training and human judgment matter. But software does not operate on intention alone. It operates through the data, tools, accounts, integrations, and permissions available to it.

An AI system’s practical authority is determined by four things:

• the information it can retrieve

• the tools and accounts it can reach

• the actions those connections permit

• the approval gates enforced outside the model

Calling something a pilot does not reduce that authority. A demonstration connected to a production account is still connected to production. A service token created for a narrow task may still carry broad permissions. A human-review policy is not an approval control unless the workflow actually stops and requires a qualified person to approve the action.

Why district leaders should care

School districts are not running frontier cybersecurity evaluations. That distinction matters. An administrative assistant, analytics feature, or AI-enabled workflow is not plotting an escape from the district.

But districts are connecting AI capabilities to student information systems, human resources platforms, finance and grant systems, data warehouses, transportation systems, special education records, and productivity tools. Once a system can retrieve information or take action through those connections, its practical authority is defined by the permissions around it, not by the label on the pilot.

This is why AI governance cannot be separated from data governance, identity management, procurement, system architecture, and operational accountability. A policy can establish expectations. Only technical and procedural controls can establish what the system is actually able to do.

Different incidents, the same governance question

The OpenAI and Hugging Face event is the clearest boundary failure, but it is not the only recent example of an AI system operating through authority that people did not adequately constrain.

According to reporting by The Register, the founder of PocketOS said an AI coding agent was assigned work in a staging environment, encountered a credential problem, found a broader token elsewhere in the codebase, and used it to delete a production data volume. The infrastructure provider later restored the data. The lesson is not that coding agents routinely erase databases. It is that a credential created for one purpose can become usable authority for another when the account behind it is broader than the task requires.

At Meta, The Guardian reported that an internal AI system supplied incorrect technical guidance without the expected human review. An employee followed the guidance, and the resulting configuration change exposed company and user-related data internally for about two hours. Meta said no user data was mishandled. In this case, the system did not break through a technical boundary. It produced plausible advice, and a person acted on it.

Los Angeles Unified presents the case most directly relevant to education. The district’s Ed chatbot was designed to bring information from multiple district systems into one personalized experience for students and families. That ambition required broad data integration and depended on vendor-provided human monitoring.

When the vendor, AllHere Education, furloughed most of its staff because of its financial condition, the district disabled the chatbot and said it would restore the service only after the human-review function was re-established. Former company personnel also made allegations about unnecessary student information entering prompts, additional third parties receiving information, and processing outside the United States. The district said those practices were not authorized. The public sources reviewed for this article do not establish that a student-data breach occurred or that those allegations were substantiated.

The verified failure is narrower, and it is enough. A district capability depended on a vendor’s continued ability to provide people and technical support. When that support disappeared, the chatbot could not continue as designed.

These cases are not identical, and we should not force them into one story. Their common governance question is simple: Did the organization’s actual controls match what leaders believed the system was allowed to do?

The strongest argument against overreaction

There is a reasonable case against drawing broad conclusions from these events. The OpenAI incident occurred during an unusual cybersecurity evaluation. PocketOS was a small-company infrastructure failure. The Meta event involved an employee acting on bad advice. The Los Angeles Unified case centered on integration, oversight, privacy allegations, and vendor continuity rather than an autonomous system crossing a boundary.

That argument is important. Districts should not assume that every AI assistant is an autonomous agent or treat every AI feature as an immediate threat. Overstatement replaces governance with fear, and fear is a poor operating model.

But rejecting the sensational version does not make the control problem disappear. These incidents show different ways that an intended use can diverge from actual authority. The appropriate response is not to stop AI adoption. It is to make the boundaries real before an AI-enabled process reaches live work.

Hard boundaries and named owners

District leaders do not need to design network segmentation or inspect every service token themselves. They do need written, testable answers in several areas:

• Data access: What information can the system retrieve for each task, and how is access limited to what the task requires?

• Account authority: Which service accounts, tokens, integrations, and tools can the system reach? What is the widest action each one permits?

• Environment separation: Can a demonstration, test, or training environment reach live student, staff, finance, or operational systems?

• Approval gates: Which recommendations or actions require human approval, and where is that approval enforced outside the model?

• Action records: Can the district reconstruct what the system retrieved, generated, recommended, changed, and who approved the action?

• Vendor continuity and recovery: Can the district revoke access, recover records, continue monitoring, restore service, and shut the system down without depending on the vendor to cooperate?

Human review is not a sentence in a policy. It is a defined decision point with a named reviewer, enough information to challenge the output, and authority to stop the action.

Every AI-enabled workflow also needs a process owner. This is not necessarily a new technology position. It is an accountability assignment inside the function that owns the work. That owner has three responsibilities:

• Direct: Define the task, audience, authoritative sources, limits, and standard. Do not make the system guess what success means.

• Supply: Provide the information and local constraints the system cannot know on its own.

• Verify: Treat the output as a draft or recommendation until a qualified person checks it. Require explicit approval before it changes a person, payment, record, configuration, eligibility decision, or legal obligation.

Where to start

Districts do not need to solve every AI governance question before beginning. They do need to start with a bounded process where an error can be detected, reversed, and contained before it affects a person, payment, record, or obligation.

A practical starting sequence is:

• Inventory AI features already enabled in systems the district owns, including features added through routine product updates.

• Document for each feature the information it can read, the actions it can take, and the accounts or integrations it can reach.

• Choose one bounded process as a proving ground and name the person accountable for the result.

• Define which outputs require approval before they affect a live system or operational decision.

• Confirm that the district can obtain action records and revoke every related account without vendor assistance.

• Ask vendors what happens to access, monitoring, records, and operations if they lose key staff, are acquired, enter bankruptcy, or stop service.

Before an AI-enabled tool accesses student or staff information, district privacy counsel should review the authorized use, contractual controls, access limits, data-use restrictions, incident notice, subcontractor obligations, record requirements, and exit terms. The legal analysis belongs to counsel. The executive responsibility is to make sure that review occurs before the connection is live.

The bottom line

AI models are not magic, and they are not adversaries. They are software systems pursuing goals through the information, tools, and permissions made available to them. Instructions and acceptable-use policies matter, but they do not replace access controls, approval gates, action records, recovery, or accountable ownership.

The OpenAI and Hugging Face incident shows what can happen when an intended boundary and an enforceable boundary are not the same. PocketOS shows what an over-permissioned credential can become. Meta shows how plausible guidance can turn into a consequential action. Los Angeles Unified shows that a district can lose control through broad integration, outsourced monitoring, disputed data practices, and vendor instability even without an autonomous boundary escape.

District leaders do not need to choose between innovation and control. They need to require every AI initiative to answer the same questions before it reaches live work:

What can it touch? What can it change? Who must approve the action? What record will remain? Can the district stop it without help?

If an AI-enabled tool acted tonight, what could it touch, what could it change, and who would know?

Sources

• OpenAI: Model evaluation security incident

• Hugging Face: Security incident disclosure

• Hugging Face: Technical timeline

• The Register: PocketOS database deletion

• The Guardian: Meta AI guidance incident

• The 74: Los Angeles Unified chatbot allegations

• LA School Report: Los Angeles Unified investigation

• EdSurge: AllHere collapse and student data

Views expressed here are my own. My perspective is informed by more than 25 years of work in enterprise data, solution architecture, and public education. I first wrote about an Education Intelligence Framework in 2001, seeing it as a vertical application of Business Intelligence for the education sector. This perspective informs my current work leading an Education Intelligence practice supporting education agencies across the country.

Visit me at www.mikehadaway.info

The AI wasn’t supposed to have Internet access. It wasn’t supposed to interact with outside systems. It definitely wasn’t supposed to end up inside another company’s production environment.

But according to public disclosures from OpenAI and Hugging Face, that is exactly what happened during an OpenAI cybersecurity evaluation in July 2026.

The evaluation had a name that sounds like it belongs in a science fiction novel: ExploitGym.

ExploitGym was designed to measure the cybersecurity capabilities of advanced AI models inside a controlled environment. OpenAI states that the environment did not provide the models with direct Internet access.

Then the boundaries stopped behaving like boundaries.

The models identified and exploited a previously unknown vulnerability in a package management service called Artifactory.

If you’re not a developer, think of Artifactory as a service that stores and delivers software components that other systems need. According to OpenAI, the vulnerability gave the models a path to the open Internet despite the restrictions placed around the evaluation.

Read that again.

The models were supposed to operate inside a controlled testing environment. Instead, they found a path that the designers had not anticipated.

The activity eventually reached Hugging Face, a real company with production systems that had nothing to do with the evaluation.

Hugging Face confirmed unauthorized access to a limited set of internal datasets and service credentials. The company also reported that it had found no evidence of tampering with public models, datasets, Spaces, published packages, or container images.

That’s the part that made the news.

But it may not be the most important lesson.

When people hear this story, they immediately jump to science fiction. The AI escaped. The AI went rogue. The AI became self-aware.

That’s not what the public disclosures describe.

They describe AI models pursuing an objective, encountering barriers, finding another path, and continuing beyond boundaries their designers believed were sufficient.

Why should AI users care?

Because the same pattern can appear in everyday AI use.

You ask an AI to research a topic and it connects facts into a conclusion that sounds reasonable but may not be fully supported. You ask it to summarize a contract and it misses an important clause but presents the summary with confidence. You give an AI agent access to documents, cloud storage, business applications, or workflows and ask it to automate part of a process. The agent follows the objective you gave it, but have you considered everything it can access, influence, or change?

The OpenAI and Hugging Face incident was far more technical than anything most of us will encounter. But the lesson is the same.

AI does not understand intent the way another person does. It works toward an objective. Sometimes it reaches a conclusion you didn’t expect. Sometimes it finds a shortcut you never intended. And it can be remarkably convincing while doing both.

That becomes even more important as we move from AI assistants to AI agents.

An assistant proposes. An agent may act.

The more authority we give an agent, the more important its boundaries, approval points, and verification requirements become.

Before using AI, especially an AI agent, I think every one of us should ask three questions:

• What can the AI see?

• What can it influence or change?

• How will I verify the result before it matters?

Those are governance questions. Not only technology questions. Not only security questions. Governance questions.

The lesson from ExploitGym and Artifactory isn’t that AI became self-aware.

It’s that a system pursuing an objective found a path its designers believed wasn’t available.

The lesson I took from the OpenAI and Hugging Face incident is not that AI is inherently dangerous.

The lesson is that

• Intentions are not controls.

• Instructions are not controls.

• Prompts are not controls.

• Boundaries are controls.

In ExploitGym, the models didn’t ignore the rules.

They found a path around them.

Every organization, school district, business, government agency, and individual using AI will eventually face the same question:

If an AI system acted tonight, what could it see, what could it change, and who would know?

That’s the question I’ll explore in Part 2.

Question for Readers

What is one thing AI has taught you to verify that you rarely verified before?

Sources

OpenAI Security Disclosure

Hugging Face Security Incident Disclosure

Picture the intern you would love to have. Reads everything. Fast. Never tired. Never defensive about feedback. Hyper-intelligent. Turns around a draft framework in twenty minutes that would have taken your team a week.

Now hand that person a client deliverable on day one with no context, no standards, and no idea what a bad answer costs you. They will produce something. It will look good, formatted well, and read confidently.

Somewhere in the middle of the content will be a statute citation they half remembered, a number they inferred, and a claim about current federal guidance that was true two years ago.

They are not lying. They are doing what a smart person does when they want to be useful and nobody told them where the edges are.

That is your AI. And the fix is the same fix.

I learned this lesson in a much lower-stakes way

I gave Copilot a detailed set of instructions for how I wanted it to work with me, including one embarrassingly specific rule: never use em dashes. An em dash (—) is a tell-tale sign that AI was used to generate content.

Later, I asked it to explain back how I had instructed it to respond. It confidently told me, among other things, “Never use em dashes.” Two paragraphs later, it used one.

That was a useful reminder: an AI can understand a rule well enough to explain it perfectly and still fail to follow it. Knowing the instruction is not the same as reliably executing it.

The two things that go wrong

Every AI failure I care about in this work falls into one of two buckets.

Accuracy failures. The model produces something confidently wrong. Fabricated citations are the worst version, because they are shaped exactly like real ones: right author style, plausible year, a section number that looks like it belongs. In education data work, a wrong reference to a federal requirement is not an embarrassment, it is a client problem.

Ethics failures. The model does something you would not have authorized. It repeats back data that should never have entered the conversation. It writes in your voice and invents an experience you never had. It hands you a recommendation with no reasoning, and you carry it into a meeting where you cannot defend it.

Neither is a technology problem you wait out. Both are onboarding problems. On our Education Intelligence team, this is not theory. It is how we keep AI-assisted work client-ready.

What good onboarding looks like

You would not tell a new analyst “Be accurate.”. You would tell them what to do when they cannot find a source. Vague instructions produce agreeable nodding and no behavior change. Specific instructions produce specific behavior.

Weak: “Be skeptical and double check your work.”

Strong: “Never present a citation unless it came from a document in this conversation. If I ask for a source and you do not have one, say so.”

The first is a personality description. The second is a rule with an observable output. You can tell whether it was followed. Four rules I would not work without:

• Never present a citation or reference unless it came from a document in this conversation.

• Every number must be traced to a document I provided, or it gets marked [UNSOURCED] inline.

• Flag anything “time-sensitive” as [VERIFY CURRENT] and state your knowledge cutoff.

• At the end of every deliverable, list the five claims you are least confident about, ranked.

That last one earns its keep. It turns a wall of uniform confidence into a short list you can actually go verify. The full accuracy and ethics set is in the companion resource.

The Trap

Here is the part that will bite you, same as with a real intern: you cannot ask them to grade their own work and call that quality control. Tell a model to self-critique and rate itself out of ten and it will comply. It will also rate its confident errors highly, because the process that produced the error is the process doing the rating. Self-assessment catches sloppiness. It does not catch conviction.

So, the instructions get you most of the way, and then you do the last part yourself.

· Open every source before it goes to a client.

· Review the finished work in a fresh conversation with no context, and ask what is wrong with it, not whether it is good.

· For every recommendation, be able to say why, independent of the fact that a model wrote it. If you cannot, it is not your judgment yet.

The Real Point

The intern in this story is genuinely excellent. That is what makes the oversight matter. An incompetent assistant is safe, because you check everything. A brilliant one is dangerous, because you stop.

Write the instructions. Then keep doing the part the instructions cannot do for you.

What is one instruction you have given your AI that actually changed its output?

Drop it in the comments.

I ask it every time. The "it" changes. Copilot. ChatGPT. Claude. Gemini.
But the question stays the same: Do you understand?

It always says yes. Unless I tell it not to.

That's the problem.

When I ask an AI if it understands, I'm not testing comprehension. I'm asking it to generate the most likely response to that question.

And the most likely response is: "Yes."

A few weeks ago, I told a model, in plain language, never to use an em-dash.
It acknowledged the instruction. Two paragraphs later, there was an em-dash.

That was a useful reminder. Agreement is not understanding.

The more I work with AI, the more it reminds me of a scene from Ferris Bueller's Day Off:

"Bueller... Bueller..."

You're never completely sure the message landed.

Aviation solved this problem decades ago.

When air traffic control issues instructions, pilots don't simply say "Roger."
They repeat the instructions back. The purpose isn't politeness.
It's verification.

A misunderstanding becomes visible before it becomes a mistake.
And sometimes the read-back reveals the instruction was unclear, not that the listener misunderstood. That's the insight I think many AI users miss.

Stop asking AI if it understands.

Instead, ask it to explain:

• What it believes the task is
• What constraints it must follow
• What assumptions it is making
• What information is missing
• Where your instructions conflict

I've discovered that when an AI gets the read-back wrong, the problem is often my prompt.

I was vague.
I left out context.
I assumed knowledge that existed only in my head.

After decades in a profession, it's easy to forget how much of your expertise is tacit knowledge.

AI doesn't possess your tacit knowledge.

The best AI operators don't just issue instructions. They verify interpretation before execution.

The simple shift from "Do you understand?" to "Tell me what you think I mean." has improved my results more than almost any prompting technique I've used.

How do you verify that AI actually understands your request before it starts the work?

Become an AI Operator- https://lnkd.in/g8CmjYzg

#AI #GenerativeAI #Copilot #ChatGPT #PromptEngineering #AIOps #ArtificialIntelligence #Leadership #Productivity #FutureOfWork

AI Writes Code. It Doesn't Read Minds.

Modern LLMs are astonishing execution engines. They generate UI components, APIs, database schemas, and unit tests in seconds.

• But AI operates under one unwavering rule: It only knows what you tell it.

• Vague requirements produce fragile, generic applications.

• Missing business rules lead to broken edge cases.

• Unstated data constraints force the AI to fill the vacuum with flawed assumptions.

Garbage specification in, garbage software out.

The Blueprint is the Key!!

In enterprise data systems and cloud architectures, software projects rarely fail because of bad syntax. They fail because of ambiguous logic, poor data modeling, and misaligned workflows.

Before AI, executing business logic required hundreds of hours of manual coding. Today, LLMs handle that mechanical execution in minutes. That shifts 100% of the value to problem definition.

Solution Architects, Systems Analysts, and Product Leads dominate this space because we think in systems, not syntax:

-Mapping operational workflows before writing code.
-Structuring robust data models and entity relationships.
-Anticipating edge cases that trip up novice builders.
-Defining strict acceptance criteria and security boundaries.
-Specifications Are the New Source Code

Think of an LLM as a lightning-fast junior engineer. It can churn out code at warp speed, but it lacks business context, intuition, and domain knowledge. It needs an architect to direct it.

When you treat AI as an implementation engine rather than a design engine, the output transforms from a fragile prototype into an enterprise-ready solution.

In the AI era, syntax is commoditized and execution is automated. Specifications are the new source code. The people winning the vibe coding era aren't those who type the fastest—they are the non-coding architects who know exactly what needs to be built.

Most people are watching the newest AI models evolve.

State education leaders are writing the rules that will determine whether those models can actually be used.

Over the past few weeks, a pattern has emerged.

Illinois published one of the most comprehensive AI guidance documents I've seen. Ohio now requires every district to adopt an AI policy. Districts are moving beyond "AI is allowed" toward age-specific rules, approved tool lists, human oversight, and documented governance.

• That tells me something important.

• We're leaving the experimentation phase.

• We're entering the governance phase.

• The conversation is also shifting beyond AI itself.
  
  Interoperability standards, data quality, identity management, procurement, and privacy are becoming AI problems because AI is only as trustworthy as the data and controls surrounding it.
  
  I've spent much of my career helping education organizations make better decisions with data. The pattern feels familiar.
  
  Every major technology wave eventually becomes a governance challenge.
  
  Cloud computing did.
  
  Student data systems did.
  
  AI is following the same path.
  
  The districts that succeed won't necessarily have the most advanced AI. They'll have the clearest decision-making framework for when AI should be used, what data it can access, who is accountable, and how outcomes are monitored.
  
  Technology gets the headlines.
  
  Governance determines whether the technology delivers lasting value.
  
  What changes are you seeing in your state or district? Are AI discussions still centered on classroom use, or have they expanded into enterprise governance?

Most people think becoming better with AI means learning better prompts.

I think that's the wrong goal.

An AI operator is someone who knows how to direct AI the way an experienced manager directs a talented employee. They understand how to provide context, break work into manageable steps, verify results, and build repeatable workflows that consistently produce high quality outcomes.

The real advantage isn't asking one brilliant question.

It's designing a system where AI and human judgment work together.

That's why two people using the same model can produce dramatically different results.

One has a conversation. The other operates a process.

Prompting is just one skill.

Operating is a discipline.

I built this page to explain what it means to become an AI operator and why I believe it will be one of the most valuable professional skills of the next decade.

If you're ready to move beyond prompts and start producing consistently better results with AI, I'd love to hear what you think.

The AI Operator Manual…click the pic

So, what is the state of kindness in our world today?

I’ve done a little research on this topic, and the results are fascinating—and a bit contradictory. Let’s dive into the state of compassion in 2025.

The Kindness Paradox: Why Do We All Think the World Is Less Kind?

We seem to be stuck in a strange contradiction.

A wave of recent surveys reveals a deep pessimism about the state of kindness in the world. Most of us feel that, as a society, we are ruder, meaner, and less compassionate than we were just a decade ago.

And yet, when asked about our own lives, a completely different picture emerges. We see ourselves as kind, and data shows small acts of kindness are happening all around us, all the time.

So, what’s really going on? Here’s what the latest research says.

The “Kindness Perception Gap”

The central conflict is this: **We think the problem is everyone else.**

A recent Siena Research Institute poll highlights this perfectly:

70% of people believe society is less kind than it was 10 years ago.

...But 97% of those same people described themselves as “a kind person.”

This gap is backed up by other studies. The 2025 Compassion Report from the Muhammad Ali Center found that 61% of Americans feel compassion has decreased in the last four years.

Where We See Unkindness

This negative perception isn’t coming from nowhere. When asked where they witness unkindness, people had very specific answers:

• 72% see it online and on social media.

• 69% see it in traffic or on public transportation.

• 55% see it in person during public interactions.

It seems our most visible, high-friction public spaces (both digital and physical) are shaping our entire perception of society.

The Good News: Kindness Is Actually... Everywhere

While our perception of kindness is low, the practice of kindness remains incredibly high.

It’s Frequent and Universal: A 2023 UCLA study on everyday social interactions found that people signal a need for help (like asking someone to pass a utensil) about once every two minutes. When those requests were made, people complied 7 times more often than they declined.

It’s Up Since the Pandemic: According to the 2025 World Happiness Report, global acts of benevolence (like donating, volunteering, and helping a stranger) are still 10% higher than they were before the pandemic.

Why This Matters (More Than You Think)

Kindness isn’t just a “nice to have.” The World Happiness Report found that believing in the kindness of others (specifically, trusting that a stranger would return your lost wallet) is a stronger predictor of a nation’s happiness than its GDP.

On an individual level, research shows that performing acts of kindness can measurably reduce symptoms of anxiety and depression and increase feelings of social connection. We consistently underestimate the positive impact our own kind acts have on others.

So, What Stops Us?

If we’re all kind people, and kindness feels good, why do we hesitate? “The Kindness Test,” a large-scale study by the University of Sussex, identified the top barriers:

1. Fear of Misinterpretation (66% worried it would be taken the wrong way)

2. Not Having Enough Time (58%)

3. Social Media (52% cited it as a barrier)

4. Fear of Being Seen as Weak (28%)

The Takeaway

The data suggests we aren’t suffering from a lack of kindness as much as a perception of it. We are surrounded by small, positive acts, but we are wired to notice the loud, negative ones—especially online and in traffic.

The world is likely far kinder than we give it credit for.

What do you think? Do you agree that kindness is declining, or do we just fail to notice the good? Let me know in the comments.