AI Agent Data Classification Policy Template: Label Every Input Before an Agent Touches It

Every agent run starts before the first tool call: with the data it will touch. If that data has no class, nothing downstream can make a sound decision about it — not the grant, not the egress rule, not the log redaction, not the retention period. Teams discover this backwards, after an agent has pasted a confidential record into an external tool, stored it in the wrong place, or written it in full into a debug log. This AI agent data classification policy template fixes the order: declare the class first, in the plan bound, and let every other control read it from there.

Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025, so the volume of data flowing through agents is rising fast. The failure mode is already documented: a runaway agent loop burned over $700 in 72 hours with no budget control. Classification does not replace spend ceilings or approval gates. It is the label those controls need to know how strict to be.

Why agents break ordinary data classification¶

Most companies already have a data classification scheme — usually a document written for people. Agents break it in three ways.

First, agents do not notice sensitivity: a human pauses before forwarding a customer record; an agent treats every input as text to process and pass to the next tool. If the class is not machine-readable, the agent has nothing to pause on.

Second, agents move data at machine speed: in one run an input can be copied into a prompt, a tool call, a stored artifact, a log row, and an outbound message — a classification in a wiki page never travels with it.

Third, agents produce new data from old data: a summary of a confidential document is still confidential in effect. Agent work must classify outputs too, and output inherits the highest class of any input that shaped it.

That is why, in the Governed Agent Mesh Playbook, classification is not a separate compliance exercise. It is a required field — data_class — in the plan bound, the bounded unit of work that must be stated before any agent runs.

The four classes, defined for agent work¶

Use four levels. More than four and nobody — human or agent — applies them consistently; fewer and the controls cannot tell a public web page from a credential.

Public: Data intended for anyone to see: published pages, public documentation, marketing copy. An agent may read, quote, store, and log it in full — the only class where full-fidelity logging is safe, which is why it must be declared, never assumed.
Internal: Data for the team, not the world: internal notes, roadmaps, non-sensitive operational records. An agent may use it inside the plan's storage and egress bounds, but it must not go to external parties, and logs should summarise it rather than quoting free text.
Confidential: Data that would cause real harm if disclosed: customer records, contracts, financial detail, personal data about identifiable people. An agent touches it only under a least-privilege grant that names it, egress is limited to allowed domains, outputs stay in guarded storage, and logs record hashes and references — never content.
Restricted: Data where disclosure is an incident in itself: credentials and secrets, payment instruments, and material under legal privilege or hold. Reading or transmitting a credential is hard-gated — always a recorded human approval — and restricted content is never written to a log.

One rule governs all four: record the highest class the workload touches. A plan that reads one confidential record among a hundred public pages is a confidential plan. Averaging down is how a single sensitive record ends up handled under public rules.

The AI agent data classification policy template¶

Copy this template into your repo or wiki, fill every bracket, name an owner, and set an effective date. A policy counts as adopted when the brackets are filled, the owner is named, and the team is notified.

AI AGENT DATA CLASSIFICATION POLICY — [TEAM NAME]
Version [VERSION] · Effective [DATE] · Owner: [POLICY OWNER]

1. Every plan MUST declare a data_class in its plan bound before any
   agent runs: public, internal, confidential, or restricted.
2. The declared class is the HIGHEST class of any input, tool output,
   or stored artifact the plan touches. When in doubt, classify up.
3. A plan with no data_class is not a plan. It is rejected at creation,
   and the rejection is recorded as an audit row.
4. The declared class drives the plan's other bounds: which grants may
   be issued, which egress domains are allowed, where output may be
   stored, how logs are redacted, and how long records are retained.
5. Output inherits the highest class of its inputs. Summaries,
   extracts, and embeddings do not downgrade the class on their own.
6. Reclassification — raising or lowering a class — is a Hard-gated
   action: it requires a recorded human approval by [APPROVER ROLE],
   with the reason recorded in the audit log.
7. Accessing or transmitting credentials or secrets (restricted) is
   ALWAYS Hard-gated, regardless of the plan's other bounds.
8. If the class of any input is missing or unclear during a run, the
   action FAILS CLOSED: it is blocked, recorded as blocked with the
   exact reason, and never retried automatically. The block names the
   evidence that would unblock it.

Clauses 3 and 8 are the ones teams are tempted to soften into warnings. Do not. A warning-only path on a side-effecting action is exactly how an unclassified input gets processed “just this once” — and once is enough.

How the class drives the other controls¶

Classification earns its keep only if other controls actually read it. Wire the class to each bound in the plan, like this:

Grants: A grant is a least-privilege record — capability, scope, issuing owner, dates, expiry, identity. The class caps what it may cover: no grant under an internal plan reaches confidential data, and restricted access is approved per action, never standing.
Egress: The plan bound records allowed_domains and a transfer cap. Public and internal work can use the normal tool set; confidential work shrinks to named destinations with a stated purpose; restricted work starts with an empty allowlist until a hard-gated approval adds one destination for one action.
Storage: Storage scope and size cap narrow as the class rises. Confidential and restricted outputs belong in the guarded system of record, not scratch space or the agent's memory store.
Logging and redaction: Public data may be logged in full; internal data is summarised; confidential data is a hash plus a reference; restricted data is not logged — the row notes a credential was used, by grant reference. Rows are hash-linked, append-only, and never contain secrets.
Approvals: Routine work inside an approved confidential plan can be Bounded auto — auto-running, fully audited, auto-blocking at any bound. Anything restricted, and any reclassification, is Hard-gated. Drafting stays Draft-only in every class: a draft never sends itself.
Retention: Set retention per class in your audit-row retention policy, and make deletion happen. Higher class means a deliberate, recorded decision — not a default nobody chose.

Classification checklist, step by step¶

Work through this checklist for each agent workflow, in order:

Inventory what the workflow touches. List inputs, tools, data stores, and outputs by the names the agent actually invokes — tool names and API calls, not architecture-diagram labels.
Assign a class to each item. Use the four definitions above. If you cannot name the consequence of an item being disclosed, classify it up until you can.
Set the plan's data_class to the highest item. Record it in the plan bound alongside identity, workload, resources, time window, location, egress, storage, cost ceiling, expiry, and grant references — all 13 bounds, or the plan does not validate.
Wire the checks. Confirm the grant check, egress check, storage check, and log writer all read the declared class, rather than carrying their own separate assumptions.
Test with a mislabeled input. Feed the workflow a confidential record labelled internal, and a run with no class at all. The first should be caught or handled at the higher class; the second must fail closed with a recorded block naming what would unblock it.
Re-run the inventory when anything changes. A new tool, a new data store, or a new output destination changes what the workflow touches — and the class follows the data, not the original diagram.

Common mistakes¶

Four mistakes account for most classification failures in agent stacks:

Defaulting to internal. A default class is an unmade decision applied at scale. If a workflow has not been classified, the correct state is blocked, not internal.
Classifying the tool instead of the data. The same database tool can return a public product description in one call and a confidential customer record in the next. Classify the data in the plan, per workload — not the tool in the inventory.
Letting output inherit a lower class. A summary, translation, or embedding of confidential input is still derived from confidential input. Downgrading requires a reclassification decision, with human approval, not an assumption that transformation equals sanitisation.
Leaving free text outside the scheme. Prompts, error messages, and model summaries quote the data they process. If free-text fields are exempt from the class rules, the scheme covers the tidy fields and leaks through the prose. Treat free text as carrying the plan's class, in full.

The 10-minute starter version¶

In ten minutes: pick your most sensitive agent workflow, name the highest class it touches, and write it into its plan bound. Apply two consequences — shrink its egress allowlist to what it demonstrably needs, and switch its log writer to hash-plus-reference above internal. Finally, make a missing class a block, not a default.

That is the core of the AI agent data classification policy template: one declared label, stated before the run, that grants, egress, storage, logging, and approvals all read from the same place. From there, extend the checklist workflow by workflow — every plan that declares its highest class honestly is a plan whose other bounds can actually be enforced.