Data governance for agents

At 3:07 p.m., Maya asks her company’s support agent: “Please check invoice INV-1842. I think I was charged twice.”

The agent retrieves the invoice, a CRM profile, and two old support notes. It sends some of that material to a model. The model calls a billing tool to issue a refund. The runtime stores a memory saying Maya prefers email. An observability system records the prompt, retrieved documents, tool arguments, and response.

The refund works.

Now ask a less comfortable question: where is Maya’s data?

It is in the billing system. It may also be in the model’s context window, a vector index, an agent-memory database, a tool request, a provider’s request log, and your trace store. If Maya later asks for deletion, “delete her customer record” is not enough.

An agent is a data-flow problem before it is a model problem. Data governance is the set of rules and controls that decide what data an agent may access, where it may go, how long each copy may exist, and who may inspect it.

The model is only one stop on the route.

Follow the copies

Treat every handoff as a possible new copy of the data.

The context window contains the text and tool results supplied to the model. It may be temporary in your application, but the provider receives it and the runtime may retry or cache it.

Memory includes saved preferences, summaries, episodes, and embeddings. A vector store is still a data store, even when it retrieves records by semantic similarity.

A tool call sends arguments to another system, which can see and retain them. A trace records prompts, retrieved sources, tool calls, outputs, and errors. It is useful for debugging and often becomes a second sensitive data store.

For every field, inventory whether it enters context, memory, a vector store, a checkpoint, a cache, a tool call, a trace, an error, or an export. Record its identity, tenant, purpose, region, and retention rule. If you cannot answer these questions, you do not yet know what your agent does with data.

Classification is a handling rule

Data classification says how data must be handled; it is not authorization.

A practical taxonomy is:

• Public: safe to disclose without access control.
• Internal: business information kept within the organization.
• Confidential: limited to an approved team, customer, or purpose.
• Restricted: payment credentials, health records, government identifiers, or authentication secrets requiring tight access, minimization, and deletion controls.

Attach each piece of data to its tenant and subject, source object, allowed purpose, destinations, retention rule, and persistence permissions. Classify derived data too: a summary or embedding can still reveal or represent personal information.

Authorization answers “who may access this?” Classification answers “what handling is required if they do?”

One request, worked through

Return to Maya at Northstar Billing. Suppose the CRM response contains:

Field	Class	Needed for the refund?
tenant_id = northstar	Internal	Yes
customer_name = Maya Chen	Confidential	Usually
invoice_id = INV-1842	Confidential	Yes
invoice_total = $480.00	Confidential	Yes
email = maya@example.com	Confidential	No
payment_last4 = 1842	Restricted	No
internal_note about a previous refund	Confidential	No

A careless agent puts all seven fields into a 1,420-token prompt. The model and trace exporter now see payment information and an irrelevant note; a summarizer might persist them. The refund needs four fields, not seven.

A governed path gives each destination an allowlist:

• Model context: tenant, name, invoice ID, and total.
• Billing tool: invoice ID, amount, and refund reason.
• Memory: no payment data or internal note; “customer prefers email” only if needed, for 30 days.
• Trace: source IDs, policy decision, model ID, and tool outcome—not the raw prompt or payment fields.
• Audit trail: that the agent read the invoice and attempted a refund.

The policy may differ by organization. The mechanism does not: select fields separately for every destination, using the authenticated principal, tenant policy, purpose, and destination.

import json

record = {
    "tenant_id": "northstar",
    "customer_name": "Maya Chen",
    "invoice_id": "INV-1842",
    "invoice_total": 480.00,
    "email": "maya@example.com",
    "payment_last4": "1842",
    "internal_note": "Asked about a second refund last month",
}

allowed_context_fields = (
    "tenant_id",
    "customer_name",
    "invoice_id",
    "invoice_total",
)

def context_for_model(source):
    return {
        field: source[field]
        for field in allowed_context_fields
        if field in source
    }

def refund_arguments(invoice_id, amount, reason):
    return {
        "invoice_id": invoice_id,
        "amount": amount,
        "reason": reason,
    }

print("MODEL CONTEXT")
print(json.dumps(context_for_model(record), indent=2))

print("TOOL ARGUMENTS")
print(json.dumps(
    refund_arguments("INV-1842", 480.00, "duplicate charge"),
    indent=2,
))

It prints:

MODEL CONTEXT
{
  "tenant_id": "northstar",
  "customer_name": "Maya Chen",
  "invoice_id": "INV-1842",
  "invoice_total": 480.0
}
TOOL ARGUMENTS
{
  "invoice_id": "INV-1842",
  "amount": 480.0,
  "reason": "duplicate charge"
}

This is not a complete authorization system. The model must not be able to request a broader record and thereby change the policy.

Redact at the boundary

A boundary is where data enters another component or trust domain: the model context, a tool request, memory, a trace exporter, or another region or provider.

Redacting only at the sink is late. If an email already went to the model provider and a tool, cleaning your local trace cannot undo those transfers.

Apply controls before each handoff:

• use field-level allowlists;
• tokenize identifiers when the model needs a reference but not the original value;
• construct typed, destination-specific tool arguments;
• use regex redaction for obvious patterns as a safety net, not as the primary policy.

Authorization and allowlists decide what may cross a boundary. Redaction catches mistakes afterward.

Isolation: the multi-tenant disaster

Shared vector memory can turn a retrieval feature into a tenant breach. If Northstar and Bluebird share a collection and retrieval returns the top five similar memories without an authenticated tenant filter, Maya might receive Bluebird’s “enterprise refund limit.”

Telling the model not to mix customers cannot fix this. Unauthorized text is already in its context.

Enforce isolation before retrieval:

• derive tenant and user or service identity from verified authentication, never model text;
• apply tenant and ACL filters in the retrieval service;
• key personal memory by tenant_id:user_id;
• use separate collections for high-risk tenants where appropriate;
• test adversarial cross-tenant queries;
• check authorization again before context assembly.

The same rules apply to checkpoints, summaries, and caches. Encryption protects stored bytes; it does not stop an application from decrypting the wrong record and sending it to the model.

Deletion is a fan-out operation

A deletion request must follow every copy, not only the source database. For Maya, inspect the CRM and billing records, document chunks and embeddings, memory, checkpoints, traces, tool logs, caches, exports, queues, and backups.

Deletion may be limited by tax, accounting, fraud, dispute, or legal-hold obligations. Where erasure is allowed, delete or anonymize the copy. Where retention is required, keep only what is necessary for a documented, bounded period, with restricted access and purpose.

Give every derived record a stable source ID and tenant ID. The deletion workflow should remove or tombstone permitted copies, invalidate caches, prevent re-import from old exports, and verify completion in each store. A tombstone is a durable “do not re-import this identity” record; it prevents asynchronous ingestion from resurrecting deleted memory.

Embeddings are derived records, not exceptions. Document backup expiry and access restrictions rather than assuming deletion is immediate everywhere.

Retention should follow purpose. A refund trace might last 30 days, while a financial record follows a different schedule. Keeping every prompt forever turns debugging into permanent collection.

Residency and purpose

Data residency concerns where data is stored; processing location concerns where it is computed. A route may store Maya’s record in Germany, process her prompt in the United States, replicate it to Ireland, and permit support access elsewhere. Check storage, processing, replication, backups, subprocessors, and support access—not only an endpoint’s regional label.

Before context assembly, attach allowed-region and transfer rules to the tenant. Route to a permitted provider and endpoint, verify the route, minimize or tokenize fields, and refuse the run when no permitted route exists. Record the actual destination and policy decision. Do not route first and redact later: the data has already crossed the boundary.

A request to inspect an invoice authorizes that purpose, not marketing, profile changes, disclosure, or indefinite memory. Record the purpose, applicable legal basis, and—when consent is used—its scope and withdrawal status. For Maya, policy might allow invoice lookup and a refund up to $500 after confirmation, while denying payment-method changes. A confirmation should identify the action and amount.

Tool permissions should be purpose-specific too. Give a support agent read_invoice and create_refund, not a general billing token. For MCP-connected tools, inspect both server and tool contract; MCP security explains why a declared description is not a complete trust boundary.

Audit reads as well as actions

Record:

• initiator, tenant, purpose, and policy version;
• source objects and fields actually returned to context;
• model, provider region, and tools proposed, approved, called, or denied;
• minimized tool arguments, outcome, approver, and related trace or memory IDs.

Store references and classifications instead of raw sensitive content where possible. Protect audit records with access controls, retention, export monitoring, and deletion analysis. Agent observability covers tracing mechanics; governance decides which fields are safe to collect.

Choose the control point

The key question is whether a control runs before data crosses a boundary or only after a copy exists.

Strategy	Protects	Misses	Best use
Model instruction	Some accidental answer disclosure	Retrieval, provider visibility, tools, logs	Behavior hint, never access control
Sink-only redaction	Local logs and traces	Earlier transfers	Last-line observability protection
Boundary allowlist	Context, memory, tools, exports before transfer	Bad classification or bypasses	Primary enforcement
ACLs and retention jobs	Stored copies and readers	Data exposed before storage	Required storage protection
Combined controls	Transfer, storage, debugging, accountability	Misclassification and provider behavior outside contract	Production default

No layer is sufficient alone. A storage ACL cannot retract a prompt already sent to a provider, and a boundary policy cannot compensate for an unreviewed integration.

Failure modes

First symptom	Likely cause	Fix
Traces contain emails, payment suffixes, or tool responses	Redaction happens only in the exporter	Filter before context, memory, tools, and traces
An answer contains another tenant’s project name	Retrieval lacks a server-side tenant or ACL filter	Derive identity from authentication and test cross-tenant queries
Deleted text reappears	An embedding, checkpoint, cache, or export survived	Delete by source ID and block re-ingestion with tombstones
Requests are handled in a forbidden region	Routing ignored residency	Route before sending data and audit the actual destination
Engineers can replay prompts containing secrets	Debug traces store raw prompts	Store references and approved excerpts; restrict replay

The honest limitation

Governance is not a clever prompt, PII regex, or vector-store setting. Classification can be wrong; models can infer sensitive facts; providers can change retention or routing; and deletion workflows can miss obscure caches. Strict minimization can also reduce usefulness.

Make each transfer deliberate, narrow, attributable, and reversible where possible. Put policy in code and infrastructure, not only in instructions to a probabilistic model, and retest when tools, providers, memory schemas, or exporters change.

What to remember

• One agent turn creates copies in context, tools, memory, caches, and traces.
• Classification governs handling; authorization governs access; purpose governs use.
• Enforce identity and allowlists before retrieval and every outbound handoff.
• Traces inherit source data’s access and deletion obligations.
• Deletion and residency must be tested across every store, route, provider, and ingestion path.

Quick check

0/3

Q1

Traces cannot contain textThe email may already have been sent to the model provider, a tool, or memoryRedaction makes vector search slowerThe model always encrypts email addresses

Check answer

Q2

The tenant name generated by the modelThe most similar document's tenantTenant and user or group identity derived from verified authenticationNo identity, because embeddings are anonymous

Check answer

Q3

Increase the trace retention periodTell the model not to mention the recordCheck residency policy before context assembly, route to an allowed endpoint, and minimize fields before the requestStore a second unredacted copy for audits

Check answer