Glossary /

The words, used precisely.

Definitions for the terms that come up when securing AI use. Where a term has a loose industry meaning and a precise one, this gives the precise one and says what the difference buys you.

AIDR

AI Detection and Response: endpoint security for how a workforce uses AI, covering what employees send to AI tools, what those tools send back, and what agents do on the machine.

AIDR sits where EDR sits, on the device, but watches a different thing. EDR asks whether a process is malicious. AIDR asks what left the machine inside a request that looks, to every other control in the stack, like ordinary HTTPS to a reputable domain.

The category exists because the risk moved into content. Nothing about a developer pasting a production database URL into a chat window is anomalous at the process, file or network layer. It is an ordinary browser opening an ordinary TLS connection. You can only see the problem in the plaintext, and the endpoint is where the plaintext is.

It covers four things: visibility into every AI tool in use, detection of what gets sent and returned, response when something slips through, and governance that applies one policy across all of it.

Shadow AI

AI tools in use across an organisation that nobody approved, procured or inventoried, usually on personal accounts and on work devices.

Shadow IT needed a purchase order and an admin. Shadow AI needs a browser tab and a personal email address, so it spreads faster and wider than anything before it. Asking people what they use produces an undercount every time.

The practical definition is narrower than "unapproved software". It means the AI tools your organisation has no contract with, no data processing agreement covering, and no record of what was sent to them. A sanctioned tool used on a personal account counts too, because the agreement attaches to the corporate tenant rather than to the product.

Finding it does not require decrypting anything. The process that opened the connection and the host it reached are enough to identify a tool, so discovery covers every AI tool on a fleet while inspection covers only the ones that have been onboarded.

Guardrail

A policy evaluated against AI traffic that can block a request, mask the sensitive part of it, or raise a finding.

A guardrail combines a condition, an action and a mode. The condition is a detector: a secret pack, a regular expression, or a keyword dictionary. The action is block, mask or alert, and the mode decides whether the rule enforces or only records.

The word gets used loosely for model-level safety training. Here it means something narrower and more checkable: a rule that runs on your infrastructure, against your traffic, that you can turn on and off and whose decisions are logged.

What a guardrail can do depends on where it runs. On the request, on the device, before the bytes leave, it can rewrite or refuse. Anywhere after that it can only tell you what already happened.

Inline enforcement

Acting on a request while it is still on the device and still unsent. This is the only point at which a control can block or rewrite rather than report.

A request body is fully buffered before it goes upstream, so scanning it, replacing bytes in it, or refusing it outright is cheap and safe. Once it is streaming to the vendor, none of those are available: no product can un-send a prompt.

This is why the response side is monitor-only by physics rather than by choice. Buffering a streamed response to make it blockable would stall tool-approval prompts and break the apps it is supposed to protect.

It is also the clearest dividing line between architectures. A cloud gateway sees only what is routed through it, and a browser extension sees only what happens in the browser, missing desktop apps and command-line agents. Neither one ever holds the request it would need to stop.

Sighted, recorded, inspected

The three fidelities at which an endpoint can know about a network flow: a rollup, a per-flow record, or the decrypted content.

Sighted is the cheapest. It records a process, a destination and a count over a time window, with no arguments and no content, which is still enough to tell you that a tool is in use and on which machines.

Recorded adds a row per connection, carrying process identity, destination, SNI, timing and byte counts, but still no content. Inspected adds the plaintext, and it is the only fidelity at which a content rule can match anything.

The distinction matters commercially as well as technically. Discovery works on every AI tool a fleet touches, while content rules work only where interception has been onboarded. Interception is deliberately an allowlist, because intercepting a tool nobody has tested against breaks someone’s toolchain instead of protecting it.

TLS interception

Terminating a TLS connection on the device with a locally trusted certificate so the plaintext can be inspected before it is re-encrypted upstream.

Without it there is no content, because TLS is designed so that the destination hostname is the most anyone in the middle learns. Any control claiming to see what was typed into an AI tool is either intercepting TLS, running inside the app, or guessing.

On the endpoint it stays bounded: the connection terminates on the same machine that opened it, and nothing is shipped elsewhere to be decrypted. Running it as an allowlist bounds it further, since only traffic to tools that have been tested is touched and everything else passes through.

The failure mode worth designing against is breakage rather than privacy. Certificate pinning, runtimes with their own trust stores, and apps that fail closed on an unexpected chain all turn a broad interception policy into a support queue.

Prompt injection

Instructions hidden in content an AI system reads, such as a web page, a document or a tool result, which the model then follows as though the user had issued them.

The model has no reliable way to separate the instructions it was given from the text it was asked to process. Anything reaching the context window is a candidate instruction, which makes every fetched page and every tool result an untrusted input.

It matters most for agents, because an agent has something to do with the instruction. A chat assistant told to ignore its rules produces a bad answer; an agent told to read a credentials file and include it in the next request produces an incident.

Three variants come up often enough to name separately: latent instructions that sit dormant until a later turn, invisible and bidirectional control characters that hide the payload from a human reviewer, and content addressed to the AI rather than to the reader.

Agentic AI

An AI system that takes actions rather than only producing text: reading files, running commands and calling APIs, in a loop it drives itself.

The security-relevant change is that the model, not the person, decides what gets read. A six-word prompt can pull an entire credentials file into a request without anyone typing a secret, which makes the tool call a surface in its own right rather than an implementation detail of the answer.

It also inverts the review model. Nobody reads every tool call an agent makes, so an agent that quietly widens its own permissions, by editing its rules file or disabling an approval step, is a meaningful event even when nothing has leaked yet.

Coding assistants got here first, so the sharpest examples are editors: repository context by design, plus shell access, plus an agent loop.

MCP (Model Context Protocol)

An open protocol for connecting AI applications to external tools and data sources through a common interface.

MCP is what turns an assistant into an agent with reach. A server exposes tools, the client advertises them to the model, and the model calls them. It is the plumbing behind most of what "connect your AI to your systems" means in practice.

From a security standpoint the interesting property is that the tool list travels with the request. That makes tool identity checkable before the model can act on it. A denylist can refuse a named tool on the declared list, which is a stronger control than noticing afterwards that it ran.

The inventory problem is real and ordinary: MCP servers get added by individual developers, in local config files, without anyone filing a ticket. Most organisations cannot currently name the ones running on their fleet.

Tool call and tool result

The request an AI model emits to invoke a tool, and the content that comes back into its context. Both are surfaces distinct from the prompt and the answer.

A tool call is something the model produces, so it arrives on the response leg of the conversation. By the time it exists the upstream request has already happened, so controls on it record and redact rather than block.

A tool result runs the other direction: content from a file, an API or a web page, entering the context. It is the most common carrier of prompt injection, because it is content nobody wrote with the model in mind.

Treating these as separate surfaces from the prompt is what lets a policy say something useful. "No secrets in input" means something different when the input was generated by an agent than when it was typed by a person.

AI DLP

Data loss prevention applied to what employees send into AI tools, rather than to email, file shares and USB devices.

Classic DLP watches the channels that existed when it was designed. AI use is not one of them: it is an interactive session over TLS to a domain your allowlist already trusts, carrying content that was pasted rather than attached.

The detection primitives carry over: credential patterns, personal data, classification markers. The enforcement point does not, so the question to ask about any AI DLP claim is where the inspection happens and whether it can act before the send.

Masking rather than blocking is what makes it usable. Refusing every prompt that contains a token trains people to route around the control, while rewriting the token and letting the answer come back leaves the work intact.