The AI Agent Data Map: What It Can Read, Write, Retain, and Send

An AI agent can pass a demo and still have no business touching your production data.

The demo usually proves that the model can produce a useful answer. It rarely proves which customer records the agent can retrieve, which fields it can change, where prompts and outputs are stored, or what happens when it calls another service.

That gap matters. A normal software tool may wait for a person to choose an action. An agent can retrieve information, make a decision, and trigger a downstream write in one run. If the team cannot trace that path, it has not approved a controlled workflow. It has approved a black box with credentials.

Build a data map for the specific workflow. Keep it practical. One page should show what the agent can read, write, retain, and send, plus the identity, approval, logging, and deletion rules around those actions.

Start with one transaction, not the whole platform

"The agent connects to Salesforce and Microsoft 365" is an inventory statement. It is not a data map.

Pick one transaction and follow it from trigger to completed outcome. For example: a customer emails a service request, the agent identifies the account, checks entitlement, creates a ticket, drafts a response, and routes an exception to a person.

That workflow may touch an inbox, identity provider, CRM, contract repository, ticketing system, model provider, orchestration layer, logging platform, and notification service. Each step may create a new copy, log entry, cache, or write permission.

If the workflow is still vague, stop and use the seven-point workflow readiness test. Data mapping cannot rescue a process nobody has defined.

Map the trigger and every data hop

Draw the workflow left to right. Start with the event that wakes the agent up. Then record each system it calls, the data it receives, the decision it makes, and the action it attempts.

Do not merge several steps into "processes the request." That phrase can hide the exact behavior leadership needs to approve. Does the agent search all customer records or one account? Does it retrieve a full contract or only an entitlement field? Does it update the source record or create a proposed change somewhere else?

Your map should answer these questions for every hop:

System: Which application, database, API, model, or queue is involved?

Data: Which fields, documents, transcripts, metadata, and identifiers move?

Purpose: Why does the agent need that information for this transaction?

Authority: Is the step read, prepare, write with approval, or automatic action within limits?

Evidence: Which log proves what happened, and who can review it?

Separate read access from discovery access

Read access sounds harmless. It is not one permission.

An agent that can retrieve one account by an approved identifier has a different boundary from an agent that can search every account, browse shared drives, follow links, or query a data warehouse. Discovery access expands what the agent may encounter, including records the workflow never needed.

For each source, document the approved data set, fields, filters, record classes, and retrieval method. Note whether source permissions are enforced at query time. Then test what happens after a user loses access or a record changes classification.

Start narrower than the final vision. One mailbox folder is better than the whole tenant. One CRM object is better than unrestricted API scope. A purpose-built view can be safer than giving the agent broad database access and asking the prompt to behave.

Treat every write as a business decision

Write access includes more than editing a database. Sending an email, opening a ticket, scheduling an appointment, triggering a payment, changing a status, posting a message, or calling another automation can alter the business.

List each allowed action separately. Define the record types, fields, amounts, recipients, status transitions, and frequency limits. Mark whether the action is reversible. Name the approval rule for anything that creates a customer commitment, financial impact, legal exposure, access change, or hard-to-reverse result.

A good rollout often moves through four levels: read, prepare, act with approval, and act within tested limits. Do not jump from a clean draft to unrestricted writes because the interface makes approval feel inconvenient.

The AI agent production scorecard gives you a way to measure correct completions, good escalations, false completions, and control failures before adding authority.

Find every place the workflow retains data

"We do not train on your data" does not answer the retention question.

Prompts, retrieved records, tool parameters, outputs, feedback, traces, support records, vector indexes, caches, and audit logs may follow different retention rules. The source application may keep one copy while the agent platform, model provider, and monitoring system each keep another.

Record the storage location, owner, retention period, deletion method, backup behavior, legal-hold impact, and administrator control for each copy. Also record whether users can change a setting that affects the company policy.

Be careful with logs. A detailed trace can help reconstruct a bad action, but a log that copies full prompts and retrieved documents may create another sensitive repository. Keep enough evidence to investigate the transaction without collecting everything forever.

Document where the agent sends data

Outbound data does not stop at the model endpoint. The workflow may call a search provider, enrichment service, speech processor, email system, webhook, analytics platform, support tool, or vendor subprocessor.

Inventory every external recipient and state exactly what it receives. Include destination region, contract owner, encryption requirement, permitted use, retention rule, and failure behavior. If the vendor can add subprocessors, document how your team receives notice and who reviews the change.

The NIST Generative AI Profile recommends inventorying third parties with access to organizational content and updating procurement reviews for data privacy, security, APIs, embedded tools, and service providers. It also recommends inventory entries that include data provenance, human oversight roles, sensitive-data considerations, underlying models, model versions, and access modes.

That is useful implementation guidance. A team should know which service received the data, under which terms, through which route, before a live transaction sends it.

Build the one-page worksheet

A useful map can start as a table. Add a row for every system hop and do not approve the pilot while a required cell remains "unknown."

Add the business owner, technical owner, risk owner, data classification, production environment, contract references, and next review date at the top. Record the stop procedure and credential revocation path at the bottom.

This is an implementation artifact, not a policy deck. The people who configure the connectors and approval rules should be able to build directly from it.

Test the map with synthetic data

Documentation is a claim until the system proves it.

Create synthetic records that look like real workflow data without exposing a real customer or employee. Include a permitted record, a restricted record, an ambiguous match, a revoked user, a missing field, a request that requires approval, and an action beyond the agent's limit.

Run the workflow and inspect the source systems, admin console, audit logs, model traces, downstream records, and notifications. Confirm that blocked data stays blocked, required approvals appear, denied writes fail safely, and the trace contains enough context for investigation.

Then test deletion and decommissioning. Remove the synthetic source record, revoke the agent identity, disconnect the connector, and follow the retained copies. NIST calls for deactivation protocols and asks organizations to consider retention, leakage, and upstream or downstream dependencies when decommissioning a generative AI system.

If the team cannot show what remains, the data boundary is still unknown.

Use the map to make the pilot decision

Approve a controlled pilot when the workflow is narrow, the identities are distinguishable, permissions match the job, downstream actions have real limits, retention is understood, external recipients are known, and the evidence path works.

Revise the design when the agent needs broad access because the data architecture is messy, when a prompt is doing the job of an access control, or when nobody can explain where traces and connector data go.

Stop when a deal breaker remains unclear. Restricted data, unbounded writes, missing logs, no deletion path, and no tested shutdown procedure do not become acceptable because the model output looked good.

Map one transaction. Test the boundary. Let the agent earn more access with evidence.