Glossary

The working vocabulary of governed AI data, defined the way I actually use the words. Definitions are mine; disagree by email. The longer arguments live in the essays.

Governed AI data

Data whose access rules are enforced when an AI reads it, not only when a person does. The question underneath is thirty years old (who is allowed to read this?); what is new is that the reader might be a model or an agent, and the enforcement has to hold at the data, not in the application asking.

Agent containment

The discipline of bounding what an AI agent can see and do: an agent sees only what the person behind it is cleared to see. Not a separate, softer rulebook for machines. Supervision does not scale (nobody supervises fifty of anything); containment has to be structural.

On-behalf-of access

The access model where an agent acts with the identity and clearance of the person it works for, rather than with broad service credentials of its own. The alternative, an agent that inherits everything its user can reach plus service-account superpowers, is how one injection bug becomes an enterprise-wide spill.

Data custody

Who actually holds the data and the keys, as distinct from who claims responsibility for it in a contract. If a vendor holds the keys, the vendor has custody, whatever the marketing says. Custody questions get sharper with AI because inference pipelines quietly create new copies in new places.

Sovereign data

A word doing too much work, so cash it out: whose keys encrypt the data, who has custody of it, and which jurisdiction can compel access to it. If you can answer those three concretely, you do not need the word. If you cannot, the word will not save you.

Blast radius

What an attacker (or a misbehaving agent) can reach once something goes wrong. The useful property of blast radius is that you set it in advance, on the day you grant access, not on the day the bug lands. Injection bugs are inevitable; the blast radius is a choice.

Least privilege, for agents

The old rule, applied to the new reader: every principal gets the minimum access its task needs. Thirty-year-old language that every AI governance paper now reaches for, because it works. The hard part with agents is that their tasks change by the minute, so the privilege has to be evaluated at the data, per request.

Data readiness

The state of knowing what data you hold, where it lives, what its rules are, and being able to enforce those rules, before you point AI at it. ASD calls it a core prerequisite for AI adoption, which is a polite way of saying: govern first, adopt second.

Cloud repatriation

Moving steady-state workloads off rented cloud onto infrastructure you control, once the economics and the workload are understood. Not a rejection of cloud; a second decision the smart companies make after the first one pays out. The AI version (owned models, on-premises inference) is happening now.

Prompt injection

Getting an AI system to follow instructions hidden in content it was merely supposed to read. Unsolved in the general case, and probably staying that way, which is why the defence is not a smarter filter but a smaller blast radius: assume the injection lands and decide in advance what it can reach.

Audit trail

The record that lets you prove, afterwards, what was accessed, by whom or by what, under which rule. With AI-assisted actions the trail has to capture the agent, the person behind it, and the data touched. A governance system you cannot audit is a governance claim, not a governance system.

Policy engine

The component that evaluates access rules at request time: this principal, this data, this purpose, yes or no. The design question that matters is where it sits. A policy engine inside the application asking can be bypassed by the next application; one at the data cannot.