Twenty years ago I walked a new hire through a plant and told them: the most dangerous person on this floor isn't the one who breaks in through the loading bay. It's the one with a badge, a login, and a reason to be here that nobody questions. This week's prompt injection attacks — autonomous agents tricked into executing unauthorised cryptocurrency payments — prove that deployed agents are now that person. They hold valid credentials. They follow approved workflows. They have legitimate access to your ERP, your scheduling system, your supplier portal. Nobody vetted their judgment.

Prompt injection isn't hacking. It's social engineering — and your agent falls for it every time

I hold a Certified Ethical Hacker certification and spent enough time in penetration testing to know that the oldest tool in the attacker's kit isn't a zero-day. It's a phone call. A convincing email. A carefully worded request that makes the target want to help. Social engineering works because it exploits trust and authority, not because it defeats cryptography.

Prompt injection is the same attack, relocated. The target is a language model that has been given instructions in natural language and then exposed to additional natural language from an untrusted source. The injected text doesn't break a cipher. It asks. It fabricates context. And because the agent cannot reliably distinguish its original instructions from injected ones, it complies. The agent isn't being hacked in any technical sense — it's being conned. And like the most reliable insider a social engineer has ever cultivated, it never gets suspicious.

The recent payment attacks followed this pattern precisely. Hidden instructions embedded in content the agent was told to read directed it to approve transactions it had no business approving. The agent obeyed because obedience is what it does. No gate, no second pair of eyes, no stop authority between the injected instruction and the irreversible action.

Why your perimeter sees authorised activity

Your OT security stack — endpoint protection on SCADA servers, network segmentation around HMI stations, intrusion detection on the PLC layer — is looking for unauthorised access. Kaspersky's ICS CERT reported a marked increase in cyber attacks on manufacturing at the start of 2026, and vendors have responded with harder OT perimeters. Good. But prompt injection doesn't touch the perimeter.

The agent already has valid credentials. It authenticates normally. It calls the procurement API through the approved integration. The transaction matches a legitimate workflow pattern. Your SIEM logs it as normal activity because, structurally, it is normal activity. The attack lives entirely in natural language — in the semantic content of a prompt the agent received — and traditional security tooling has no instrumentation for that layer.

You could have the best OT security posture in your sector and still lose money to an agent that was told, in perfectly grammatical English, to pay an invoice that doesn't exist.

If the agent has the authority to act and no independent gate to stop it, you haven't deployed automation — you've delegated trust.

Write the PFMEA for your AI agent

In IATF 16949 and AS9100 environments, we assess every process failure mode the same way: severity, occurrence, detection. The framework doesn't care whether the failure originates in a weld robot, a stamping press, or a language model reading an email from a supplier portal.

Run the PFMEA. Severity: if your procurement agent executes a fraudulent payment, or your scheduling agent reroutes production capacity based on injected instructions, or your quality-routing agent suppresses a nonconformance flag because it was told to — what is the cost? In aerospace, a suppressed nonconformance isn't a financial loss. It's a certification issue. Occurrence: prompt injection is trivially easy to attempt and, without architectural controls, succeeds at rates that would make any auditor flinch. Detection: if your only detection layer is the agent's own judgment about whether an instruction is legitimate, your detection score is a coin flip with confidence.

That risk priority number would be unacceptable for a CNC process. It should be unacceptable for an AI agent with the same authority.

Consensus is the stop authority

I design and build multi-agent AI systems — including a platform called MultiPS that runs dozens of models in parallel with consensus synthesis. The reason I built consensus into the architecture wasn't academic. It was defensive.

When a single model receives an instruction, it either obeys or doesn't. When three independent models from different families, with different training, different system prompts, and no shared context must independently arrive at the same decision before a transaction executes, a single injected prompt cannot trigger action. The injected instruction would need to compromise all of them simultaneously, through different architectures, using the same natural-language payload. Possible in theory. The probability collapses by orders of magnitude.

This is the same principle as cross-functional engineering sign-off. An engineering change in an aerospace plant doesn't proceed on the authority of one engineer. Design, stress, manufacturing, quality — each reviews independently, each can stop the process. We've done this for decades because we learned, through expensive experience, that single-point authority on irreversible decisions is bad engineering. Consensus before action is that control applied to autonomous systems.

Key takeaways

  • Treat every deployed AI agent as an insider with credentials. Apply insider-threat logic, not perimeter logic.
  • Run a PFMEA on each agent's decision space. If the agent can take irreversible action without independent verification, the risk priority number demands a control.
  • Require multi-model consensus before any agent executes a financial transaction, supplier change, or quality disposition. A single model obeying a single instruction is not a control — it's a single point of failure.
  • Segregate instruction channels from data channels in your agent architecture. An agent that reads untrusted content and executes trusted actions in the same session is an attack surface, not a feature.

The manufacturers who get burned by this won't be the ones who avoided AI agents. It'll be the ones who gave their agents authority without verification — who treated deployment as the finish line instead of the starting line. The agents are here. The attacks are here. The only open question is whether your architecture treats them like the insider nobody vetted, or the insider everybody vetted — with controls, sign-off authority, and a stop button that actually works.