How to Give an AI Agent Access to Sensitive Data Safely
Give an AI agent access to sensitive data by giving it a distinct identity rather than a shared service account, authorizing every action rather than every session, requiring the agent to assert a purpose that policy can evaluate, and placing enforcement at the data object so the control survives the pipeline. The agent should hold no standing entitlement of its own. Each retrieval, tool call and write produces its own authorization decision against current attributes, recorded in a form that can be queried later without a human reading every event.
Why a service account model breaks for AI agents
The service account model assumes a workload with a fixed, narrow job: one function, one data set, a grant reviewed at onboarding and rarely again. AI agents violate every part of that assumption.
An agent's action set is not fixed at design time. It plans, and the plan determines which tools it calls and which data it touches, so the permission a service account needs is the union of everything the agent might ever need. That union becomes the standing grant.
An agent acts for many different people. A service account collapses them into one identity, so the data layer sees the agent rather than the analyst who asked, and the decision loses the attribute that mattered. That collapse also destroys attribution: the log says the agent read the record, which answers nothing about whose task caused it.
The OWASP Top 10 for Agentic Applications, published 9 December 2025 by the OWASP GenAI Security Project, lists Identity and Privilege Abuse (ASI03) and Tool Misuse and Exploitation (ASI02) for exactly this reason. A broad standing credential turns a prompt injection into a data access with no further step required. Delegation structures that preserve the human principal are examined in AI Agent Credential Delegation Chains and Policy-Bound Tokens.
Per-action authorization instead of per-session authorization
Per-session authorization asks once, at the start, and permits everything afterward. That works when a session is a human doing bounded work over minutes. It fails when a session is an agent issuing hundreds of retrievals in the same interval, because the single decision at the front covers actions nobody had described when it was made.
Per-action authorization asks at each step. The agent requests a specific object, for a specific action, with a specific asserted purpose, on behalf of a specific principal. The policy decision point evaluates that request against current attributes and returns allow or deny for that object alone.
Three properties follow. Revocation takes effect at the next action rather than the next session. A hijacked plan cannot ride an existing grant into data outside its scope, because there is no existing grant. And each decision record names the object, making the audit question answerable at the object level. How the decision component works is set out in What Is a Policy Decision Point.
Purpose as an asserted attribute
Purpose limitation traditionally works by inference. A clinician opening a chart in an encounter workflow is presumed to be delivering care; an analyst querying from a fraud console is presumed to be investigating fraud. The context supplies the purpose, and policy reads the context.
Agents remove that context. The same agent, holding the same tools, reads the same record for care delivery, billing reconciliation, model evaluation and a user's ad hoc question. Nothing in the request distinguishes them, so purpose cannot be inferred from the path the request arrived on.
The correction is to make purpose an explicit attribute the caller asserts and policy evaluates. The agent submits a purpose value with each request; policy accepts or rejects that purpose for that object, principal and action; the asserted purpose is recorded with the decision. Policy can then deny on purpose alone, the record shows what was claimed, and a false assertion becomes a reviewable, attributable act rather than an invisible one.
Asserted purpose is not proof of intent. An agent instructed to assert a permitted purpose will assert it. The mechanism provides a policy hook and an evidence trail, not honesty enforcement.
Why post-hoc review stops working at machine volume
Post-hoc review assumes an alert queue a human can work through and a per-event investigation cost small relative to the event count. Agents break the ratio rather than the concept. A single agent task can generate hundreds of data accesses in seconds, and a population of agents generates volume no review team clears. The practical outcomes are sampling, threshold alerting that misses low-and-slow patterns, or an unread log. In each case review has stopped being a control and become a record.
The structural fix is to move the decision forward. If every access is authorized before it happens, against current attributes and an asserted purpose, the volume that overwhelms review is already governed as it occurs, and the log becomes evidence rather than the last line of defense.
What derived artifacts inherit from their sources
Sensitive data does not stay in its original form once an agent works with it. It becomes chunks, embeddings, index entries, caches, summaries, agent memory, tool outputs and sometimes fine-tuning data. Each derived artifact is a copy with weaker governance than its source unless the inheritance is made explicit.
| Derived artifact | What it retains from the source | Common failure |
|---|---|---|
| Text chunks in a retrieval store | Substantially the full content, split | Chunk store carries no classification or policy from the source object |
| Vector embeddings | A lossy but meaningful representation; published research shows text can be partially reconstructed from embeddings | Embeddings treated as non-sensitive because they are not readable by eye |
| Retrieval index metadata | Titles, paths, identifiers, timestamps | Index browsable by users with no access to the underlying documents |
| Agent memory and scratchpads | Verbatim excerpts carried across turns and sometimes across users | Memory persists past the authorization that produced its contents |
| Caches and tool outputs | Whole responses containing released content | Cache read path skips the authorization the original read passed |
| Fine-tuning and evaluation sets | Content absorbed into model weights or held indefinitely | No revocation path once training has occurred |
The rule that keeps this tractable: a derived artifact inherits the most restrictive policy of every source it draws from, at creation time rather than at review time. An index built from documents with three classifications is governed at the highest of the three unless every entry carries its own source policy. Trust boundaries in retrieval pipelines are covered in Protecting RAG Context and Agent Tool Outputs at Trust Boundaries.
Fine-tuning is the one derivation with no revocation path. Content absorbed into weights cannot be withdrawn by changing a policy, which makes the decision at ingestion the only decision that will ever be made about it.
What NIST and OWASP say about agent access to data
| Source | Status | What it covers |
|---|---|---|
| NIST Control Overlays for Securing AI Systems (COSAiS) | Concept paper published 14 August 2025; annotated outline for the predictive AI overlay released 8 January 2026 | Five planned SP 800-53 control overlays, two of which cover AI agent systems, single-agent and multi-agent |
| OWASP Top 10 for Agentic Applications | Published 9 December 2025 | Ten agentic risk categories including Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Memory and Context Poisoning, and Rogue Agents |
| NIST SP 800-207, Zero Trust Architecture | Final, August 2020 | Policy engine, policy administrator and policy enforcement point separation, which applies to non-human subjects unchanged |
COSAiS matters for organizations that map controls to SP 800-53, because it treats agent systems as their own control context rather than as an application of general AI guidance. Neither agent overlay had been published as of this writing, so mappings against them remain provisional.
Steps to grant an AI agent access to sensitive data
- Give the agent its own identity. Distinct from the human principal, from other agents, and per deployment. Shared identities make every later step unenforceable.
- Carry the human principal through every call. The data layer decides against the requesting user's attributes, with the agent identity as an additional subject attribute rather than a replacement.
- Grant no standing entitlement. The agent's own permissions should be the empty set. Everything it reaches, it reaches on behalf of a principal, per action.
- Require an asserted purpose on every request. Evaluate it in policy, record it with the decision, and deny purposes not permitted for that object and principal.
- Authorize each action, not each session. One decision per object per action, against current attributes.
- Place enforcement at the object. Enforcement at the application or gateway is bypassed by the next pipeline; enforcement at decrypt applies wherever the object is opened.
- Propagate policy into every derived artifact. Chunks, embeddings, index entries, caches and memory inherit the most restrictive source policy at creation.
- Record decisions, not just accesses. Each record names the object, principal, agent, asserted purpose, effect, reasons and policy version.
- Set fail-closed defaults. An unreachable decision point denies.
- Test revocation end to end. Withdraw an attribute and confirm the next agent action denies, including through caches and retrieval indexes.
What per-action authorization does not solve
Per-action authorization does not govern content after release. Once a decision permits a read and plaintext enters a context window, the control has been exercised; what the model does afterward is a model behavior problem.
Per-action authorization does not stop prompt injection, it bounds the consequences. An injected instruction still produces requests, and those requests still face policy, so the attacker inherits the principal's entitlements rather than a union of everything.
Per-action authorization does not remove attribute governance, and agent volume amplifies the error when a clearance is stale or a classification wrong. Nor does it eliminate the availability dependency: fail-closed defaults mean an unreachable decision point stops agent work.
Frequently asked questions
How do you securely allow AI agents to access sensitive data?
Give the agent its own identity, grant it no standing entitlement, and require it to act on behalf of a named human principal. Authorize each individual action against current attributes rather than authorizing a session. Require an asserted purpose that policy evaluates and records. Place enforcement at the data object so the control applies wherever the object is opened, and propagate the source policy into every derived artifact.
How are permissions enforced when agents access enterprise data?
Permissions are enforced by a policy enforcement point positioned where the agent cannot route around it, calling a policy decision point for each requested object and action. The decision evaluates the human principal's attributes, the agent identity, the asserted purpose, device and network posture, and the object's own attributes. Enforcement at decrypt time survives changes to the orchestrator, retrieval layer and tooling in the path.
What is policy-based authorization for AI agents?
Policy-based authorization for AI agents evaluates a written policy at the moment of each agent action rather than issuing the agent a durable permission. The policy references attributes of the requesting principal, the agent, the object and the environment, including asserted purpose. Because the evaluation is per action, revoking an attribute changes the next answer immediately, with no credential to rotate or session to terminate.
Do vector indexes and embeddings inherit the permissions of their source documents?
Not automatically. A chunk store, embedding set or index is a new artifact, and it carries only the governance its pipeline gives it. Published research shows meaningful content can be recovered from text embeddings, so treating them as non-sensitive is unsafe. The workable rule is that each derived artifact inherits the most restrictive policy of every source it draws from, applied at creation.
How Lattix enforces agent access
The Lattix policy decision point evaluates attribute-based access control (ABAC) across subject, device, environment and geography, purpose of use, network posture, risk and data-object attributes, which is the same evaluation for a human principal and for an agent acting on that principal's behalf. It returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash and the object identifier, so each agent action produces an object-level record. The Lattix policy enforcement point acts at decrypt time, below the orchestrator, the retrieval layer and any tool in the path. Defaults are fail-closed and revocation propagates to deny, so a withdrawn attribute stops the next action. Content identifiers and Merkle-tree lineage records make decision history queryable. Which authorization model to evaluate is compared in ABAC, RBAC and ReBAC: Which Model Answers Which Question.