Disclosure: BlueBear builds an AI agent platform, so we have a commercial interest in this vocabulary. These definitions are written to be vendor-neutral and quotable; where a term has a BlueBear-specific meaning we say so explicitly rather than presenting our usage as the industry's.
Why a glossary earns its place in this particular subject
Most stalled conversations about AI auditing are vocabulary problems wearing a technical disguise. A business owner says "we log everything" and means "we would notice a problem". An engineer hears "we have an audit trail" and means "there are files". Both are right about their own sentence and the discussion goes nowhere for a quarter.
These are defined in the order they usually come up rather than alphabetically, and each carries a note on the specific mistake it tends to cause.
Records
| Term | Definition | The mistake it causes |
|---|---|---|
| Application log | A record written for an engineer debugging code, usually free text, retained for days or weeks. | Being treated as an audit trail. It records that something ran, not that it was allowed. |
| Audit trail | A durable record of what was permitted, what was done, and under whose authority — written for a reviewer who was not present. | Being scoped as "more logging" and budgeted accordingly. |
| Evidence chain | A linked record where each entry references the next, so one identifier pulls back a whole run. | Being confused with a distributed ledger. It is a data modelling property, not a consensus mechanism. |
| Run identifier | A value minted when a request is admitted and carried on every record that run produces. | Being minted inside the agent, which means a run that fails early produces nothing. |
| Typed record | A record with a declared schema and a version, validated when written. | Being deferred as an optimisation. Untyped records become unreadable once the authors leave. |
| Append-only | A store with no update or delete path from the application. | Being conflated with immutability, which is a much heavier and usually unnecessary commitment. |
| Sampling | Retaining a fraction of records to control cost. | Correct for telemetry, fatal for evidence — and usually a default nobody mentions. |
| Retention | How long a record is kept before deletion. | Being inherited from the log platform, which defaults to weeks while obligations run for years. |
Boundaries
| Term | Definition | The mistake it causes |
|---|---|---|
| Control plane | The layer that decides what is permitted and records what happened, kept separate from the layer that does the work. | Being used as a synonym for "platform", which loses the separation that is the whole idea. |
| Runtime | The layer that actually performs the work: runs the agent loop, calls the model, calls the tool. | Being asked to also enforce policy, which puts the actor and the witness in the same component. |
| Execution boundary | The point where a call leaves your system — the tool invocation, the model call, the write. | Being assumed to exist. Many systems have several, and an agent that can reach any one directly makes the others decorative. |
| Tenant | The isolation unit that owns data, agents and credentials — usually one customer or one business entity. | Being modelled as a filter rather than as a property of the request. |
| Workspace | A boundary inside a tenant: a team, a project, or an environment with its own agents and connections. | Being treated as cosmetic grouping rather than as an access boundary. |
| Connection | A described link to an external system, carrying the credentials and the set of operations that are permitted through it. | Being equated with an API key, which is the thing a connection exists to stop the agent holding. |
| Scope | The specific set of operations a given actor may invoke through a connection. | Being set once at integration time and never narrowed as the agent's job changes. |
| Least privilege | Holding only the permissions the job requires, for only as long as it requires them. | Being read as a security aspiration rather than as a testable property: can you revoke one capability without a redeploy? |
| Blast radius | How far the damage from a single mistake or compromise can reach. | Being estimated from what the agent normally does rather than from what its credentials permit. |
| MCP | Model Context Protocol — an open standard for describing a connection to a tool or data source and the named operations inside it. | Being expanded into other things entirely. It is not a cloud management acronym. |
Decisions
| Term | Definition | The mistake it causes |
|---|---|---|
| Policy | A rule evaluated before a step, producing a decision and a reason. | Being written into a prompt, where nothing evaluates it and nothing records it. |
| Plan | The steps an agent intends, and the constraints applied to them, recorded before execution. | Being collapsed into the execution record, so intent and action become indistinguishable. |
| Plan-honoured | Whether what ran is what was planned. In BlueBear's routing this is recorded explicitly, because a plan can time out, a model can be unavailable, and a fallback can fire. | Being assumed. A savings or quality model that assumes the plan ran is overstating its case. |
| Shadow mode | Producing and recording a decision without acting on it, so a change can be evidenced before it is made. In BlueBear's routing the modes are off, shadow and active. | Being skipped, which turns a policy change into a production experiment. |
| Approval | A human decision recorded with the approver, the time, and what they were shown. | Omitting what was shown, which reduces the record to an assertion. |
| Completion | A technical event: the run finished and returned something. | Being counted as a success. |
| Outcome | A business judgement: accepted, corrected, rejected or abandoned. | Being assumed to exist. It is the only link that is not an infrastructure event, so it needs a producer. |
Two definitions worth expanding
Evidence chain gets its own paragraph because the word "chain" misleads people toward blockchains. The existing guide why AI agent reliability starts with an evidence chain is the argument for the model rather than the vocabulary. It means only that each record references the previous one, so a run can be reassembled from either end. What regulated use normally requires is append-only storage, tamper-evidence and controlled schema change — properties ordinary databases and object stores provide. Distributed ledgers solve a trust problem between parties, which most internal audit obligations do not have. The evidence chain explained works through the links.
Outcome gets one because it is the term most likely to be nodded through in a vendor conversation. Every product will say it supports outcome measurement. Most mean they have a field. Ours is a case in point and we would rather say so: the ingestion path and the storage for action outcomes in our gateway are built, tested and mounted, and no producer currently calls them, so the store is empty. The useful question, of us or anyone, is "show me a stored row".
If you operate in a regulated industry
Three terms will appear in a review and are worth agreeing internally before they do: completeness (is the record sampled), tamper-evidence (who can reach the store), and retention (stated as a number, by obligation). The financial services treatment covers how they are usually tested.
If you are a platform or engineering lead
The two terms most worth insisting on in design review are execution boundary and plan-honoured. The first stops policy drifting into prompts; the second stops the system asserting things it did not verify. The control plane architecture walkthrough uses both.
Do this next
Send this page to whoever you have been talking past — usually the engineer if you are the business owner, or the compliance lead if you are the engineer — and agree on the six terms in the Decisions table. That agreement is worth more than a policy document. Then read what an AI agent audit trail is for the definition in full, or audit trail vs. application logs if the disagreement is specifically about whether you already have one.
Questions people actually search for
- ai agent audit trail glossary
The terms that most often cause a business owner and an engineer to talk past each other are audit trail versus log, evidence chain, control plane versus runtime, execution boundary, least privilege, scope, run identifier, plan-honoured, and outcome versus completion. Each is defined below in one or two sentences of plain English, with a note on the mistake it usually causes. The definitions are written to be quotable and are deliberately vendor-neutral.
- what does execution boundary mean
The point where a call actually leaves your system - the tool invocation, the write to a system of record, the model call. It matters because it is the only place a permission decision can be enforced regardless of what the agent was persuaded to attempt, and the only place a record can be written by something other than the actor itself. Constraints expressed anywhere earlier, including in the prompt, are requests rather than controls.
- what is the difference between an outcome and a completion
A completion is a technical event: the run finished and returned something. An outcome is a business judgement: the result was accepted, corrected, rejected or abandoned. A run can complete successfully and produce a rejected outcome, which is why cost and quality figures based on completions are systematically optimistic. The two are recorded in different places and only the first happens automatically.
- what does least privilege mean for ai agents
An agent holds only the specific permissions its job requires, for only as long as it requires them, rather than inheriting whatever the application credential can reach. In practice that means named operations on named connections rather than a database password or a broad API key, and it means the credential is supplied at the execution boundary rather than held by the agent. The test is whether revoking one capability is a configuration change or a redeploy.
- what does plan honoured mean in ai routing
Whether the model or route that was planned is the one that actually ran. They diverge for ordinary reasons - the preferred model is unavailable, the planner exceeded its time budget, a fallback fired - so a system that records only the plan will assert something it did not verify. Recording plan and execution as separate events, and whether they agreed, is what makes an incident reconstructable and a savings model honest.