Ghosts in the Machine: Your AI Is an Insider — and Attackers Know It

By Dereck Coleman — Founder & Principal Pentester, Ghost Ops Security

There is a quiet assumption inside most organizations right now: that the AI assistant they switched on last quarter is just a smarter search box. Something you type into. Something that answers.

It is not just a search box. In more and more deployments, it is a participant. It reads your email so it can summarize it. It has access to your document store so it can answer questions about your contracts. It can file tickets, send messages, query databases, trigger workflows, and — increasingly — take actions on your behalf without a human reviewing each one.

Somewhere in that convenience, a boundary got crossed. The AI stopped being a tool you use and became an actor inside your environment. An actor with real access, real credentials, and no judgment of its own about who is allowed to tell it what to do.

Attackers understand this shift. Most defenders haven't caught up to it yet.

This piece is about closing that gap. We'll walk through what your AI is actually touching, how an attacker turns a trusted assistant into an insider operating inside your trust boundary, why pushing AI onto edge and IoT devices widens the problem, and — most importantly — what you do about all of it. For every attack, there's a defense. That's the part that matters.

A 50-Year-Old Bug Wearing a New Face

In 1988, a computer scientist named Norm Hardy described a problem he called the "confused deputy." The idea is simple and it has aged terrifyingly well. A confused deputy is a program that has legitimate authority to do something, and gets tricked by a less-privileged attacker into misusing that authority on the attacker's behalf. The program isn't compromised in the traditional sense. It's doing exactly what it was told. The problem is who got to tell it.

An AI assistant with tool access is the most powerful confused deputy we have ever built.

Think about what a modern AI agent holds. It may have an API token to your email. A connection to your file store. Permission to call internal services. The ability to browse the web and read whatever it finds. It sits in a position of trust — your systems treat its requests as authorized, because they are authorized. And it will faithfully carry out instructions.

The catch is that a language model cannot reliably tell the difference between instructions from you and instructions that arrive inside the data it's processing. To the model, it's all just text. If your AI reads a web page, an email, a document, or a support ticket that contains hidden instructions, it may follow those instructions with all the authority you gave it — while believing it's still serving you.

That's the whole attack in one sentence: the attacker doesn't need to break into your system if they can get a message to the AI that's already inside it.

> Why this is different from normal software: Traditional software separates code from data. Your database doesn't execute the contents of a customer's name field — and when it does, we call it SQL injection and treat it as a critical bug. Large language models erased that separation by design. Their instructions and their data are the same medium: natural language. That's what makes them useful, and that's what makes them exploitable.

What Your AI Is Actually Touching

Before we get to attacks, an honest inventory. Most organizations cannot answer the question "what can our AI reach?" with any precision. That's the root problem, so let's make it concrete.

When you connect an AI system to your business, you typically grant it some combination of:

- Read access to communications — email, chat, shared inboxes, so it can summarize and draft.

- Read (and sometimes write) access to documents — file shares, wikis, knowledge bases, contract repositories.

- Tool and API access — the ability to call functions: create a calendar event, open a ticket, run a query, post a message, hit an internal endpoint.

- Web access — the ability to fetch and read external content.

- Memory — persistence across sessions, so it "remembers" prior conversations and context.

- Autonomy — in agentic setups, the ability to chain several of these together and act without a human approving each step.

Each of these is reasonable on its own. Stacked together, they describe something that looks a lot like an employee — one with broad access, a helpful disposition, a perfect memory, and absolutely no instinct for when it's being manipulated.

Now ask the questions a pentester asks:

- If this AI can read email, and an attacker can send email, can the attacker put instructions in front of the AI?

- If this AI can browse the web, and an attacker controls a web page, can the attacker reach it?

- If this AI can call internal tools, what is the worst single action in its toolset — and what happens if it's triggered by someone who isn't you?

- If this AI has memory, can an attacker plant something today that fires next week?

The uncomfortable answer, in most current deployments, is "yes, and nobody is watching."

How the Attack Actually Works

Let's make this real. The mechanics matter for defense. Here are the technique classes every defender needs to recognize.

• Direct prompt injection. The simplest case. A user talks to the AI and tries to talk it out of its rules — persuading it to ignore its instructions, reveal its configuration, or misuse a tool. This is the version most people have heard of. It's real, but it's the least of your worries, because the attacker has to be talking to the AI directly.

  
  

• Indirect prompt injection. This is the one that should keep you up at night. The malicious instructions don't come from the person chatting with the AI — they come from the content the AI consumes while helping that person. A booby-trapped web page. An email crafted to be read by an AI summarizer. A document in your own file store that someone planted. A support ticket. A calendar invite. The legitimate user asks an innocent question; the AI goes off to gather information; the poisoned content hijacks it mid-task. The user never sees it. This is how an external attacker reaches an AI they can't talk to directly — by leaving a message where the AI will find it.

  
  

• Tool and agent abuse. Once an attacker's instructions are being followed, the damage is bounded only by what the AI is allowed to do. If it can only read, you have an information-disclosure problem. If it can send email, it can now phish your colleagues from a trusted internal source. If it can call internal APIs, it can act. This is where "excessive agency" — giving an AI more capability than the task requires — turns a nuisance into an incident.

  
  

• Data and context exfiltration. The AI has access to sensitive context — your documents, your prior conversations, its own instructions. A successful injection can turn that access into a leak, routing sensitive data into any channel that leaves your boundary. The AI becomes the exfiltration path precisely because it's trusted to move data around.

  
  

• Memory and persistence poisoning. If the AI remembers across sessions, an attacker who plants instructions in that memory has established persistence — a foothold that survives the original conversation and reactivates later, against a different user, in a different context.

Put these together, and you have the through-line of this entire piece: the AI becomes an insider threat. Not because it's malicious, but because it holds insider access and can be commanded by an outsider. It sits inside the boundary. It has credentials. It acts on instructions it can't authenticate. That is the definition of the problem.

These technique classes align with the OWASP Top 10 for LLM Applications — notably Prompt Injection, Sensitive Information Disclosure, and Excessive Agency — and with adversary behaviors catalogued in MITRE ATLAS, the AI-focused companion to MITRE ATT&CK. If you're building a security program, those two references are your shared vocabulary between offense and defense.

AI on the Edge: The Attack Surface Nobody Inventoried

Everything above gets harder when the AI leaves the data center and moves onto edge and IoT devices — cameras with on-device vision models, industrial sensors with local inference, smart building controllers, point-of-sale systems, medical and automotive devices, the whole sprawling world of "smart" hardware.

Vendors are racing to put AI on the device for good reasons: lower latency, offline operation, privacy, cost. But it changes the security picture in ways most buyers never evaluate:

• Physical access. Data-center models sit behind locked doors. An edge device may sit on a factory floor, a storefront, a pole, or a patient's bedside — reachable by people you don't control.

  
  

• Weaker isolation. Constrained hardware often skips the layered defenses, monitoring, and update discipline of cloud infrastructure. The model, its inputs, and its outputs may share space with little separation.

  
  

• Longer lifecycles. Industrial and IoT gear lives for years or decades. The AI baked into it today may still be running, unpatched, ten years from now — long after its weaknesses are public.

  
  

• Invisible inputs. An edge AI acts on what it senses — camera frames, audio, sensor readings. Those inputs are an attack surface too, and they're often completely unmonitored. If an attacker can influence what the device perceives, they can influence what it decides.

  
  

• Trusted position. Here's the killer: edge AI devices are usually inside the operational network, treated as trusted endpoints. A manipulated edge AI is an attacker with a seat inside the very environment that's hardest to monitor — the same insider problem, now on hardware you can't easily see or patch.

  
  

• The pattern is identical to the enterprise case: an AI with real access and no judgment, sitting inside a trust boundary, acting on inputs it can't authenticate. The edge just removes your visibility and adds physical reach.

The Defense: Treat Your AI Like an Insider, Because It Is

Here's the turn. Everything so far was the problem. This is what you do about it — and the good news is that you are not starting from zero. The disciplines that contain a risky insider are the same ones that contain a risky AI. You already own most of these tools. You just have to point them at a new kind of actor.

Inventory what your AI can touch. You cannot secure access you haven't mapped. For every AI system in your environment, write down: what data it can read, what tools it can call, what it can do without a human in the loop, and what the single most damaging action in its reach is. Most organizations have never done this. Doing it once is the highest-value hour you'll spend.

Apply least privilege — ruthlessly. The AI should have the minimum access the task requires and nothing more. If it drafts email replies, it may not need send permission. If it answers questions about documents, it may not need write access. Every capability you remove shrinks the blast radius of a successful injection. Excessive agency is the vulnerability; least privilege is the patch.

Draw a hard line between instructions and data. Architecturally, treat everything the AI ingests from email, web, documents, and sensors as untrusted input — the same way you treat user input in any application. It should never be able to silently escalate into a command. This is the single most important mindset shift: content the AI reads is data, not orders, no matter how convincingly it's phrased.

Put a human in the loop for consequential actions. Autonomy is fine for low-stakes tasks. For anything that moves money, changes access, sends external communications, deletes data, or touches production — require human approval. The confused deputy is only dangerous when it can act unsupervised. Supervision is cheap insurance.

Constrain the outputs, not just the inputs. Assume injection will sometimes succeed, and limit what a hijacked AI can do with that success. Allow-list the destinations it can send data to. Restrict the domains it can fetch. Validate its outputs before they reach a tool. If the AI can only ever talk to approved endpoints, exfiltration gets much harder even when the model is fooled.

Log everything the AI does — and baseline it. This is where your existing security muscle pays off. AI actions should be logged like any privileged account: what it accessed, what tools it called, what data left the boundary. Then baseline normal behavior. An AI that suddenly fetches an unusual URL, calls a tool it never uses, or moves data it's never moved is showing you an incident in progress. AI behavior is more repetitive than human behavior — which makes anomalies stand out if you're watching.

Extend all of it to the edge. For AI on IoT and edge hardware: inventory the devices, control physical access, monitor their inputs and outputs where you can, demand a patching and end-of-life story from vendors before you buy, and segment these devices so a manipulated one can't freely reach the rest of your network. Treat an edge AI device as an untrusted endpoint that happens to live inside your walls.

The Reframe That Makes It All Click

If you take one idea from this, make it this one.

Stop thinking of your AI as software, and start thinking of it as a new employee with sweeping access, a helpful streak, a flawless memory, and zero ability to tell when it's being conned.

You would never give a brand-new hire the keys to every system on day one, no supervision on consequential actions, and no record of what they do. You'd scope their access to their job. You'd require sign-off on the big stuff. You'd keep an audit trail. You'd train them to recognize social engineering — and you'd still watch for the day they fall for it anyway.

Your AI needs exactly that treatment, and it needs it more, because unlike a human employee, it will never develop an instinct for when a request feels wrong. Judgment is the one thing it doesn't have. Everything else — the access, the credentials, the trust, the reach — it already has.

The organizations that stay safe over the next few years won't be the ones that avoided AI. They'll be the ones that deployed it with their eyes open, scoped its power to its purpose, and watched it the way they'd watch any powerful insider.

That's the whole job. That's how you keep the ghost in the machine working for you rather than someone else.

Do This Yesterday

1. List every AI system connected to your business, and for each, write down what data and tools it can reach.

2. Identify the single most damaging action in each AI's toolset. That's your priority to gate.

3. Revoke one unnecessary permission this week. Start shrinking the blast radius.

4. Reclassify AI-ingested content — email, web, documents — as untrusted input in your security model.

5. Require human approval for any AI action that sends externally, moves money, changes access, or touches production.

6. Turn on logging for AI actions and start building a behavioral baseline.

7. Inventory your edge and IoT AI devices and confirm each vendor's patching and end-of-life commitments.

Further Reading

• OWASP Top 10 for Large Language Model Applications — the canonical list of LLM risk categories, including prompt injection, sensitive information disclosure, and excessive agency.

• MITRE ATLAS — adversary tactics and techniques against AI systems, structured like MITRE ATT&CK.

• NIST AI Risk Management Framework (AI RMF) — governance and risk guidance for organizations deploying AI.

Is your AI an insider you're not watching? Ghost Ops Security helps organizations find and fix the exploitable gaps in their AI, IT, and OT environments — before someone else does. If this raised questions about what your AI can reach, info@ghostops-security.com for a conversation about an AI security assessment.