Data Security for AI Agents: From Source Permission to Governed Data Use

Executive Summary

AI agents can receive a task, retrieve content from enterprise sources, assemble working context, and execute a sequence of actions through connected tools. Their security posture cannot be inferred from the model name, existence of a search index, or a single output filter. The operative question is which data an agent may read for a particular request, which confidential context may appear in its working material, what instructions it may trust, and where any result may be disclosed or sent. Each step changes the access decision that must be explained.

This report is a secondary-research synthesis using public risk guidance, platform documentation, and CyberTech Intelligence operating analysis. OWASP describes prompt injection risk in large-language-model systems and states that retrieval augmentation does not fully eliminate that risk. [1] NIST’s Generative AI Profile is a cross-sector companion to the AI Risk Management Framework. [2] MITRE ATLAS documents a technique in which malicious instructions are planted in a public-facing application for later ingestion by an agent or retrieval system. [3] These sources support a risk-informed architecture discussion; they do not establish prevalence, a breach count, or findings about a specific organization.

The main CyberTech Intelligence conclusion is that effective data use needs an evidence chain: approved purpose, accountable owner, identity, source permission, retrieval selection, context classification, tool rights, destination controls, activity record, and review or removal trigger. If only some of those elements are visible, the sound conclusion is that the available evidence is incomplete, not that a leak or compromise has occurred. Conversely, a clean final answer is insufficient evidence if an unauthorized source was retrieved or a tool action moved information elsewhere.

This research offers six findings, five board-level evidence measures, a twelve-month staged roadmap, and an eleven-domain readiness method. The framework is proposed CTI synthesis, not a technical standard or independently validated benchmarking instrument. It is intended to support responsible agent deployment decisions without making undocumented claims about individual vendors or target accounts.

Research Methodology and Source Selection

Research was limited to publicly available primary documentation and authoritative maintained references accessible as of October 9, 2026. Sources were selected for relevance to prompt injection, generative-AI risk, permission-aware retrieval, malicious indexed content, output evaluation, technical API surfaces, and operating-risk measurement. A source was included only when the specific point it supports could be identified and stated without assuming local deployment details. No private telemetry, independent penetration test, market panel, survey sample, or proprietary product benchmark was commissioned for this report.

The OWASP 2025 risk material supports the existence and mechanisms of threat classes rather than numerical prevalence. [1] NIST AI 600-1 supports structured risk-management concepts and recommended actions, not a universal set of mandatory controls for private businesses. [2] MITRE technique descriptions support a plausible adversary workflow and threat-informed test cases, not proof of exploitation at any named organization. [3] Microsoft Azure AI Search documents query-time identity and permission enforcement as preview functionality with stated dependencies on permission metadata. [4] AWS documents contextual grounding checks with use-case boundaries that must be considered before describing their effect. [5]

Microsoft’s Prompt Shields REST API documents an input structure for testing user prompts and documents, which is useful as an example of separate attack surfaces. [6] NIST’s AI RMF Measure function provides guidance for selecting and documenting risk metrics, including those not adequately measured. [7] The OWASP Gen AI Top 10 index is a maintained taxonomy covering several related risks, including sensitive information disclosure and output handling. [8] Different source types are not pooled to imply agreement on deployment effectiveness; their scopes remain separate.

Evidence Universe and Assumptions

The evidence universe contains six layers. The first is purpose: the business task, supported user group, authorized result, and accountable owner. The second is access: human and service identities, delegated authority, group membership, roles, and source permissions. The third is retrieval: repositories, indexed replicas, embeddings or search infrastructure, document permission metadata, filter conditions, and query-time behavior. The fourth is context: text or data passed to a model, intermediate summaries, memory, prompt assembly, and source provenance. The fifth is agency: available tools, operations, destinations, workflow steps, and any consequential action approvals. The sixth is governance: logs, versioned policies, evidence, exception owners, testing, change triggers, and revocation.

This is a logical analysis model, not a claim that all agent platforms implement these layers in the same way. Some systems make one call to retrieve data; others operate a multi-step workflow. Some tools work under the human requester’s authority; others use a service role or delegated token. Some deployments prohibit external tool calls entirely. The model should be adapted to what the product and organization actually do, and a judgment should be made only at the scope supported by that evidence.

Evidence Grading

Grade A – Final government standards and risk-management publications with an explicit scope. Permitted use: structured risk identification, security-development and governance principles. A framework does not itself establish a finding at any private company.

Grade B – Maintained independent risk taxonomies and adversary knowledge. Permitted use: documented threat mechanisms, examples, mitigations, and test hypotheses; these do not establish customer incidence or measured product effectiveness.

Grade C – Current first-party cloud or platform documentation. Permitted use: described features, APIs, deployment prerequisites, stated support, preview notices, and limitations of the named product. These pages do not prove which options a specific customer enabled.

Grade D – CyberTech Intelligence analytical synthesis. Permitted use: suggested ownership models, maturity criteria, metrics, decision tables, and roadmaps clearly identified as editorial guidance. Grade D is not a certification, external control standard, legal conclusion, or validation of a deployment.

Research Limitations

This report has no access to an enterprise’s source permissions, identity logs, RAG corpus settings, agent runtime configuration, or tool execution records. Consequently, it cannot assign any specific company a sensitive-data leak, exploitable prompt injection, excess privilege, compliance violation, or unsafe disclosure. Published product capability is not evidence that an implementation uses the product, enables the feature, supplies trustworthy identity context, or keeps index permissions synchronized.

An authorized request may legitimately return a sensitive answer. A denied answer may be correct despite an underlying permission problem that allowed inappropriate retrieval earlier in the flow. A content filter may evaluate a limited text channel while a tool call contains separate structured arguments. A prompt-injection test may pass once and fail under a different document, source, task, or model. Data-security conclusions therefore need current scope, negative testing, repeatability, and careful interpretation.

The report does not derive market opportunity, return on investment, breach probability, or expected loss reduction from the referenced sources. Suggested metrics below have no numerical external benchmark. They are internal program measures whose denominators must come from a verified, bounded asset and test inventory. Any decision involving regulated data, contractual limitations, or jurisdiction-specific privacy law also requires context-specific legal and privacy assessment outside this secondary-research brief.

Key Terminology Distinctions

Agent identity: the person, service, managed identity, or delegated principal under which an AI-enabled workflow accesses data or calls tools. Requester identity: the identity and current authority of the person or process asking the agent to act. These identities may differ and must not be silently treated as equivalent.

Source authorization: the permission under the original system’s policy to access a document, field, or operation. Retrieval filtering: a condition that selects or suppresses content in a search or knowledge layer. A retrieval filter can support authorization when fed trustworthy data and combined with the right checks, but it is not automatically equivalent to a source authorization decision.

Sensitive context: classified, restricted, or confidential information presented to a model or retained in intermediate working data; may include data combined from several permitted sources. Agent data leakage: a disclosure or transfer of information beyond an authorized audience, purpose, or destination, which requires actual evidence to assert for a specific case. Hypothetical paths, risk taxonomies, and control gaps are not incident records.

Indirect prompt injection: attacker-controlled or untrusted content carrying instructions that an AI system may misinterpret as directives. Tool invocation: an action or data transfer through a connector, API, function, or service. Evidence gap: a missing or unverified fact required to establish a data permission or security conclusion; it should be described as uncertainty rather than as an observed exploit.

Research Framework

The CyberTech Intelligence Agent Data Boundary Framework proceeds through Define, Identify, Bound, Retrieve, Contain, Verify, Observe, and Review. The purpose of its eight layers is to preserve accountability as information moves from an original system into an AI request and then to a response or action. The layers are sequential as a review tool but not as a software implementation mandate. The same evidence can satisfy several layers, and the exact enforcement mechanism depends on the platform.

Executive Findings

• OWASP documents prompt injection as a threat to model behavior and identifies that retrieval augmentation does not fully eliminate the problem. The source provides mechanism evidence, not a claim that every agent can be exploited. [1]

• NIST’s Generative AI Profile provides cross-sector considerations for identifying and managing generative-AI risks as part of a broader AI risk program. It does not issue agent-specific certification. [2]

• MITRE describes malicious instructions planted in content later indexed by RAG or processed by an agent, supporting the case for safe adversarial-document tests. [3]

• Microsoft documents preview query-time permission enforcement based on indexed access metadata and the requesting identity, with deployment and feature restrictions. [4]

• AWS contextual grounding checks evaluate defined reference and query relationships and have use-case limitations; they do not themselves prove source access authorization. [5]

• NIST’s Measure function supports selecting, documenting, and interpreting meaningful program measurements, including risk aspects not currently measured. [7]

Data Access Follows Identity and Purpose

The first security issue is neither vector search nor prompting. It is the scope of legitimate use. The requester has a role and an approved task. The source contains data owned by someone. The agent may run as a third principal with separate privileges. A request must be valid under the relevant source and application rules, not merely under the broadest technical principal in the chain. An agent that can read a repository because its service account has access does not necessarily have authority to quote everything it finds for every requester.

For example, a general employee assistant might have access to an employee handbook and selected policies, while payroll records are restricted. If both document classes are copied into one searchable corpus, the retrieval process must maintain an effective way to distinguish allowed results for that employee. This is an illustrative situation, not a finding about an actual employer or search product. The implementation test asks whether a correctly identified employee receives public policy information and is denied restricted payroll material, including excerpts that might match semantically similar search terms.

A good permission decision includes the original owner and authorization basis; authenticated requester identity; agent or service identity; authorized operation; relevant tenant, group, document or field scope; and a review trigger. If the policy depends on a time-sensitive group membership or a document movement, the design should specify where freshness is verified and how stale copies are handled. The outcome of a test should record observed behavior, not a broader conclusion about every workflow or possible document.

Retrieval Can Alter the Visibility Boundary

Retrieval improves usefulness by finding relevant source passages. But relevance is not an access-control decision. A knowledge index may include documents from different projects, departments, or customers. A filter can limit the result set by category, tenant tag, or user identity. Whether that filtering is a true permission control depends on the provenance of its inputs and where authorization is enforced. The security team should know whether a permission was evaluated by the original repository, by an index with synchronized permissions, or through an application-defined comparison.

Microsoft’s documented preview approach to query-time ACL and RBAC enforcement uses permission metadata supplied during indexing and information about the querying identity. [4] This can be meaningful within supported sources, API versions, and identity flows; the preview label is consequential. It cannot be generalized into a guarantee that all Azure AI Search deployments apply the same check. The report instead treats it as evidence that document-level permission-aware retrieval is a supported design problem with multiple implementation options.

The best test is deliberately negative. Select a test document restricted to one authorized user or group, then submit semantically relevant questions from both an allowed and a denied principal. Review retrieved results before they enter the model, not only the final response. Repeat after permissions change in the source. A denied result demonstrates a specific control under the exact conditions tested; it does not establish complete future coverage across all documents or changed configurations.

Context Assembly Creates New Disclosure Questions

A final response is often formed from several retrieved passages, prior messages, tool results, and intermediate notes. Each may have different provenance and sensitivity. Even if the final message does not reproduce a confidential page, the combined content could reveal a restricted person, customer relationship, internal process, or planned action. A rigorous review therefore distinguishes lawful and permitted synthesis from unauthorized inference or transfer, without assuming all combinations of data are prohibited.

NIST’s GAI Profile describes a structured way to manage risks across the system lifecycle. [2] Within that broad approach, CTI recommends identifying information that may enter context, whether it is persisted, and which audience may receive the resulting summary. Data classes should be defined by an enterprise’s actual policy and obligations. An AI system is not automatically prohibited from using sensitive data; it needs an explicit legitimate purpose, appropriate authorization, and the corresponding handling controls.

Teams can use safe artificial fixtures to see whether a response unintentionally joins facts across access boundaries. An example would pair a publicly visible customer name with an internally restricted renewal note and ask the agent for a combined status. The observation should distinguish a refusal, a partial public-only answer, an internal-only answer to an authorized user, and a leakage of restricted details. Audit the source passages that reached context, because source selection itself is an important part of the result.

Untrusted Sources Can Redirect Agent Behavior

The agent may read documents, emails, support tickets, webpages, and files whose contents are not under the same authority as the agent’s instructions. An attacker can place a directive inside an otherwise relevant-looking paragraph. OWASP describes prompt injection as manipulation of the model’s expected behavior, while MITRE documents a pattern in which hostile instructions are planted in content that a retrieval system may later ingest. [1] [3] These are reasons to test untrusted input boundaries, not evidence of successful exploitation in an individual organization.

The defensive design should preserve a distinction between instructions from the authorized application and content the application was asked to process. The agent can summarize an email that says “forward this to someone” without interpreting that sentence as authority to send a message. A system may employ input screening, instruction isolation, tool-level permissions, and user confirmation for consequential actions. None of those layers makes external material trustworthy by itself. Enforcement must happen at the identity and tool boundaries even when text-based defenses miss a manipulated passage.

A useful test document contains an unauthorized request to look up another team’s records or send a source excerpt elsewhere. This should be tested only in a controlled environment with fictional information and benign destinations. Log whether the instruction was treated as content, whether additional retrieval was attempted, whether the tool was invoked, and whether the final response reflected the untrusted command. The outcome should be documented with model and policy versions so an identical scenario can be retested after changes.

Tool Invocation Adds an Action and Destination Boundary

Connected agents can do more than answer questions. They may create files, update records, send messages, schedule events, or call business APIs. Each action changes the risk model because confidential context may leave the response channel and enter another application. Granting permission to call a tool does not answer whether the user has authority to send specific data to the selected recipient or alter a particular record. Tool permissions therefore need their own business rules, validation, and review.

Microsoft’s Prompt Shields REST API is an example of a separate input assessment service that accepts both user prompts and document arrays. [6] Such a mechanism may contribute to screening, but it cannot validate every downstream authorization or destination choice. AWS’s contextual grounding guidance likewise describes response/source consistency checks with explicit use-case restrictions; a grounded answer might still disclose data to an unauthorized party, and a well-authorized answer can be ungrounded. [5] Safety, correctness, permission, and business authorization are distinct questions.

For higher-consequence tools, test permitted and prohibited recipient domains, destination accounts, file classes, and action types. Require explicit confirmation when business policy calls for human approval. Keep enough audit evidence to reconstruct what tool was invoked, by which technical and requesting identities, with what data class, and under what versioned permission. Preserve logs securely and avoid putting raw secrets into a broadly available testing or observability system.

Verification and Revocation Require Operating Evidence

Once a control is configured, its continued usefulness depends on changes in source systems, data classifications, group membership, connector privileges, and agent tools. A search index may lag a source access update. An agent may gain a new tool or retrieve data through a different connector. A model update may change how adversarial instructions are handled. Reviews must therefore be connected to real changes, not only to annual policy attestations.

A sound closure record includes the scope of the issue, the observed behavior, the authorized expected behavior, the specific control changed, the relevant positive and negative retests, an owner, and a future review trigger. If permission removal breaks the approved task, the right action may be to redesign the workflow or authorize a narrower exception with an expiry. Treating every denied retrieval as success would hide availability and business-purpose failures. Treating every allowed retrieval as insecurity would also be a mistake.

NIST’s Measure function emphasizes selecting metrics suited to the risk and documenting measurement limitations. [7] That is a useful discipline for agent programs. A percentage of agents with owners may be meaningful once the inventory is complete; it is misleading if the denominator excludes shadow deployments. A passing red-team scenario can support a bounded observation, not proof against all prompt variations. Leaders should ask what was tested, under which conditions, and what remained outside scope.

Board-Level Evidence and Decision Metrics

• Agent scope coverage: proportion of priority agents with a named business owner, allowed users, documented task, and current connected-system list.

• Sensitive-source authorization coverage: proportion of critical indexed sources with current permission provenance, identity-binding approach, and approved negative-case test.

• Retrieval denial verification: percentage of required disallowed-access fixtures whose restricted material was absent from retrieved results and final output under the specified requester context.

• High-consequence tool control: percentage of identified tools with documented operation, recipient or destination restrictions, approval route, and access-change owner.

• Review closure quality: share of completed permission changes supported by current test evidence proving the intended restriction or retained access, including exception expiry where applicable.

Twelve-Month Implementation Roadmap

Months 0–3: define a representative set of agent tasks and owners; inventory original source permissions, search copies and write-capable tools; classify sensitive context; run safe allowed and denied access tests. Establish baseline evidence for one complete workflow rather than claiming full enterprise readiness. Build a small backlog of uncertain identity transitions and data-handling rules.

Months 3–6: standardize how request identity and source entitlement travel into retrieval; verify permission refresh and tool action rules; introduce simple source-aware logging and material exception registers; review whether prompt-injection test fixtures exercise both retrieved text and tool actions. Extend coverage only to additional sources with known owners and supported controls.

Months 6–9: expand to more business functions and multi-step agents; test combined-context disclosure and cross-system actions; establish review triggers for tool, model, source-permission and connector changes. Track negative-case pass rates and verified revocation, keeping coverage limitations visible to executives.

Months 9–12: compare control evidence across agent platforms without assuming identical semantics. Automate repeatable inventory or retesting where appropriate, review exceptions and data retention, retire unused service permissions, and refresh the prioritized plan using actual observations. No phase presumes a specific return on investment or guaranteed incident reduction.

Governance and Decision Rights

Purpose approval – Accountable: business sponsor with the relevant data owner. Evidence: task description, intended users, permitted sources and outputs, classification, request scope. Decision: approve, narrow, or reject use. Technical identity and tool scope – Accountable: identity/platform owner. Evidence: agent principal, delegated user context, role and connector grants, destinations, policy review. Decision: configure only required permissions and establish revocation.

Retrieval enforcement – Accountable: retrieval application owner and data owner. Evidence: source permissions, indexing metadata, filter logic, caller identity, freshness limits, allowed and denied request tests. Decision: verify the relevant source and runtime boundary; document any feature-specific exclusions. Sensitive context and outputs – Accountable: data governance and application owner. Evidence: data classes, permitted audience, prompt construction, response and log treatment. Decision: retain, redact, block or refine under current business policy.

Tool execution – Accountable: application workflow owner with risk or security authority. Evidence: permitted operations, destinations, action request and approver where needed, reversible changes, logs. Decision: allow a bounded action or require approval. Change and closure – Accountable: joint platform, security and data owners. Evidence: permission change, retest, exception expiry, owner, rollback, closure. Decision: retain, reduce, revoke, or redesign the path.

CyberTech Intelligence Agent Data Boundary Framework

This eight-layer framework links the operational evidence across the data journey. It is CyberTech Intelligence synthesis based on the scoped evidence above; it is not a standard, automatic product score, or audit verdict.

• 01 - Define: Name the agent job, business owner, data purpose, and decision that the agent must support; record who approves changes.

• 02 - Identify: Inventory the agent, connector identities, source systems, data classes, people, and downstream tools in scope.

• 03 - Bound: Separate source permissions, retrieval permissions, and action permissions; choose the narrowest working role and scope.

• 04 - Retrieve: Carry verified user and document permissions into the search path; treat metadata filters as controls only within verified scope.

• 05 - Contain: Treat retrieved documents and tool results as data, not instructions; use defenses appropriate to the threat and tool chain.

• 06 - Verify: Test allowed and denied requests, sensitive context, adversarial documents, and attempted exports using safe test fixtures.

• 07 - Observe: Collect proportionate logs of source, access decision, tool call, policy version, and review result without retaining unnecessary secrets.

• 08 - Review: Revisit access after new integrations, changed permissions, tool updates, model changes, or agent retirement; retain evidence of closure.

Agent Data Security Readiness Score

Score the eleven domains from 0 to 4 using current evidence: 0 absent, 1 informal, 2 documented, 3 implemented and tested, 4 measured and improved. Maximum 44. Readiness percentage = total/44 × 100. Suggested CyberTech Intelligence interpretation: Basic 0–24%; Developing 25–49%; Defined 50–69%; Managed 70–84%; Adaptive 85–100%. These bands are an internal assessment aid, not a certification, industry benchmark, or prediction of incidents or commercial outcomes.

Agent Data Maturity Model

Reactive: access decisions are made during incidents or urgent rollout requests; agents and indexed sources may not share a consistent inventory.

Immediate emphasis: establish owners, purpose, and first permitted/denied tests.

Defined: core agents, sensitive data, source rules, and action permissions are documented.

Immediate emphasis: test query-time enforcement rather than relying on design assumptions.

Controlled: teams can repeat source-to-response authorization tests, document scope and exceptions, and verify permission changes.

Immediate emphasis: integrate change triggers and destination restrictions.

Adaptive: measures and retests routinely update agent permissions and data-use policies; deviations are investigated with evidence and scope boundaries. The maturity labels describe a proposed CTI operating progression, not measured distribution in the market.

Strategic Takeaway

Responsible agent data security should preserve the authorization boundary as information moves. Source permissions must be considered at retrieval; confidential context must be governed when combined; outside documents must not become authority; and action tools must carry distinct permissions and destination rules. The goal is not a promise of perfect detection. It is an explainable, tested, reviewable process in which a business owner can distinguish intended data use, a documented limitation, and a real observed failure.

About CyberTech Intelligence

CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and evidence-aware security planning.

Research and Citation Governance

Public standards and industry guidance inform the control principles discussed here. Vendor documentation is evidence of a described feature or product limitation, not evidence of a specific customer configuration. Illustrative scenarios and CyberTech Intelligence frameworks are analytical models, not findings about a named organization, incident statements, certifications, breach predictions, or guaranteed outcomes.

References

1. OWASP Gen AI Security Project, “LLM01:2025 Prompt Injection.” 2025 threat description explains malicious directions in untrusted inputs and RAG limits. https://genai.owasp.org/llmrisk/llm01-prompt-injection/  
2. NIST, “AI 600-1: Generative AI Profile.” July 2024 cross-sector profile extends AI RMF risk treatment to generative AI. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence  
3. MITRE D3FEND / ATLAS, “Prompt Infiltration via Public-Facing Application, AML.T0093.” Maintained technique describes malicious instructions planted in material later indexed by RAG. https://d3fend.mitre.org/offensive-technique/attack/AML.T0093/  
4. Microsoft Learn, “Query-Time ACL and RBAC Enforcement, Azure AI Search.” 2026 preview guidance describes identity- and permission-metadata-aware result restrictions. https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement  
5. Amazon Web Services, “Use contextual grounding checks in Amazon Bedrock Guardrails.” The current documented feature has scoped use cases and known limitations, not universal factuality guarantees. https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-contextual-grounding-check.html  
6. Microsoft Learn, “Shield Prompt, Azure AI Content Safety REST API.” Documented API accepts user prompt and document arrays for prompt-attack assessment. https://learn.microsoft.com/en-us/rest/api/contentsafety/text-operations/shield-prompt?view=rest-contentsafety-2024-09-01 
7. NIST AI Resource Center, “Measure: AI RMF Playbook.” Maintained guidance describes selection and documentation of appropriate risk measures. https://airc.nist.gov/airmf-resources/playbook/measure/ 
8. OWASP Gen AI Security Project, “2025 Top 10 for LLMs and Gen AI Apps.” Current index lists separate risks, including prompt injection, sensitive disclosure and output handling. https://genai.owasp.org/llm-top-10/