AI Agents Should Not See Every Document They Can Find

At a Glance

• OWASP identifies sensitive information disclosure as a risk for large-language-model applications. The sensitive material can include personal data, confidential documents, credentials, and proprietary information. [1]

• AWS documents ACL-aware retrieval for Bedrock Managed Knowledge Bases, while explicitly warning that this filtering is not the same as authenticating and authorizing an end user. [2]

• Microsoft documents Prompt Shields for user-supplied prompts and instructions hidden in outside documents. A detection layer is useful but should not substitute for access controls or tested application behavior. [3]

• CyberTech Intelligence view: a reliable agent-data review follows information from its original permission boundary through retrieval, prompt context, tool use, and final response. A possible leakage path is a design consideration, not evidence that a named company leaked data.

The New Question: What Information Is the Agent Allowed to Use?

Organizations commonly introduce AI agents to search approved materials, summarize records, answer questions, or carry out repetitive work. These are legitimate uses. The security question is not whether an agent can find a useful answer. It is whether the agent is permitted to read the source, combine its contents with other data, and reveal the result to the person who requested it.

A person may have access to an application without being entitled to every document in that application. An agent that uses a broad connector credential can read more than the requesting person, depending on design. A knowledge base can contain material from multiple teams or customers. If search results are selected only by topical relevance, confidential context may enter an answer even when it is not appropriate for that requester. These are plausible design failures that must be tested against an actual implementation before anyone calls them findings.

OWASP distinguishes authorization from authentication. Knowing which person or service sent a request does not establish permission to perform every action or read every resource. [4] CyberTech Intelligence recommends carrying that distinction all the way through the agent journey. The user, the agent identity, the retrieval service, and the action tool may have different permissions; the most permissive one should not quietly become the rule for all.

Why Retrieval Needs Its Own Access Boundary

In a search-enabled agent, source content is often copied or indexed into a form that can be searched quickly. The original repository may know which employee can open a contract, customer record, or internal report. The search layer may instead rely on metadata and identity information supplied by an application. AWS documents an ACL-aware retrieval pattern that filters knowledge-base results using document permissions and caller context. It is explicit that upstream authentication is still the application’s responsibility. [2]

That distinction matters during design review. A filter using a verified requester identity is not equivalent to a string that any caller can invent. An index containing access labels is not proof that those labels stay current after a source permission changes. A filter matching document metadata is not necessarily authorization for the original document. Every implementation needs the appropriate source-specific checks, tested deny cases, and a record of which feature actually enforces which boundary.

The Bedrock RetrievalFilter API also supports metadata conditions on knowledge-base content. [5] These conditions can narrow search results, but a useful subject or date filter does not become a person-level access control by itself. CTI’s recommended evidence is a reproducible request: identify the requester, source document, relevant permission, applied search restriction, returned result, and observed final answer.

Sensitive Context Can Leak Without a Dramatic Security Event

Some disclosures are obvious, such as reproducing a private record verbatim. Others are contextual: combining several permitted snippets into a response that reveals a confidential relationship, sending excerpts to an external tool, including credentials in diagnostic output, or leaving sensitive source text in broad application logs. OWASP’s sensitive-information category covers several classes of sensitive material, but an assessment must establish what is actually sensitive under the organization’s data policy. [1]

Teams should distinguish accidental inclusion, permitted use, and unauthorized disclosure. An agent quoting a sensitive passage to an authorized employee can be expected behavior. The same passage shown to an unauthorized requester may be a control failure. A redacted answer might still disclose sensitive facts through its structure or surrounding context. The right determination depends on permission, classification, business purpose, and actual request evidence.

Treat Retrieved Material as Evidence, Not Authority

An agent can encounter instructions inside a retrieved document, website, spreadsheet, or email that conflict with its approved task. Microsoft’s Prompt Shields distinguishes user-prompt attacks from attacks hidden in third-party content, and documents where the detection controls can be configured. [3] A useful security design therefore treats outside material as task data and does not let its embedded commands redefine who can access what.

A response that is correctly summarized may still be inappropriately disclosed. Conversely, an answer containing little sensitive detail can be unsafe if it triggered an unauthorized send or export action. Review must cover both information shown to users and actions the agent attempted with connected tools.

A Five-Step Agent Data Boundary Check

What Practical Readiness Looks Like

• An agent has a business owner and a narrow, written purpose. Connected systems and data owners are identified before scale-up.

• The requesting person and the technical identity used by the agent are distinguishable in access evidence. Sensitive sources are classified and handled according to their owners’ rules.

• Retrieval restrictions are checked with both approved and disallowed test users. Search filters, platform access permissions, and application authorization are not treated as interchangeable.

• Tool permissions are deliberately narrow. A read-only research task does not inherit email, export, file-change, or administrative permissions by convenience.

• Reviewers can trace a generated statement to relevant source context without placing unnecessary sensitive information in broadly accessible logs.

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.

Evidence and Citation Note

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, “LLM02:2025 Sensitive Information Disclosure.” 2025 risk taxonomy; sensitive data may include personal information, credentials, and confidential documents. https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/
2. Amazon Web Services, “Access Control Lists awareness enablement, Amazon Bedrock.” Current product guidance explicitly says ACL-aware retrieval is filtering, not end-user authorization. https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.html 
3. Microsoft Learn, “Prompt Shields in Microsoft Foundry.” Current documentation explains separate user-prompt and document attack checks; coverage depends on configuration. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/content-filter-prompt-shields 
4. OWASP Cheat Sheet Series, “Authorization Cheat Sheet.” Maintained application-security guidance distinguishes authentication from authorization and recommends request authorization. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html 
5. Amazon Web Services, “RetrievalFilter, Amazon Bedrock API.” Current API reference documents filter conditions on knowledge-base metadata. https://docs.aws.amazon.com/bedrock/latest/APIReference/API_RetrievalFilter.html