Every few months a video goes around: a robot folds a shirt, pours coffee, or loads a dishwasher, and the comments fill up with “it’s over for humans.” I watch these with a mix of awe and suspicion. The awe is earned. The suspicion is too, because what a demo hides is usually more interesting than what it shows.

“Physical AI” is the label that has stuck for AI systems that perceive the world and then act in it. Think a robot arm, a humanoid, or a car. Physical AI is not a new idea wearing a new hat. It is a very old problem that finally got some new tools. To see why 2026 feels different, you have to start with why it felt impossible for sixty years.

A long road of confident predictions

The first industrial robot, Unimate, went to work at a General Motors plant in New Jersey in 1961. It lifted hot die-cast metal parts and stacked them. It was useful, and it was also blind. It repeated a fixed sequence of motions, and if you moved the part three centimeters, it failed.

A few years later, researchers at SRI built Shakey, a wheeled robot that could look around, build a symbolic model of a room, and plan its way through it. The reasoning was impressive for the time. The execution was painful. Shakey could take a long while to work out a simple route, and a changed shadow could confuse it.

Then came a humbling realization, usually credited to Hans Moravec and others in the 1980s. The things humans find hard, like chess and logic, turned out to be easy for computers. The things a toddler does without effort, like grasping a cup or walking across a cluttered room, turned out to be brutally hard. This is called Moravec’s paradox, and it hung over robotics for decades.

The field responded in waves. In the 1980s and 90s, Rodney Brooks argued that robots should stop building big internal world models and react to the world directly with simple layered behaviors. Later, machine learning took over perception, and robots got far better at seeing. Then reinforcement learning let simulated agents learn to move. In 2019, OpenAI’s Dactyl hand solved a Rubik’s cube after huge amounts of simulated training with randomized physics. It was a fascinating result, and it was also one hand, one task, and a mountain of compute.

Each wave solved a piece. None of them gave you one system that could handle a messy kitchen it had never seen.

The thing that changed

The shift came from somewhere unexpected: language models.

Large language models trained on internet-scale text and images had absorbed a startling amount of general knowledge. They “knew” that a mug goes upright, that milk goes in the fridge, and what “tidy up” roughly means. Robotics researchers asked an obvious question. Could we borrow that knowledge instead of teaching a robot everything from zero?

In 2023, Google DeepMind’s RT-2 gave this idea a name and a proof of concept: the vision-language-action model, or VLA. The trick was to take a model that already understood images and text and teach it to also output robot actions. A robot that had never been shown a particular object could still act sensibly on it, because the underlying model already knew what the object was.

So what’s actually inside one of these things?

Here’s the technical version, without the jargon fog.

1. Perception and understanding. Cameras (and sometimes touch and joint sensors) feed into a vision-language model. This is the “brain” part that understands “put the red cup next to the laptop” in terms of what is in front of it.

2. The action part. This is where it gets different from a chatbot. A language model produces words, one token at a time. A robot needs smooth, continuous motions: joint angles, grip force, and speeds, many times per second. Physical Intelligence’s π0 model, for example, pairs a vision-language model with a separate “action expert” that uses flow matching, a close cousin of diffusion, to generate these continuous movements. The company’s initial iteration, π0, combines a vision-language model with an action-expert flow-matching model. Instead of predicting the next word, it predicts a short chunk of upcoming motion, which makes the movement smoother and less jittery. Wikipedia

3. Two speeds of thinking. Thinking slowly about “what should I do” and moving fast enough to not drop the cup are different jobs. Several systems, including Figure’s Helix and NVIDIA’s GR00T family, split the work into a slower reasoning module and a much faster motor module that runs at high frequency. If you’ve heard the “System 1 / System 2” analogy from psychology, it fits well here.

4. Many bodies, one brain. A big goal is cross-embodiment learning: train on data from many different robots (arms, humanoids, two-armed setups) so knowledge transfers between them. It is the robotics version of a model learning from every language at once.

How this differs from the AI you chat with

People often assume physical AI is “ChatGPT with a body.” It is related, but the differences are real, and they explain most of the field’s pain.

The output is continuous and unforgiving. If a chatbot writes a slightly wrong word, you can edit it. If a robot arm is slightly wrong, it knocks over the glass. Errors don’t just appear. They compound: a small slip puts the robot in a situation it has never seen, and the next action gets worse.

Time is a hard constraint. A language model can pause for two seconds to think. A robot balancing or catching something cannot. Latency is not an inconvenience here. It’s part of the physics.

The data doesn’t exist on the internet. There are trillions of words online. There is no equivalent pile of “what a hand felt while tightening a screw.” Robot data has to be collected, often by humans teleoperating machines, and that is slow and expensive. This is, I’d argue, the central bottleneck of the whole field.

The world pushes back. Text is a closed system. Physical environments involve friction, weight, slippery surfaces, bad lighting, and objects that behave differently each time. You can’t fully predict them, only keep adapting.

Safety is not optional. A wrong answer in a chat is embarrassing. A wrong move near a person is dangerous. That means physical AI needs layers of guarantees that language models never needed.

Why this matters now

Put the pieces together and you can see why the timing feels different. Pretrained vision-language models gave robots common sense. Better action generators gave them smoothness. Simulation and, increasingly, “world models” that predict what happens next give them practice without breaking real hardware. And money followed: at CES 2026, NVIDIA’s CEO called this the “ChatGPT moment” for robots, a claim that was being put to the test in factories and warehouses within months. neuralcoretech

I’m cautious about that phrase. A “ChatGPT moment” implies everyone suddenly has access to something useful. Robots are not software. You can’t download one. That’s the story for the next article: where this is actually working, what the newest research says, and where it still falls apart.

If this kind of explainer is useful to you, follow me here on Medium. I’m writing a short series on how AI is leaving the screen and entering the physical world, and the next piece covers the latest research and the real limits.

Robots Didn’t Get Smarter Overnight. Here’s How Physical AI Really Works was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here is a question every executive eventually asks: “Why are we paying a highly skilled engineer to sit in a customer’s office?”

On a spreadsheet it looks expensive. A senior engineer’s salary, travel, and the opportunity cost of not building the core product add up fast. If forward deployment were just custom work, the skeptics would be right.

But the best FDEs create value in ways that don’t appear on a project plan. Let’s unpack where the value comes from, then follow a case study from stalled pilot to measurable result.

The Five Types of Value an FDE Creates

1. Speed to value

Enterprise AI projects commonly die in the gap between a successful pilot and real adoption. An FDE collapses that gap by removing blockers in real time: an access permission, a data format, a hesitant stakeholder. Problems that take weeks to resolve through email and tickets get solved in a hallway conversation.

2. Accuracy of problem definition

Customers rarely describe the true problem on day one. They describe the symptom, or the solution they’ve already imagined. An embedded engineer watches the work happen and notices that the “document summarization” request is really a “we have no idea which contracts are about to expire” problem. Building the right thing beats building the wrong thing beautifully.

3. Trust and adoption

Software nobody trusts doesn’t get used. FDEs earn trust the old-fashioned way: by showing up, listening, fixing small things fast and being honest about limitations. When the AI makes a mistake, the customer already knows the person to call, and, more importantly, trusts that person to fix it.

4. A product feedback loop no survey can match

This is the most underrated benefit. Every deployment is a field experiment. FDEs see which features get used, which get ignored, which workarounds users invent and which gaps keep appearing across customers. That intelligence flows directly to product and research teams, so the roadmap is shaped by reality instead of guesswork.

5. Retention and expansion

A customer whose workflows are rebuilt around your product with your engineer’s help is far harder to lose. Successful deployments also open doors: once one team sees results, adjacent teams ask for the same thing.

Case Study: From Stalled Pilot to Claims Engine

Note: This is an illustrative composite based on common patterns in enterprise AI deployments. The company and figures are fictional, built to show how the dynamics play out.

The situation

Meridian Mutual is a fictional mid-sized property insurer processing tens of thousands of claims a year. Its adjusters spent a large part of each day reading photos, repair estimates, policy documents and emails to decide whether a claim was straightforward or needed investigation.

Meridian had purchased an AI platform and run a pilot. The pilot summarized claim files impressively in demos. Six months in, adjusters rarely opened it. Leadership was ready to write it off as another AI experiment that didn’t pan out.

Week 1–2: Listening before building

The vendor assigned a Forward Deployed Engineer, whom we’ll call Priya. Her first move was not to write code. She sat beside adjusters and watched them work for two weeks.

She discovered three things that never appeared in the project brief:

1. Adjusters didn’t need summaries. They needed a fast answer to one question: “Does anything in this file contradict the claim?”
2. The most important information lived in places the pilot never touched, including an old policy database and scanned PDF endorsements.
3. Adjusters distrusted the tool because early outputs contained confident errors, and nobody had given them a way to see why the AI said what it said.

Week 3–6: Building the right thing

Priya redesigned the solution around the real workflow:

• Integrated the policy database and scanned endorsements through a document-processing pipeline, giving the model the context it was missing.
• Reframed the output from “summary” to “flags”: a short list of potential inconsistencies, each linked to the exact source passage or photo.
• Built an evaluation set with a senior adjuster, using several hundred historical claims with known outcomes, so accuracy could be measured instead of debated.
• Added a feedback button so adjusters could mark any flag as wrong or useful, and sent that data back into a weekly review.

Critically, she involved two skeptical senior adjusters as co-designers. Their credibility with their peers did more for adoption than any training session.

Week 7–12: Stabilize and expand

Priya stayed through the dull but decisive stage: edge cases, performance issues, a security review and a handful of confidently wrong outputs that she traced to a formatting quirk in one legacy system. Each fix was logged and shared with the vendor’s core team.

The outcomes (illustrative)

The compounding effect

The value didn’t stop at Meridian. Three product improvements that came out of Priya’s work, source-linked outputs, the feedback loop and the scanned-document pipeline, became standard features for the vendor’s other insurance customers. A custom solution for one client became a competitive advantage across the portfolio.

That is the FDE multiplier: one engineer’s field work, productized, scaling to dozens of customers.

How to Measure the Value of an FDE

If you lead a company considering this model, avoid judging FDEs by billable hours. Better indicators include:

• Time from signed contract to first production use
• Adoption depth: daily active users, not licenses sold
• Expansion revenue from deployed accounts
• Retention compared with accounts that had no embedded support
• Reusability: the share of custom work that later becomes product
• Insights shipped: how many field discoveries influenced the roadmap

The last two are the real test. If reusability is near zero, you’re running a consultancy. If it’s high, you’re running a learning machine.

Pitfalls to Avoid

• The services trap. Without discipline, every deployment becomes bespoke work that never productizes.
• Hero dependency. If only one person understands the customer’s system, you’ve created a single point of failure. Document everything.
• Burnout. Constant travel and context switching wear people down. Rotate assignments and protect recovery time.
• Misaligned incentives. If FDEs are rewarded only for customer satisfaction, product feedback gets neglected. Reward both.

How to Build or Hire Your First FDE

1. Look for builders with curiosity about people. Technical depth matters, but the unusual signal is genuine interest in how other people’s jobs work.
2. Test with an ambiguous scenario. Give candidates a messy customer problem with missing information. Watch how they ask questions before they write code.
3. Give them a direct line to the product team. An FDE without influence is just remote support.
4. Start with one high-value customer. Prove the model, document the playbook and then scale.

The Takeaway

In an era when AI capabilities are advancing at breathtaking speed, the scarce resource isn’t intelligence. It’s integration: the ability to make intelligence useful inside the unique, tangled, human reality of a real organization.

The Forward Deployed Engineer is the person who does that work. They shorten the path to value, sharpen the product and turn skeptical customers into advocates. Their cost is visible on a budget line, but their value shows up everywhere else: in adoption, trust, retention and a product that gets better with every deployment.

In AI’s next chapter, the winners won’t just be those who build the smartest models. They’ll be those who show up, roll up their sleeves and make the technology work where it matters.

The ROI of Showing Up: What a Forward Deployed Engineer Is Really Worth was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you work anywhere near cybersecurity, MITRE ATT&CK barely needs an introduction. It’s the matrix that shows up in SOC dashboards, red team reports, vendor marketing slides, and job interviews. It became the shared vocabulary for describing what attackers actually do, replacing vague terms like “advanced persistent threat” with something concrete: tactics, techniques, and procedures anyone can point to and say “yes, that’s what happened to us.”

SPARTA, the Space Attack Research and Tactic Analysis framework from the Aerospace Corporation was deliberately built on that same foundation. But space is not an office network, and a satellite is not a laptop, so the resemblance only goes so far. I wanted to actually put the two side by side and see where they genuinely converge, and where the differences start to matter a lot.

If you haven’t read the first piece in this pair, it’s worth a quick look, it walks through what SPARTA is and how it’s structured. This one assumes you’ve got the basics and want the comparison.

The shared ancestry

Let’s start with what SPARTA borrowed, because it borrowed a lot, and it borrowed it openly. Aerospace has said plainly that SPARTA follows the same industry-standard approach pioneered by ATT&CK: organize adversary behavior into a matrix of tactics (the why), techniques (the how), and sub-techniques (the specifics), and pair every technique with countermeasures defenders can actually implement.

That shared DNA shows up in the fundamentals. Both frameworks treat reconnaissance as the opening move. Both recognize resource development, building malware, acquiring infrastructure, setting up command-and-control, as a distinct phase that happens before an attacker ever touches the target. Both track persistence, defense evasion, lateral movement, and exfiltration as recognizable stages an adversary moves through. If you’ve internalized how to read the ATT&CK matrix, you can open SPARTA and immediately understand the grammar, even before you understand the specific vocabulary.

That’s not an accident, it’s the whole point. A security professional moving from enterprise IT into space systems, or a space engineer picking up general cybersecurity literacy, shouldn’t have to learn a completely foreign mental model. SPARTA deliberately preserved the parts of ATT&CK’s approach that already worked.

Where the numbers diverge

Here’s the first concrete difference: ATT&CK’s Enterprise matrix currently organizes adversary behavior into fourteen tactics, running from Reconnaissance all the way through Impact, with stops at Privilege Escalation, Credential Access, Discovery, Collection, and Command and Control along the way. SPARTA condenses this down to nine tactics.

That’s not SPARTA being less thorough, it reflects a genuinely different battlefield. A spacecraft doesn’t have the same sprawling identity and privilege architecture as a corporate Active Directory environment, so some of ATT&CK’s tactics simply don’t map cleanly onto how a satellite is built and operated. At the same time, SPARTA folds certain enterprise-style concepts into fewer, more consolidated categories, since a lot of what happens on orbit is constrained by hardware, bandwidth, and physics in ways a cloud environment never is.

Two circles that overlap more than you’d expect

Picture the two frameworks as overlapping circles. In the shared middle sit the concepts that show up almost anywhere adversaries operate: supply chain compromise, exploiting trusted relationships, establishing command-and-control channels, evading defenses, and exfiltrating data. Attackers, it turns out, have surprisingly consistent instincts regardless of whether the target is a data center or a satellite bus, they still want to get in quietly, stay hidden, move toward what they want, and get data or control out without being noticed.

Where the circles pull apart is where things get interesting. ATT&CK’s territory is built around IT infrastructure: identity systems, cloud services, containers, operating systems, and the sprawling lateral-movement possibilities of a networked enterprise. SPARTA’s territory includes things that would never appear in a corporate threat model: radio frequency link exploitation, spoofing and jamming of command-and-control signals, tampering with flight software update processes, exploiting the physical and procedural realities of launch and on-orbit operations, and yes, even non-cyber counterspace techniques like high-powered lasers or kinetic anti-satellite weapons that SPARTA acknowledges sit alongside pure cyber threats in a mission’s real risk picture.

That last point is worth sitting with for a second: SPARTA isn’t purely a cybersecurity framework in the narrow sense. It captures that a spacecraft’s “attack” surface includes both the network intrusion an ATT&CK-trained analyst would recognize instantly, and physical-domain threats that simply have no equivalent on a corporate network. You can’t jam a database server with radio noise.

A side-by-side look

Laid out this way, the practical differences become clearer. ATT&CK has had over a decade to mature into an industry standard with matrices covering enterprise, mobile, and industrial control systems, shaped by a huge community of contributors reporting real-world incidents. SPARTA, launched in 2022, is much younger and leans more heavily on theoretical and lab-proven techniques simply because there’s a smaller public body of confirmed space-cyber incidents to draw from, which, frankly, says more about how classified and rare public space-attack disclosures have historically been than about any weakness in the framework itself.

Both frameworks pair techniques with defensive countermeasures, but SPARTA goes further by shipping dedicated tooling like a Countermeasure Mapper and a Navigator, aimed specifically at helping engineers thread mitigations directly into system design during the mission architecture phase, a much earlier intervention point than most enterprise security teams get, since you can’t exactly patch a satellite’s hardware after it’s in orbit.

Why the differences matter more than the similarities

It would be easy to read all this and conclude that SPARTA is basically ATT&CK with a space-themed coat of paint. I don’t think that’s quite fair, and here’s why: the differences aren’t cosmetic, they’re structural, and they come from genuinely different failure modes.

In enterprise IT, the nightmare scenario is usually data theft or ransomware, bad, expensive, sometimes catastrophic, but generally recoverable. In space, several of SPARTA’s Impact techniques describe outcomes with no recovery path at all. A compromised satellite is not something you can just re-image and bring back online, and depending on the mission, an attacker degrading a spacecraft’s function might be functionally identical to destroying it outright. That changes the entire cost-benefit calculation for defenders. ATT&CK-style detection and response catch it, contain it, remediate it, works because enterprise systems are usually reachable and fixable. A lot of SPARTA’s philosophy leans instead toward getting the countermeasures right before launch, because “incident response” for a spacecraft mid-mission is a much more limited toolbox than an IT team is used to having.

What this pairing tells us about the future of threat modeling

I think the real story here isn’t SPARTA versus ATT&CK, it’s what their relationship previews. As more critical infrastructure moves into unconventional domains, orbit, autonomous vehicles, industrial robotics, whatever comes next. I’d bet we see more of this pattern: take the proven bones of ATT&CK’s approach, and adapt it to a domain with its own physics, its own failure modes, and its own irreversible consequences. ATT&CK didn’t just give the industry a matrix; it gave the industry a methodology for building matrices. SPARTA is the clearest proof yet that the methodology travels well, even a few hundred kilometers straight up.

For anyone doing threat modeling work today, the takeaway is simple: learn ATT&CK if you haven’t, because it’s still the widest and deepest resource for understanding adversary behavior in general. But if your work touches space systems or anything adjacent to them, SPARTA isn’t optional reading anymore. It’s quickly becoming the baseline vocabulary for an industry that spent decades assuming distance was a defense, and is now catching up fast.

Enjoyed this comparison? Follow me for more breakdowns like this. I dig into the frameworks, standards, and quiet infrastructure decisions that end up mattering a lot more than the headlines suggest.

SPARTA vs. MITRE ATT&CK: Same DNA, Very Different Battlefield was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Models get smarter every month. So why is the hottest hire in tech someone who sits inside the customer’s office?

Picture a Tuesday morning at a regional hospital network. The leadership team just spent six figures on a state-of-the-art AI platform. The demo was dazzling. It summarized patient notes, flagged billing errors and answered questions in plain English.

Three months later, almost nobody is using it.

The data lives in four incompatible systems. The nurses don’t trust the summaries. Compliance has questions nobody can answer, and the one person who understood the integration left in July.

Then someone new walks in. She isn’t a salesperson or a consultant with a slide deck. She’s an engineer, and she has a laptop, a badge and a desk on the third floor. Within two weeks she knows which nurse hates the new interface and why. Within six, the tool is embedded in a workflow people use daily.

She is a Forward Deployed Engineer (FDE), and she may be the most important person in the AI economy right now.

A Job Title With a Spy-Novel Origin

The role isn’t new. It was popularized by Palantir in the early 2000s, when the company was building data-analysis software for intelligence agencies and other demanding organizations. Palantir noticed something uncomfortable: great software sitting in a vendor’s headquarters doesn’t solve problems in a customer’s environment. The distance between “it works in our lab” and “it works in your messy reality” was where projects went to die.

So Palantir sent engineers to the front line. Internally, the field engineers became known as “Deltas,” and their analyst counterparts as “Echoes.” They sat with customers, learned the real problems, wrote code on site and fed what they learned back to the core product team.

For years this was considered a quirk of one company’s culture, even a slightly embarrassing one. Investors prefer software that scales without people. Sending skilled engineers to live at a customer site looks like consulting, and consulting has lower margins and doesn’t compound the way pure software does.

Then generative AI arrived and the logic flipped.

The Last-Mile Problem of Artificial Intelligence

Large language models are astonishing general-purpose tools. But “general-purpose” is exactly the problem. A model that can write a sonnet and debug Python knows nothing about your claims process, your supply chain exceptions, your regulatory constraints or your ten-year-old database with column names like FLD_7_OLD.

Closing that gap takes work that doesn’t fit neatly into a product roadmap:

• Data plumbing. Connecting the model to messy, siloed, permission-controlled systems.
• Context engineering. Deciding what the model needs to see, when, and in what form.
• Evaluation. Defining what “good” means in a specific domain and measuring it, because an impressive demo is not a reliable system.
• Workflow design. Fitting AI into how people actually work, including the unglamorous steps in between.
• Trust. Earning the confidence of the people who must rely on the output.

AI makes the first 70% of any project astonishingly fast. The remaining 30% is where the value, and the risk, lives. That last 30% requires someone who understands both the technology and the terrain, and who is physically or virtually there.

That is the FDE’s job.

What Does a Forward Deployed Engineer Actually Do?

The title varies. You’ll see “Forward Deployed Engineer,” “Deployment Strategist,” “AI Engineer, Customer-Facing” and others. The pattern is consistent, though. An FDE typically:

1. Embeds with a customer for weeks or months, either on-site or in close daily contact.
2. Diagnoses the real problem, which often differs from the one in the contract.
3. Builds working software fast: prototypes, integrations, agents, pipelines and evaluation harnesses.
4. Ships to production and stays through the unglamorous stabilization phase.
5. Carries insight back to the core product team: what’s missing, what’s broken, what every customer keeps asking for.

That last point is what separates an FDE from a consultant. A consultant delivers a project and leaves. An FDE’s work is meant to harden into the product itself. The first customer’s custom integration becomes the second customer’s standard feature.

A good FDE is a product manager who can code, a consultant who ships, and an engineer who actually talks to users.

The Skill Stack: Why These People Are Hard to Find

If the role sounds like it requires superhuman range, that’s because it nearly does. Great FDEs combine:

• Strong engineering fundamentals. They write production-quality code across the stack, not just notebooks.
• Applied AI fluency. They understand prompting, retrieval, agents, fine-tuning trade-offs and, critically, how to evaluate model behavior.
• Customer empathy. They can sit with a frustrated operations manager and translate vague pain into a precise specification.
• Comfort with ambiguity. There is no ticket queue. The problem is whatever turns out to be true when they arrive.
• Communication. They explain technical trade-offs to executives and operational details to engineers, often in the same afternoon.

Traditional career ladders rarely produce this combination. Pure software engineers often avoid customer contact. Pure consultants often can’t build. The FDE sits in the overlap, and the overlap is small.

Why Demand Is Exploding Now

Several forces converged at once.

1. The demo-to-production gap is now the bottleneck. Anyone can prototype with an API in an afternoon. Companies discovered that turning that prototype into something reliable, secure and trusted inside a large organization is the actual hard problem. Pilots stall at the same stage across industries.

2. AI vendors need proof, not promises. When the product is probabilistic, customers want to see it work on their data before committing. Putting an engineer on site is the fastest way to turn skepticism into a signed renewal.

3. Enterprise buyers are cautious. Banks, hospitals, insurers and governments don’t hand sensitive systems to a self-serve tool. They want a human accountable for making it work.

4. The product is still being discovered. AI capabilities change so quickly that nobody fully knows the best use cases. FDEs act as scouts, finding what works in the field and reporting back faster than any survey could.

Notably, this isn’t just a startup phenomenon. AI labs and AI-native companies have been building out deployment teams, and job postings using the title have grown sharply as the market moved from experimentation to rollout. The label that once belonged to a single company has become a category.

How an FDE Differs From Roles You Already Know

The Honest Trade-Offs

The model isn’t free of tension. FDE-heavy companies must guard against becoming a services business in disguise: custom work that never productizes, margins that never improve and engineers who burn out living on the road. The best organizations treat every deployment as research, and the measure of success is how much of the custom work they can absorb into the product.

For individuals, the role is demanding. It rewards people who like variety, autonomy and visible impact, and it punishes those who want a predictable sprint cadence and a quiet desk.

The Bigger Picture

There’s a quiet irony here. For decades, the dream of software was to remove humans from the loop: build once, sell infinitely. AI, the most powerful software ever created, is bringing humans back into the loop at the point where it meets reality.

That isn’t a flaw in the technology. It’s what happens when a technology becomes powerful enough to touch the core of how organizations work. Power requires fit, and fit requires someone willing to move in, learn the terrain and build.

The next time you read about a breakthrough model, remember that its real-world impact will be decided somewhere less glamorous: in a conference room, over a messy spreadsheet, by an engineer with a badge and a laptop who refused to accept “it works in the demo.”

In the next article, I’ll break down the value FDEs create and walk through a case study.

The Engineer Who Moves In: Why the Forward Deployed Engineer Is AI’s Most Important New Job was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a moment every security person eventually has with space. You’re reading the news, you see a headline about a jammed GPS signal or a “communication anomaly” on a military satellite, and you realize you have absolutely no mental model for what just happened. Was it a hack? A solar flare? Someone with a truck-mounted jammer near a border? For most of us, space cybersecurity is a black box wrapped in acronyms and classified briefings.

That’s exactly the gap the Aerospace Corporation set out to close in 2022, when it released a framework called SPARTA, Space Attack Research and Tactic Analysis. If you’ve spent any time in enterprise security, the name of its inspiration will click immediately: MITRE ATT&CK, the matrix that reshaped how defenders think about adversary behavior on the ground. SPARTA takes that same idea and points it at the sky.

This article is the “what is it” primer. In the next one, I’ll dig into how SPARTA and MITRE ATT&CK actually compare, tactic for tactic. For now, let’s get oriented.

Why space needed its own framework in the first place

For decades, the working assumption in the space industry was that spacecraft were basically unhackable by virtue of being, well, in space. Proprietary protocols, obscure hardware, physical distance, it all added up to a kind of security-through-obscurity that nobody had to think too hard about.

That assumption has quietly expired. Modern spacecraft run on commercial off-the-shelf components, connect to ground networks that look a lot like any other corporate IT environment, and increasingly rely on software-defined radios and cloud-based mission operations. The very things that made space systems cheaper and faster to build also made them look a lot more like every other target on the internet.

The Aerospace Corporation, a federally funded research center that’s been involved in space systems engineering since before most of us were born, noticed a specific problem: there was no shared vocabulary for talking about space-cyber threats. Researchers, engineers, and defenders were all describing the same kinds of attacks in different ways, which made it hard to share intelligence, compare notes, or build countermeasures that actually generalized. SPARTA was built to fix that, a common language, backed by unclassified research, that spacecraft developers, owners, and operators could actually use.

The bones of the framework: tactics, techniques, and countermeasures

If you’ve ever looked at MITRE ATT&CK, SPARTA’s structure will feel instantly familiar, and that’s intentional, Aerospace built it explicitly on that foundation.

At the top level, SPARTA organizes adversary behavior into tactics, the “why” behind an action. Nine of them, covering the full lifecycle of an attack:

• Reconnaissance: gathering information to plan an operation
• Resource Development: building the tools and infrastructure needed to attack
• Initial Access: getting a foothold on the spacecraft or its supporting systems
• Execution: running malicious code once inside
• Persistence: staying there
• Defense Evasion: avoiding detection
• Lateral Movement: spreading through connected systems
• Exfiltration: getting data out
• Impact: the actual damage - denial, degradation, destruction, or manipulation

Underneath each tactic sit techniques, which describe “how”, the specific method an attacker might use to achieve that goal. And underneath techniques are sub-techniques, which get even more granular. This is where SPARTA earns its keep as a space-specific tool rather than a copy-paste of an IT framework: the sub-techniques reflect things you’d never see in a corporate threat model, like compromising a mission collaborator’s ground segment, exploiting flight software update mechanisms, or manipulating telemetry to mask an intrusion.

Crucially, SPARTA doesn’t stop at describing the attack. Every technique is mapped to countermeasures, concrete engineering and operational steps that reduce the risk of that specific technique succeeding. That’s the part that turns this from an academic taxonomy into something an engineer can actually act on during system design.

The attack surface is bigger than you think

One of the most useful mental shifts SPARTA forces on you is realizing that “hacking a satellite” almost never means someone beaming code directly at the spacecraft from a laptop in a movie-villain lair. The real attack surface spans the entire mission architecture.

SPARTA breaks this down roughly into the ground segment (mission control centers, ground stations, the software supply chain feeding into them), the link segment (the RF uplinks, downlinks, and crosslinks carrying commands and telemetry), the space segment (the bus and payload themselves), and the user segment (the terminals and people actually consuming the mission’s data). An attacker doesn’t need to touch the spacecraft at all if they can compromise a contractor’s laptop that has access to the ground station, or exploit a trust relationship with a partner agency. That’s arguably the single biggest lesson SPARTA teaches newcomers: space cybersecurity is mostly still cybersecurity. It just has a few extra rooms in the house and one of those rooms is currently orbiting the Earth at 17,000 miles an hour.

Walking through an example, tactic to technique to sub-technique

Abstractions are easier to grasp with a concrete walk-through, so let’s take one tactic: Initial Access and follow it down the tree.

Under Initial Access, SPARTA catalogs techniques like compromising the supply chain, exploiting a trusted relationship, hitting a public-facing application, compromising a ground system, or using a rogue external entity to gain a foothold. Drill into “compromise trusted relationship” and you find a sub-technique specifically about compromising a mission collaborator, say, a university partner or an international agency with legitimate access to some part of the mission. That’s a threat vector that barely registers in a typical corporate threat model but is a very real concern for a space program juggling dozens of contractors, universities, and international partners across a mission’s lifetime.

This layered structure is what makes SPARTA genuinely useful rather than just a poster on a wall. A systems engineer designing a new bus can walk the matrix during a threat modeling session, ask “which of these techniques apply to our architecture,” and pull the associated countermeasures straight out of the framework instead of reinventing security requirements from scratch.

Who’s actually supposed to use this

SPARTA was built with a few overlapping audiences in mind. Spacecraft developers and systems engineers can use it during design to bake in defense-in-depth from day one rather than bolting security on after launch, which, for a satellite, is a genuinely bad time to discover a gap. Operators and defenders can use it to structure detection and response, the same way a SOC analyst might map alerts to ATT&CK techniques. And researchers and red teams use it as a shared vocabulary for describing what they found, so that a vulnerability disclosed by one lab is immediately legible to everyone else in the field.

It’s worth noting that SPARTA is unclassified by design. That’s a deliberate choice Aerospace wanted something the whole community could use, including commercial operators who don’t have security clearances but absolutely have satellites worth protecting. Given how fast the commercial space sector has grown, mega-constellations, small satellite operators, university CubeSat programs, that openness matters. A framework locked behind classification would have helped a handful of government programs. An unclassified one helps the entire ecosystem, including companies that a few years ago wouldn’t have had a dedicated security team at all.

Why this matters even if you’ll never touch a satellite

You don’t need to work in aerospace for this to be relevant. GPS timing underpins financial transactions. Weather satellites feed the forecasts that agriculture and aviation depend on. Communication satellites carry everything from disaster response coordination to the internet service reaching rural communities. The infrastructure SPARTA is trying to protect is, increasingly, just infrastructure, full stop, no qualifier needed.

What I find genuinely encouraging about SPARTA isn’t just the matrix itself, it’s the instinct behind it: take a domain that used to run on obscurity and classification, and instead build something open, shared, and continuously updated by a community. That’s the same instinct that made MITRE ATT&CK one of the most useful things to happen to enterprise security in the last decade. Watching that same playbook get applied to orbit feels like exactly the right move at exactly the right time, because the threats aren’t waiting for the industry to catch up.

In the next piece, I’ll put SPARTA and MITRE ATT&CK side by side, where they overlap, where space genuinely demands something different, and what that tells us about the future of threat modeling as more of our infrastructure leaves the ground entirely.

If you’re into frameworks like this, the unglamorous plumbing that quietly keeps complex systems secure, follow me for the next one. I write about cybersecurity, space systems, and the places where the two increasingly collide.

What Is SPARTA? The Framework Quietly Teaching Us How Satellites Get Hacked was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a thought experiment I use when reviewing AI systems with clients. Imagine your model starts giving subtly wrong answers, not dramatically wrong, not obviously broken, but consistently nudged in a direction that benefits someone other than your users. Recommendations that skew toward certain products. Risk assessments that systematically underweight certain factors. Summaries that omit particular kinds of information.

Now the question: how long would it take you to notice?

For most organizations, the honest answer is weeks. Possibly months. Possibly never, if the nudge is calibrated carefully enough to stay below whatever threshold triggers an alert.

That’s what data and model poisoning looks like in practice. Not a dramatic breach. Not a system going offline. A slow, deniable drift in model behavior, seeded before deployment, expressing itself quietly in production. OWASP classifies this as LLM04: Data and Model Poisoning, and it sits at the intersection of two uncomfortable truths: AI systems are shaped by data we often can’t fully audit, and the effects of that shaping are genuinely difficult to detect.

Two Flavors of the Same Problem

Poisoning attacks on AI systems come in two broad forms that are worth distinguishing, because they operate at different points in the model lifecycle and require different mitigations.

Training data poisoning happens upstream. An attacker introduces malicious examples into the dataset used to train or fine-tune a model. The model learns from those examples along with the legitimate ones, and the malicious content shapes its behavior in ways the attacker intended. The attack surface for this is wider than most people realize: for models trained on scraped internet data, an attacker can potentially influence training data simply by publishing content to sources the scraper will index. For fine-tuning datasets assembled from customer interactions, internal documents, or community contributions, anyone with write access to those sources has a potential poisoning vector.

Model weight tampering, the other half of LLM04, operates at the artifact level. Rather than influencing training, an attacker directly modifies a trained model’s weights to alter its behavior. This is the supply chain attack described in the previous article, viewed from the poisoning angle: instead of intercepting the model in transit, the attacker modifies it at rest, introducing a backdoor that activates under specific conditions.

Both produce the same effect: a model whose behavior has been deliberately shaped to serve the attacker’s goals rather than the developer’s intentions. The difference is when and how the corruption enters the system.

The Backdoor That Fine-Tuning Won’t Remove

One of the more alarming findings from academic research over the past three years is that backdoors introduced through data poisoning can survive fine-tuning. This matters enormously for the real-world deployment pattern, which almost always involves taking a pre-trained base model and fine-tuning it on domain-specific data.

The conventional intuition is that fine-tuning on clean data should wash out the effects of poisoned pre-training. The research suggests otherwise. Backdoor behaviors can be dormant during normal operation and active only when a specific trigger is present, a particular phrase, a specific formatting pattern, a certain kind of prompt structure. Fine-tuning on clean data updates many of the model’s weights, but if the backdoor is implemented efficiently enough in the base model, the fine-tuning process doesn’t reach the weights that encode it.

MITRE ATLAS documents this class of attack under its ML Model Backdoor technique, with case studies demonstrating practical implementations in both natural language and computer vision domains. The implication for practitioners is direct: you cannot assume that fine-tuning a model on your own clean data makes it safe if the base model was compromised. The compromised base model is a risk that needs to be assessed and mitigated before you build on top of it, not after.

What Targeted Poisoning Actually Looks Like

Abstract descriptions of poisoning attacks can make them feel academic. Let me make this concrete with the kind of scenario that appears in real threat models.

Suppose you’re building an AI system to assist loan officers with initial risk assessment, a RAG-based system that retrieves relevant policy documents and historical cases, and generates a structured summary to inform the officer’s decision. The fine-tuning dataset for this system was assembled partly from synthetic examples your team generated, and partly from historical case records.

An insider with access to the historical case records or an external attacker who compromised the system that stores them, introduces a small number of carefully crafted records into the dataset. Each poisoned record is individually plausible. The cases look like legitimate historical data. But across those records, a pattern is encoded: loan applications from a particular demographic, or with a particular structure, or involving a particular type of collateral, are associated with artificially positive risk summaries.

The fine-tuned model learns this pattern. Not from a single dramatic injection, but from a consistent statistical signal embedded in a subset of its training data. The model passes all standard benchmarks because the backdoor is narrow, it only activates on inputs with specific characteristics. In production, it introduces a systematic bias that benefits whoever planted the poisoned records, and disadvantages the people on the wrong side of the pattern.

This scenario isn’t hypothetical in its mechanics. It’s a straightforward application of targeted poisoning techniques that researchers have demonstrated in controlled settings. The question isn’t whether this class of attack is possible. It’s whether your organization would detect it.

Why Detection Is Genuinely Hard

The challenge with data poisoning detection is that you’re looking for a signal that was designed to be invisible. A skilled attacker doesn’t introduce obviously wrong examples, that would be caught by basic data validation. They introduce examples that are locally plausible, pass automated checks, and are individually indistinguishable from legitimate data. The attack lives in the aggregate statistical pattern, not in any single data point.

This means the standard quality assurance process, reviewing samples of training data, checking for formatting errors, filtering for obvious anomalies won’t catch a sophisticated poisoning attack. The reviews look at individual data points. The attack is in the distribution.

The controls that do work are more expensive:

Statistical anomaly detection on training data distributions. If you’re assembling a fine-tuning dataset from multiple sources, analyzing the statistical properties of data from each source, label distributions, feature correlations, outlier rates can surface poisoning that’s localized to one source. This requires having a clear prior expectation of what the data distribution should look like, which itself requires investment in data documentation.

Behavioral red-teaming against known backdoor trigger patterns. If backdoors activate on specific trigger patterns, systematic testing with prompts that match those patterns can expose them. This only catches backdoors whose trigger patterns you can anticipate which is why it should be combined with broader adversarial testing rather than relied on as a primary control.

Data provenance and access controls. The most reliable control for poisoning attacks is controlling who can introduce data into your training pipeline. Treating training data as a privileged artifact with the same access controls, audit logging, and integrity verification you’d apply to production configuration limits the attack surface dramatically. If only a small number of vetted people can write to the fine-tuning dataset, the insider threat and external compromise scenarios become significantly harder.

Model behavior monitoring in production. Because pre-deployment detection is imperfect, post-deployment monitoring is essential. If a backdoor activates in production, you want to detect it through behavioral drift, outputs that deviate statistically from expected distributions on inputs with specific characteristics. This requires establishing a behavioral baseline before deployment and monitoring against it continuously. The NIST AI RMF’s Measure function includes ongoing output monitoring as a core component of responsible AI deployment; for poisoning risks, this isn’t optional.

The Organizational Accountability Question

The NIST AI RMF’s Govern function asks a question that sounds simple and turns out to be genuinely hard: who is accountable when an AI system behaves harmfully?

For poisoning attacks, this question has a specific edge. If a model produces systematically biased outputs because its training data was corrupted, the harm may be distributed across many decisions, affecting many people, with no single incident that clearly signals something is wrong. By the time the pattern is detected, it may have been operating for months. The people affected may not even know that an AI system was involved in the decision that harmed them.

This is why the governance structure around training data , who can contribute to it, how contributions are reviewed, who signs off on a dataset before it’s used, isn’t a bureaucratic detail. It’s the accountability structure that determines whether you can answer the question “how did this get into the training data?” when something goes wrong.

Organizations that have invested in that governance structure, formal data intake processes, provenance documentation, access auditing , have a much shorter path to both detection and remediation when a poisoning incident occurs. Organizations that haven’t will find themselves trying to reconstruct a chain of custody for training data after the fact, which is extraordinarily difficult and often impossible.

The Uncomfortable Conclusion

Data and model poisoning sits in an uncomfortable place in the AI security landscape: it’s technically sophisticated enough that many practitioners don’t engage with it seriously, but operationally grounded enough that organizations willing to treat training data with rigor can meaningfully reduce their exposure.

The technical controls, anomaly detection, behavioral testing, provenance tracking, are not exotic. They’re applications of existing data engineering and security discipline to a new context. What’s exotic is the threat model: the idea that an attacker would invest effort in corrupting training data rather than attacking the running system. But the investment calculus for that attacker can be favorable. A successful poisoning attack is deniable, persistent, difficult to detect, and affects every decision the model makes for as long as it’s deployed.

The organizations that will navigate this well aren’t the ones with the most sophisticated ML security tools. They’re the ones that treated their training data as a security-critical asset before they knew they needed to. That means now, before the models are deployed, while the pipelines are still being built and the governance structures are still malleable.

The corruption you can’t see is still corruption. And the time to look for it is before it’s already doing its work.

If you’ve read this far, you know this isn’t surface-level stuff and there’s more coming. I’m covering the full OWASP LLM Top 10 through the lens of architecture and deployment security, and the next articles tackle prompt injection and the vector/embedding weaknesses that affect RAG systems. Follow along so you don’t miss it and if this was useful, share it with someone who’s building AI systems without a security lens. They might need it more than they know.

This article is part of a series on AI application security, drawing on the OWASP LLM Top 10 (2025), MITRE ATLAS, and the NIST AI Risk Management Framework.

The Corruption You Can’t See: Understanding Data and Model Poisoning in Production AI was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few weeks ago I fell down a rabbit hole that started, as these things do, with a scary headline. Something like: “AI models can now hack computers and copy themselves onto new machines.” My first reaction was the same one I imagine a lot of people had a mix of “wait, what?” and “okay, is this real or is this hype?”

So I spent a weekend actually reading the research instead of just the headlines. What I found was more nuanced, more interesting, and honestly more unsettling in a slower-burning way than the clickbait version. I wanted to write it down in plain English, because I think most of us are getting a distorted picture from two directions at once: journalists who need a punchy headline, and AI companies who for genuinely mixed reasons but keep using words like “existential risk” in the same breath as “our product roadmap.”

Here’s what I actually learned.

Wait, is AI copying itself right now?

Not in the way the headlines imply. Nobody’s laptop is quietly spawning AI clones in the night.

What’s actually being studied is something researchers call autonomous replication. It’s a specific, testable question: if you gave a capable AI agent a model hooked up to a web browser, a coding environment, and a cloud computing account, could it, on its own, complete this chain of steps?

1. Get a copy of its own model weights (the huge file of numbers that is the AI)
2. Rent computing power somewhere else, using stolen credentials, a fake account, or its own money
3. Install and configure itself to actually run on that new machine
4. Get past whatever security or identity checks stand in the way
5. Optionally, do it again from the new location

This isn’t a hypothetical thought experiment anymore, it’s an actual category of safety test that labs and independent evaluators run against new models before they’re released. Groups like METR (an independent AI evaluation nonprofit) and the UK’s AI Security Institute have built structured benchmarks for exactly this. The UK institute’s benchmark, called RepliBench, breaks the challenge into four buckets: obtaining the model’s weights, getting compute resources, setting up the software environment, and executing the actual self-copying.

The current verdict, as of the research I could find, is reassuring: today’s frontier models have a lot of the individual pieces but can’t reliably chain them together into a full, working escape plan. They can navigate a cloud provider’s website. They can write code that copies files around. In one evaluation, a model even tried to convince a human to solve a CAPTCHA for it by claiming to be visually impaired, which is a delightful and slightly chilling sentence to type. But actually pulling off persistent, undetected replication in a real, defended environment? Not yet, according to the evaluators.

There’s an important asterisk here, though. Some academic groups working with smaller, open-weight models in controlled lab environments , not production security setups, have gotten much higher success rates on simplified versions of this task. That’s led to headlines saying self-replication is “no longer purely theoretical.” Which is technically true. But cybersecurity experts quoted in that same coverage were quick to point out that real-world networks have defenses that lab setups don’t, and that modern AI models are enormous, genuinely hard to move around and hide, even if you wanted to.

So: not science fiction, but also not an emergency happening in your web browser right now. It’s a capability trend line that’s climbing, being watched closely, and hasn’t crossed the danger threshold as far as anyone testing it publicly can tell.

Then why do the people building this stuff sound so scared?

This was the part that actually confused me most, and I think it confuses a lot of people. Why would the CEOs and lead researchers at the companies building AI also be the ones signing open letters comparing it to nuclear war?

A few things are going on at once, and I don’t think it’s fair to reduce it to just one motive.

First, there’s a real, substantive argument, and it goes roughly like this. Modern AI systems aren’t programmed with explicit rules the way older software was, they’re trained on enormous amounts of data, and even the people who build them can’t fully explain why a given model produces a given output. That’s a genuinely strange position to be in as an engineer. On top of that, we don’t yet have a reliable way to guarantee that a very capable AI system’s goals stay aligned with what we actually want, especially as these systems get better at long, independent tasks with less human supervision at each step. That open problem is usually called “the alignment problem,” and it doesn’t have a solved answer yet. Researchers worried about this aren’t imagining a moustache-twirling evil computer, they’re worried about a system that’s extremely good at optimizing for something, and that something turning out to be subtly not what we meant.

Second, there’s competitive dynamics. Multiple companies, and multiple countries, are racing to build more capable systems, partly because whoever gets there is worried someone less careful will get there first. That’s a classic race-to-the-bottom setup, and some of the loudest safety warnings are, honestly, also an attempt to get regulators and the public to slow the whole field down together, which is hard for any single company to do unilaterally without losing the race.

Third and I think this deserves to be said plainly, public alarm is also just useful. It builds attention, it can be a competitive signal (“look how powerful our thing must be if we’re this worried about it”), and it shapes regulation in ways that sometimes favor incumbents who can afford compliance costs that startups can’t. I’m not saying every warning is cynical. I think the honest picture is that the concern is real and the incentives around expressing it are also messy, and both of those things are true simultaneously.

Where I landed, after reading a lot of this, is that it’s a genuinely unresolved and contested debate even among serious experts. Some very credentialed researchers think extinction-level risk from AI is a real and underrated possibility. Other equally credentialed researchers think that framing is a distraction from more immediate, less exotic harms, job displacement, bias, disinformation, concentration of power in a handful of companies. I don’t think there’s a settled answer, and I’d be suspicious of anyone who tells you there is.

So are they actually trying to build a “superintelligence”?

Yes, more or less openly. Several of the major labs state this as their explicit mission building AI systems that meet or exceed human capability across most domains, sometimes called AGI (artificial general intelligence), with “superintelligence” as the term for something that goes further still.

What surprised me is that there isn’t some separate, secret research track for this. It’s the same work that produces every new model release, just aimed further down the same road:

• Scale. Bigger models, more training data, more computing power. The underlying bet is that this alone keeps unlocking new capabilities, which has mostly held up so far, though there’s real debate about diminishing returns.
• Better training for reasoning and autonomy. A lot of recent progress isn’t about raw size it’s about training models to plan, use tools, and work on long tasks over extended stretches, rather than just answering one prompt at a time.
• AI helping build better AI. This is the one that gives people the most pause. Labs are actively researching whether AI systems can help design their own training methods, write better code, or speed up chip design. If that works well, progress could compound faster than expected, which is the scenario researchers mean when they talk about an “intelligence explosion.”
• Safety research running in parallel, at least in theory. This includes interpretability work (trying to understand what’s actually happening inside these models, rather than treating them as black boxes), and the capability evaluations we already talked about the tests designed to catch dangerous abilities before a model gets released to the public.

Nobody has a proven theory guaranteeing this path leads to superintelligence, or a reliable timeline for when it might. Predictions from serious people inside these companies range from a few years to “this might not be the way it happens at all.” That range alone tells you something about how uncertain even the experts are.

What I took away from all this

I went into this expecting to either get scared or debunk it. I ended up somewhere less satisfying: this is a real, actively contested area of both engineering and public debate, not a settled crisis and not empty hype either. The self-replication research is a genuine safety test that’s finding real, if partial, capabilities worth tracking, not worth losing sleep over today. The extinction-risk conversation is a real disagreement among smart people about deep uncertainty, tangled up with competitive incentives that make it hard to fully trust anyone’s motives, including the people sounding the alarm.

If there’s one thing I’d want a reader to take from this, it’s just: be suspicious of anyone selling you certainty in either direction. The people building this technology don’t have it. That’s kind of the whole story.

This is my attempt to make sense of a topic that’s easy to get either too cynical or too alarmed about. If you’ve read the underlying research and see it differently, I’d genuinely like to hear it in the comments.

The Robots aren’t coming to get you but here’s why their creators are nervous was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A large European bank recently processed its millionth automated mortgage application. No human touched it. An AI model evaluated the applicant’s financial profile, cross-referenced it with property data and market conditions, assessed risk, and issued a binding decision, all in under four minutes.

A decade ago, that same process took a loan officer three to five business days.

This isn’t a hypothetical future. It happened. It’s happening right now, across industries, in organizations that have made a serious commitment to what technology researchers and business strategists are calling hyperautomation, the orchestrated, intelligent, end-to-end automation of business processes using AI, machine learning, robotic process automation, and a constellation of other technologies working in concert.

In my last piece, I explained what hyperautomation is and why it matters. Now I want to get into the harder, more interesting question: what does it actually look like inside organizations that are doing this well? And what separates them from the ones whose automation programs stall out after a few promising pilots?

The Old Model: Automation as a Cost Center

For most of the last two decades, enterprise automation was treated as an IT project. Leadership would identify a painful manual process, often something in finance, HR, or customer service and authorize a project, bring in a vendor, and deploy a solution. Six months later, a bot was running. Time savings were measured. ROI was calculated. Everyone moved on.

The problem was that this approach was fundamentally reactive and fragmented. Different departments deployed different tools. There was no shared architecture, no data sharing between automated systems, no consistent governance. And because automation was managed by IT as a service delivered to the business, the business never really owned it.

The result was often what practitioners now call “automation islands”, isolated pockets of efficiency surrounded by manual operations. A company might automate invoice processing in finance while their contract management team is still drowning in spreadsheets. Their customer onboarding bot works beautifully in isolation, but breaks whenever it touches the CRM, which was automated by a different team using different tools.

The islands don’t talk to each other. And the ocean between them is still entirely manual.

The New Model: Automation as Operating System

The organizations getting hyperautomation right have fundamentally different mental models.

They don’t think of automation as a project. They think of it as infrastructure, as foundational to the business as their ERP system or their cloud environment. They have a dedicated Center of Excellence (CoE) for automation, staffed by people who sit at the intersection of business knowledge and technical capability. They have an automation strategy that cascades from the C-suite down. And they have a platform approach that ensures all automation assets share common architecture, governance standards, and critical data.

In these organizations, automation is not something done to the business by the IT department. It is something the business owns, operates, and continuously expands.

The difference in outcomes is striking. Organizations with a mature, platform-based approach to hyperautomation consistently report three to five times better returns than those pursuing ad hoc, project-by-project automation. And they scale dramatically faster, because when your foundation is solid, adding new automation becomes a matter of configuration rather than construction.

How It’s Reshaping Specific Functions

Let me walk through what hyperautomation looks like in practice across different organizational functions, because the abstract case studies only get you so far.

Finance and Accounting is where hyperautomation typically starts and goes deepest. The transactional volume is high, the processes are well-defined, and the data lives in systems that are relatively easy to connect. Organizations using hyperautomation in finance are running fully automated accounts payable cycles, real-time reconciliation, automated financial close processes that once took two weeks of manual effort, and predictive cash flow modeling that updates dynamically as business conditions change. The CFO’s office stops being a factory for reports and becomes a center for strategic financial analysis.

Human Resources is perhaps the most surprising territory for hyperautomation, but some of the most impressive transformations are happening here. AI-powered systems are screening thousands of resumes against multi-dimensional criteria in the time it would take a recruiter to open their email. Onboarding workflows that once required coordination between HR, IT, legal, and facilities, an error-prone process that could stretch weeks, are now triggered automatically the moment an offer letter is signed, provisioning accounts, scheduling orientation, generating compliance paperwork, and assigning training modules without a single human coordinating step.

Customer Service is being fundamentally restructured. The first line of defense is now AI, conversational agents that handle routine inquiries, process returns, update account information, and resolve common complaints without escalation. But the sophisticated implementations go further: they route complex cases to the right human agent with a pre-assembled case history, sentiment analysis, and a suggested resolution path. The agent’s job changes from processing to judgment. Average handle times drop. Customer satisfaction scores go up.

Supply Chain and Operations may represent the highest-stakes frontier for hyperautomation. AI models that synthesize sales data, inventory levels, supplier lead times, logistics capacity, and weather forecasts to recommend and in some cases autonomously execute inventory and procurement decisions are becoming standard in advanced manufacturing and retail. The manual work of coordinating between systems is disappearing. What replaces it is a real-time operational intelligence layer that keeps humans informed and intervenes with recommendations exactly when judgment is needed.

The Five Traits of Organizations Getting This Right

After looking at dozens of hyperautomation programs, successful and failed, certain patterns emerge. The ones that succeed tend to share five characteristics.

First: Executive sponsorship that is genuine, not performative. Hyperautomation touches processes across every department. Turf wars, resistance from middle management, and competing technology priorities will derail any program that doesn’t have a senior executive with real authority willing to clear obstacles. The most successful programs have a C-level owner, often a Chief Automation Officer or Chief Digital Officer, who treats hyperautomation as a business transformation priority, not an IT initiative.

Second: A process-first mentality. The biggest mistake in automation is automating bad processes. If a workflow is inefficient, fragmented, or poorly designed, automating it doesn’t fix it, it just makes the problem run faster. Organizations that succeed at hyperautomation invest heavily in process mining and redesign before they automate. They map how work actually flows. They eliminate unnecessary steps. They simplify hand-offs. Then they automate what remains.

Third: Change management at the center, not the edge. Hyperautomation changes jobs. Some jobs change dramatically. Some disappear. Some become more interesting and higher-value. None of this happens smoothly without deliberate, sustained communication, training, and support for the people affected. Organizations that treat change management as an afterthought, something to handle once the technology is deployed , experience resistance, low adoption, and workforce disruption that undercuts the business case. The ones that treat change management as equally important to the technical work see dramatically different outcomes.

Fourth: Data quality as a prerequisite, not an assumption. AI and machine learning only work as well as the data they’re trained on. Organizations with fragmented, siloed, or dirty data cannot build reliable automated intelligence. The most mature hyperautomation programs have invested seriously in data infrastructure, data lakes, unified data models, master data management, real-time integration pipelines. This is foundational work that is unglamorous and often underestimated.

Fifth: Continuous measurement and iteration. Hyperautomation is not a one-time deployment. It’s a living system. The organizations getting it right are measuring the performance of every automated process against defined KPIs, using those measurements to identify degradation or drift, and continuously refining their automation assets. They treat their automation portfolio with the same discipline they’d apply to a product portfolio.

The Question of Jobs

Any honest treatment of hyperautomation has to address this: what happens to workers?

The evidence from organizations that have implemented hyperautomation at scale is nuanced and often counterintuitive. In the short term, certain categories of work , particularly high-volume, repetitive, rule-based tasks are substantially reduced or eliminated. This is real, and it requires honest planning and support for displaced workers.

But in the medium term, something else tends to happen. The elimination of low-value work frees people to do high-value work. Customer service agents who spent 60% of their time on data entry now spend 60% of their time on complex problem-solving and relationship-building. Financial analysts who spent their weeks pulling and formatting data now spend their weeks actually analyzing it. The nature of knowledge work shifts upward.

Simultaneously, hyperautomation creates new categories of work. Someone has to design, build, govern, and maintain the automation estate. The role of “automation developer” barely existed fifteen years ago. Today it’s one of the fastest-growing technical roles in enterprise organizations.

None of this means the transition is painless. It isn’t. Organizations that pretend otherwise are setting themselves up for workforce crises. But the long-term trajectory with thoughtful management is toward more meaningful work, not toward mass unemployment.

What’s Coming Next

We are still in the early stages of hyperautomation. The technologies are advancing rapidly, and several developments on the horizon will push capabilities further.

Agentic AI : AI systems that don’t just respond to inputs but proactively take action, make multi-step plans, and execute workflows with minimal human supervision, is beginning to move from research into production. When agentic AI is embedded in hyperautomation platforms, the scope of what can be automated will expand dramatically, reaching into complex, unstructured knowledge work that has so far resisted automation.

The integration of hyperautomation with the physical world through robotics, IoT sensor networks, and autonomous systems is collapsing the boundary between digital and physical operations. Warehouses, factories, logistics networks, and healthcare facilities are being redesigned around intelligent automation in ways that were science fiction a decade ago.

And the barriers to entry are dropping. Low-code and no-code tools mean that business users, not just engineers, can build and deploy sophisticated automated workflows. The democratization of automation will accelerate its adoption across organizations of every size and in every industry.

The Window Is Narrowing

Here is what I want to leave you with.

Hyperautomation is not a technology trend that organizations can afford to approach casually, to pilot indefinitely, to treat as someone else’s department’s problem. The operational advantages it creates in speed, cost, accuracy, scalability, and intelligence are compounding. Every month that high-performing organizations invest in building out their automation infrastructure, the gap between them and the organizations still deliberating widens.

This is not meant to generate anxiety. It’s meant to generate urgency. Because the organizations that act now, that invest seriously in the infrastructure, the talent, the process discipline, and the cultural change required to do this well, will emerge from the next decade with sustainable competitive advantages that will be very hard to close.

The hyperautomated company is not a vision of the future. It’s being built right now, by organizations that decided the time to act was today.

The only question worth asking is: which side of that divide do you want to be on?

If you found this useful, I’d genuinely appreciate it if you followed me here on Medium. I write about hyperautomation, AI, and how technology is reshaping the way organizations operate and compete written for people who want to understand these shifts in depth, not just at the surface level. There’s a lot more coming, and I don’t want you to miss it.

How Organizations Are Being Rebuilt From the Ground Up was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2020, a routine software update pushed to thousands of organizations contained a backdoor that went undetected for months. The SolarWinds attack didn’t succeed because the attackers were exceptionally clever at breaking into systems. It succeeded because the attackers understood something most defenders hadn’t fully absorbed: if you can compromise the supply chain, you don’t need to compromise each target individually. You let the targets install the compromise themselves.

The AI industry is about to learn this lesson the hard way.

We are in a moment of extraordinary dependency. Teams building LLM-powered applications are, almost without exception, building on top of components they didn’t create: pre-trained foundation models, open-source fine-tuning frameworks, community-contributed datasets, third-party embedding APIs, model hubs where anyone can publish weights under a permissive license. The speed of AI development has made this dependency structure essentially mandatory, nobody is training a frontier model from scratch to power their customer support chatbot.

That dependency structure is also an attack surface. And right now, most organizations have no systematic way of understanding what’s in it.

LLM03: The OWASP Category That Looks Like a Vendor Problem

The OWASP LLM Top 10 for 2025 classifies this as LLM03: Supply Chain, and the definition is deliberately broad: compromised pre-trained models, datasets, and third-party dependencies introduced before deployment. The “before deployment” framing is important. This isn’t about runtime attacks. It’s about the integrity of the components you assembled your system from.

Most security teams, when they encounter this category, treat it as a procurement problem. “We got the model from a reputable provider. We checked the license. We ran the benchmark.” That’s the equivalent of verifying that your SolarWinds renewal was processed correctly. The question isn’t whether the vendor is reputable, it’s whether you can verify that what you received is what you think you received, and whether anyone in the supply chain between origin and deployment had an opportunity to tamper with it.

For traditional software, we have tooling for this: software composition analysis, dependency scanning, SBOM generation, cryptographic signing of artifacts. The tooling is imperfect, but the discipline exists. For AI components model weights, training datasets, fine-tuning pipelines; the equivalent discipline is almost entirely absent from most organizations’ security programs.

What the Attack Surface Actually Looks Like

Let me be specific about the vectors, because “supply chain” is abstract enough to be easy to dismiss.

Model weight tampering. A pre-trained model is a file, typically a large binary blob of floating-point numbers. That file can be modified. If you download a model from a public repository, you are trusting that the weights you received are the weights the author published, and that the weights the author published are the weights that were produced by the training process they described. Each of those links in the chain is a potential point of failure. Model hubs are not immune to account compromise. Researchers have demonstrated that weight files can be modified to introduce backdoor behaviors that survive fine-tuning, meaning that even if you do additional training on top of a compromised base model, the backdoor may persist.

Dataset poisoning upstream. The training data for large foundation models is scraped from the internet at scale. The data for domain-specific fine-tuning often comes from curated but still external sources. An attacker who can influence what goes into a training dataset, by publishing content to a source that will be scraped, by contributing to an open dataset, by compromising a data pipeline can influence model behavior in ways that are extraordinarily difficult to detect after the fact. MITRE ATLAS documents this class of attack explicitly, including case studies of researchers demonstrating practical data poisoning in production-adjacent settings.

Third-party integration compromise. Beyond the model itself, LLM applications typically depend on a stack of third-party components: tokenizers, vector databases, embedding services, orchestration frameworks, evaluation libraries. Each of these is a dependency with its own supply chain. A compromised tokenizer can alter what the model actually processes relative to what the developer intended. A compromised embedding service can return manipulated representations that affect retrieval behavior. These are exactly the kinds of attacks that traditional software supply chain security is designed to catch but teams often don’t apply that same scrutiny when the dependency is AI infrastructure rather than application code.

The Verification Gap

Here’s the uncomfortable gap at the center of this problem: even if you wanted to fully verify the integrity of a pre-trained model, you largely can’t.

Traditional software artifacts can be verified against a hash. The hash tells you that the binary you received is byte-for-byte identical to the binary the vendor published. What it doesn’t tell you is whether the source code that produced that binary contains vulnerabilities, or whether the build environment was clean. This is why supply chain security for software has evolved beyond hashing toward things like reproducible builds and build provenance attestation.

For AI models, we don’t even have widespread hashing as a standard practice. Model cards, the documents that describe a model’s training process, data sources, and intended use are self-reported and unverified. Reproducibility of training runs is technically feasible in principle and practically difficult in almost every production scenario. The compute required to reproduce a frontier model training run in order to verify that the published weights match the claimed process is, for most organizations, simply not available.

This doesn’t mean verification is impossible. It means the practical controls need to be risk-proportionate and pragmatic:

Verify what you can verify. Cryptographic hashes for model weight files should be a baseline requirement. If a model provider doesn’t publish hashes, that’s a gap worth raising with them. If the hashes they publish don’t match what you downloaded, that’s an incident.

Treat provenance as a security property. Where did this model come from? What was it trained on? Who has had access to the weights? These questions should be part of a formal model intake process, not an afterthought. The NIST AI RMF’s Map function explicitly includes understanding the lineage of AI components as part of risk context. Organizations that have a model register, a formal inventory of what models they use, where they came from, and what they’ve been evaluated against are in a categorically better position than those that don’t.

Behave testing as a control. Because you often can’t verify the training process, behavioral testing becomes a meaningful signal. Red-teaming a model for anomalous responses, testing for known backdoor triggers, evaluating behavior under adversarial inputs, these are not replacements for supply chain integrity controls, but they provide partial coverage when those controls aren’t available. MITRE ATLAS includes case studies of researchers detecting backdoored models through systematic behavioral testing.

Apply software composition analysis discipline to AI dependencies. Your vector database library has CVEs. Your orchestration framework has a dependency tree. Your tokenizer has a published version with known issues. These components should go through the same SCA process as your application dependencies because they are your application dependencies, and calling them “AI infrastructure” doesn’t change that.

The Governance Question Nobody Has Answered Yet

The NIST AI RMF’s Govern function asks organizations to establish clear accountability for AI system behavior. For supply chain risk, this creates an organizational question that most teams haven’t answered: who owns the decision to trust a particular model or dataset?

In traditional software procurement, there’s usually a process. Legal reviews licenses. Security reviews the vendor’s security posture. Engineering evaluates the technical fit. Someone signs off. The component enters an approved list.

For AI models, especially open-source ones downloaded from public hubs, this process often doesn’t exist. An engineer finds a model that benchmarks well, pulls the weights, integrates it into a prototype, and the prototype becomes production. The formal intake process that would catch supply chain risks, the risk assessment, the provenance review, the behavioral evaluation never happened.

Building that intake process is an organizational change, not a technical one. It requires someone in the organization to own “AI component governance” as a function, with the authority to establish criteria for approved models and the mandate to ensure that new models go through review before reaching production.

Why This Will Get Worse Before It Gets Better

The AI model ecosystem is growing faster than the security discipline around it. Model hubs are adding thousands of new models per week. Fine-tuning pipelines are becoming simpler and more accessible, which means the gap between “I found an interesting base model” and “it’s in production” is shrinking. The economic incentive to build on top of existing components rather than training from scratch is only increasing as foundation models become more capable.

All of this is happening in an environment where the tooling for AI supply chain verification is roughly where software supply chain tooling was in 2015, nascent, inconsistent, not yet widely adopted, and not yet integrated into the standard security workflow.

The organizations that are going to weather the first wave of serious AI supply chain attacks are the ones that started treating AI components with the same rigor they apply to software dependencies before the attacks became common knowledge. That means building the intake process now. It means requiring provenance documentation now. It means asking hard questions of model providers now, even when those providers aren’t used to being asked.

The supply chain is already your attack surface. The question is whether you know what’s in it.

If you’re finding this series useful, it would genuinely mean a lot if you followed along , I’m covering the full OWASP LLM Top 10 through the lens of pre-deployment architecture review, and the next piece goes deep on data and model poisoning: what it looks like at the training layer, how it survives fine-tuning, and what you can actually do about it before you ship. Hit follow so you don’t miss it.

This article is part of a series on AI application security, drawing on the OWASP LLM Top 10 (2025), MITRE ATLAS, and the NIST AI Risk Management Framework.

The Model You Didn’t Build: Why the AI Supply Chain Is Security’s Next Blind Spot was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let me describe a class of vulnerability that’s been quietly living inside LLM applications since the first wave of production deployments. It doesn’t require a sophisticated attacker. It doesn’t exploit some obscure edge case in the model’s training. In many cases, the developer who introduced it never thought it was a security decision at all.

It’s called Improper Output Handling, LLM05 in the OWASP LLM Top 10 for 2025, and the reason it keeps appearing in architecture reviews is that most engineers building LLM-powered features think of model output as text. It is text. It’s also data that gets processed by other systems. And that distinction is everything.

The Old Problem Wearing a New Hat

If you’ve spent any time in application security, the pattern here will feel familiar. Injection vulnerabilities, SQL injection, command injection, XSS all share the same root cause: data that an attacker can influence flows into a system that interprets it as instructions, and the system doesn’t adequately distinguish between the two.

For decades, the data in question was user input: form fields, URL parameters, HTTP headers. The lesson security engineering absorbed, slowly and painfully, was that user input must be treated as untrusted and sanitized before it reaches any system that interprets it as structured data or executable instructions.

Now add a language model to the architecture. The model generates output. That output gets forwarded to a rendering engine, a database, a template system, a code execution environment, an email client, a browser. Does your sanitization logic still sit between the data source and the interpreter? Or did someone assume that because the model generated the content, it must be safe?

That assumption is the vulnerability.

What “Downstream Systems” Means in Practice

When people talk about LLM applications, they tend to picture a chat interface: user types something, model responds, response appears on screen. That’s accurate for some deployments. It’s increasingly rare for production systems.

In practice, LLM components are embedded in pipelines. A customer support bot doesn’t just respond to queries, it retrieves data from a CRM, generates a response, logs the interaction to a ticketing system, and potentially triggers follow-up workflows. A coding assistant generates code that gets executed. A document processing system generates structured output that gets parsed and stored. A marketing tool generates content that gets rendered in a browser.

Each of those downstream handoffs is a potential injection point. And the model’s output is the data crossing that boundary.

Consider a scenario where an LLM application retrieves customer emails, processes them for intent classification, and generates responses that include extracted data. An attacker sends an email that contains carefully crafted content, something like a hidden instruction embedded in normal-looking text. The model, trained to be helpful and to follow instructions, incorporates the attacker’s directive into its output. That output then flows to the ticketing system, which interprets certain patterns as commands. The attacker has just achieved indirect prompt injection that propagates into a downstream system.

This is not theoretical. MITRE ATLAS documents this class of attack. The technique involves an adversary embedding adversarial content in data that the model will encounter, not in a direct conversation with the model, but in an email, a document, a web page, a database record that the model retrieves as context. The adversarial payload travels through a legitimate data source and achieves execution when the model incorporates it into output that reaches an interpreter.

The Sensitive Data That Leaks Through the Output Channel

Improper Output Handling doesn’t only concern injection. It has a second, quieter failure mode: information disclosure. LLM02: Sensitive Information Disclosure describes how LLMs can leak confidential data, PII, or system details through their responses and the output handling layer is often where the controls should live but don’t.

A model trained on or given access to sensitive data will, under the right conditions, reproduce that data in its responses. The conditions don’t require an attacker. They can be as simple as a user asking a question that happens to be adjacent to sensitive information in the model’s context window. Retrieval-augmented systems are particularly vulnerable here: the retrieval step fetches documents the user might need; the generation step may include details from those documents that the user shouldn’t have.

I’ve seen this pattern in internal knowledge base applications where the retrieval system returns the ten most semantically similar documents to a query, and the LLM then generates a response that synthesizes all ten including the two documents the querying user didn’t have permission to see. The access control logic was implemented at the retrieval layer but not enforced at the generation layer. The model had no concept of the user’s permission level; it simply used everything in its context.

The NIST AI 100–2 document, published in January 2025, catalogs this as a failure of output governance, the absence of controls that verify what the model’s response is allowed to contain before it reaches the user. It’s a technical problem with an organizational dimension: someone needs to own the question of what is this model permitted to output, and how do we verify compliance at runtime?

The Three Places Teams Miss the Problem

In my experience reviewing LLM architectures, Improper Output Handling tends to slip through at three specific points:

At the rendering layer. Teams implement input sanitization, they strip dangerous characters from user queries before sending them to the model. They don’t implement equivalent output sanitization before the model’s response is rendered in a browser or passed to a document system. If the model can be manipulated into including JavaScript in its output, and that output is rendered without sanitization in a web context, you have stored XSS via an AI assistant. The attack surface is user-controlled data that the model might incorporate into its output, which is effectively unlimited in a general-purpose assistant.

At the code execution boundary. Coding assistants and AI-powered development tools generate code that often gets executed, either directly, as part of a CI/CD pipeline, or by a developer who trusts the model’s output without review. The model doesn’t have a concept of “this is a test environment” versus “this is production.” It generates code based on its training and context. An attacker who can influence what’s in that context can influence what code gets generated. Output that reaches an execution environment without review is a direct injection risk.

At the inter-service boundary. Microservice architectures that incorporate LLM components often pass model output between services as structured data JSON, XML, templated strings. Each of those formats has its own injection risks. A model that generates JSON output that gets parsed by a downstream service may produce output that’s structurally valid but semantically malicious if the attacker can influence the model’s output in the right way. Teams who handle SQL injection carefully in their application layer sometimes forget to apply the same thinking when the data source is a language model rather than a user form field.

What the Fix Actually Looks Like

The remediation pattern for Improper Output Handling draws on established secure development practices, because at its core, this is the same problem that’s always existed: don’t trust data from external sources, even when that source is your own AI component.

Treat model output as untrusted input to every downstream system. This is the mental model shift that matters most. The model may be your model, trained on your data, running in your infrastructure. Its output is still external data from the perspective of every system that receives it. Apply the same validation, sanitization, and encoding rules you’d apply to any other external data source.

Implement output filtering at the boundary, not inside the model. You cannot rely on the model’s training to prevent it from reproducing sensitive information or generating output that could cause injection in a downstream system. Those constraints need to be enforced at the output layer: before the response reaches the user, before it reaches a rendering system, before it crosses a service boundary. Content classifiers, regular expression filters for PII patterns, output schema validation, these are the controls that actually work at scale.

Enforce access control at the output layer, not just at retrieval. For RAG systems and knowledge base applications, the permission model needs to persist all the way to generation. If a document is outside a user’s access scope, the model should not be able to include information from that document in its response, not because the model knows the user’s permissions, but because the output layer validates what’s allowed before returning the response.

Log output, not just input. Most teams log user queries for monitoring and debugging. Far fewer log the model’s responses at the same level of detail. Output logging is essential for detecting information disclosure incidents after the fact, for auditing what the model actually communicated to users, and for identifying injection attempts that may have succeeded. The NIST AI RMF’s Measure function specifically includes monitoring AI outputs as part of ongoing risk assessment, you cannot measure what you don’t record.

The Framing That Makes This Tractable

The teams I see handling this well have internalized one framing that makes the problem tractable: the LLM is an external service, even when it’s internal.

Your language model is not part of your application logic in the way a function call is. It’s a component with nondeterministic behavior, influenced by inputs you may not fully control, capable of producing outputs you cannot fully predict. Treating it with the same trust assumptions you’d apply to a third-party API rather than the trust you’d extend to your own application code, leads naturally to the right security posture: validate its outputs, don’t expose it directly to interpreters, and never let its responses flow unexamined into systems that can take real-world actions.

That framing also makes the governance question answerable. If the LLM is an external service, then the question of what it’s permitted to output is a service interface contract question, not a training question. And interface contracts are something security and engineering teams know how to define, enforce, and audit.

The OWASP LLM Top 10 exists because these problems are real, recurring, and often underestimated. Improper Output Handling isn’t the most dramatic entry on the list. It doesn’t have the conceptual novelty of adversarial ML attacks or the visceral alarm of a data poisoning incident. But it’s the category most likely to bite a team that knows what it’s doing in traditional security, simply because it requires applying familiar principles in an unfamiliar context.

The context is new. The principles aren’t. That should make this one solvable.

This article is part of a series on AI application security, drawing on the OWASP LLM Top 10, MITRE ATLAS, and the NIST AI Risk Management Framework.

Your AI Assistant Is Piping Unsanitized Output Into Your Stack. Are You Sure That’s Fine? was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.