Executive Brief

An AI agent may have a simple assignment: locate the latest internal guidance, answer a support question, summarize a customer record, or prepare an operational update. Its data security challenge can be considerably less simple. The agent can use a separate technical identity, retrieve source material through an index, combine passages from multiple systems, and invoke connected tools. Permissions that are clear in each original application may become difficult to explain once those steps are chained.

This playbook is designed to help a security, data, and AI implementation team prove one bounded agent workflow before broad deployment. It provides worksheets for inventory, information classification, decision rights, request-time control, and safe validation; an eleven-domain readiness method; and a practical 90-day schedule. It does not assume that using an agent creates a breach, that all data should be blocked, or that an automated content filter replaces authorization.

Microsoft documents identity, role, and document-level security practices for Azure AI Search. [1] AWS describes knowledge-base retrieval and management permissions as explicit IAM actions. [2] Google Cloud states both supported and unsupported security controls for its RAG Engine. [3] These are platform-specific illustrations. The common CyberTech Intelligence recommendation is to connect the requester, agent identity, source permission, retrieval decision, tool action, and output to an accountable business purpose.

Set an Approved Agent and Source Inventory

Choose one agent and write a one-sentence purpose that a business owner can verify. Distinguish whether it is allowed to answer questions, draft material, create internal records, or send information to external recipients. A broad statement such as “assist employees with everything” cannot be tested meaningfully. List the systems it will query, how it accesses them, and who owns each source. Include the source location, connected account, search index, retrieval service, and any intermediate storage where excerpts may persist.

Start with three use cases rather than an unrestricted enterprise inventory. For example, a support summary may need service tickets and approved product documentation; a compliance review may need policy materials and specific evidence repositories; a sales account brief may need approved CRM data. These examples are design patterns, not claims about a particular organization’s current integrations. Use the inventory to identify where source-specific permission tests can be performed safely.

Worksheet 1. Agent, Source, and Action Inventory

Record

What to capture

Reason for review

Business task

Agent identifier, use case, allowed audience, output and decision owner.

Prevents a general-purpose assistant from silently expanding into unrelated data use.

Source

System, repository, collection, owner, classification, update schedule.

Makes indexed copies and original-source rules traceable.

Requester and agent identity

User or service principal, delegation method, group and role boundaries.

Separates platform service access from person-specific authorization.

Retrieval layer

Search index, permission metadata, filter, refresh mechanism, cached chunks.

Shows whether access checks remain effective after ingestion.

Action tool

Tool name, allowed operations, destinations, authorization, approval.

Prevents an information search from inheriting unnecessary write or export rights.

Output and logs

Recipient, retention, masking policy, audit location and access.

Covers disclosure through responses, files, tool results, and records.

Define Sensitive Context and Authorized Use

The same passage may have different treatment depending on requester and purpose. A contract clause may be legitimately used by legal counsel and inappropriate in a general answer for another business unit. An internal incident note may contain sensitive operational detail even if it contains no email address. Classification should therefore combine content type, source owner, intended audience, and any contractual or policy restrictions.

Do not reduce classification to a keyword scan. Identify personal information, proprietary source text, confidential business relationships, financial or security-sensitive records, credentials, and restricted customer data. For each class, define whether the agent may ingest it, retrieve it for an authorized task, quote it, summarize it, send it to another system, or retain it in logs. Denying one activity need not deny all others. The data owner should determine legitimate use with relevant privacy and security authorities.

When designing controls, account for the limits of platform capabilities. Google Cloud’s published RAG Engine quickstart identifies support for specific controls, such as CMEK and VPC-SC, while stating that other named features are not supported. [3] A security claim must follow the actual deployment version, region, data path, and service rather than treating a platform name as comprehensive protection.

Worksheet 2. Sensitive Context and Disclosure Matrix

Data class

Authorized example

Constrained or disallowed example

Evidence

Customer information

Answer an approved service question for that customer.

Combine records belonging to unrelated customers.

Source ownership, requester relationship, denied test.

Internal documents

Summarize approved policy for an employee.

Return restricted draft strategy to a general audience.

Classification label, permission check, source link.

Credentials and secrets

Use managed authentication without exposing secret values.

Show a key in a generated answer, export, or log.

Credential handling test; masked output check.

Personal information

Support a documented and permitted service workflow.

Share personal fields beyond the permitted audience.

Purpose basis, minimization, response test.

Operational security records

Produce an authorized incident or control summary.

Send detailed internal response procedures externally.

Owner approval, destination check, action trace.

Assign Data and Tool Decision Rights

People who configure agents are not automatically the owners of every source the agents can query. Name the business sponsor for the task, the data owner for each restricted source, the identity or platform owner who grants privileges, the security reviewer who tests enforcement, and the authority that can approve a time-limited exception. A small team can combine roles, but the approval question should be explicit.

AWS documents the permissions needed to operate and manage Bedrock Knowledge Bases, including separate actions for retrieval, source management, and ingestion. [2] That product description is an example of granular control, not evidence that any specific deployment is least-privileged. The team should compare configured permissions to the job and remove capabilities that are unnecessary to complete it. This is especially important for tool endpoints capable of writing data.

Worksheet 3. Agent Data Decision-Rights Record

Decision owner

Must answer

Evidence to retain

Business sponsor

What result is the agent authorized to produce?

Use-case description, scope, and change approval.

Source owner

Which documents may be retrieved, by whom, and for what purpose?

Permission rule, classified data, owner sign-off.

Platform/identity owner

Which agent and user identities have what privileges?

Role grants, token flow, service boundaries, expiry.

Security reviewer

Do allowed and denied cases work as described?

Safe test results, limitations, material exceptions.

Risk/exception owner

What deviation is justified and until when?

Named approver, residual concern, expiry, review.

Operations owner

How is access changed or withdrawn after a workflow ends?

Change events, audit trail, revocation test.

Build Retrieval and Disclosure Gates

There are at least four decisions to enforce. The requester must be authenticated. The requester must be authorized for the source data. The retrieval system must narrow results appropriately. Any response or tool action must respect the approved purpose. A search filter or model instruction can assist with part of that chain, but it is not a blanket replacement for source permissions.

Microsoft’s Azure AI Search security guidance describes roles for managing and querying indexes and document-level access patterns for agentic AI. [1] Treat its feature details as specific to the relevant deployment, including preview limitations where applicable. Where a retrieval system relies on permission labels or metadata, verify those labels are trustworthy and up to date. Test users from permitted and non-permitted groups, mixed-classification search results, moved documents, and changes to user group membership.

Amazon Bedrock Guardrails offers configurable denied-topic checks. [4] Such checks may help enforce content policy for particular requests or responses, but an agent should not use them as its proof that a user may read a confidential source. A denied topic filter, a personally identifying information filter, and an authorization decision answer different questions. Record which check ran at which stage and what class of information or action it actually covered.

Worksheet 4. Retrieval and Disclosure Gate

Gate question

Required test

Closure evidence

Who is asking?

Verify human/service requester identity and expiry.

Verified subject and request context.

Can they read the source?

Use source entitlement or trusted, tested permission-aware retrieval.

Source reference, permission result and allowed/denied cases.

May content enter context?

Inspect retrieved chunk classification and business purpose.

Chunk ID, classification decision, relevant handling rule.

May the agent act?

Authorize write, export, or send independently from read.

Tool grant, destination, approval and action trace.

Can access be removed?

Disable a permission, account, or source and retest.

Denied result, revocation timestamp, named reviewer.

Validate Across Documents, Context, and Tools

Use test fixtures that contain fictitious names and records rather than importing real customer secrets into a test. Create one publicly shareable document, one internal restricted document, and one document accessible only to a specified test group. Test answers to permitted and denied questions, then check what was retrieved, what was passed to the model, what appeared in its answer, and whether any tool actions were attempted. Preserve the rule version and identity context in a controlled evidence location.

Next, introduce an adversarial test document that tells the agent to ignore policies, search for unrelated documents, or send contents to a destination. The objective is not to claim immunity after one test. It is to observe whether access and tool boundaries remain in force when outside content contains instructions. A secure refusal in the final response does not necessarily prove that the system never retrieved inappropriate content, so collect observations at each layer.

NIST’s SP 800-218A is a final secure-development community profile for generative AI and foundation models and supplements the Secure Software Development Framework. [6] Use it as development-process guidance rather than an automatic security certification. Tie test cases to changes in code, prompts, model versions, connectors, data schema, and access policies. Re-run the relevant tests before and after higher-consequence changes.

Measure and Improve

Select a few useful measures rather than inventing a universal risk score. Track the share of in-scope agents with owners, the share of sensitive sources with explicit permission paths, the coverage of allowed and denied retrieval tests, the percentage of write-capable tools reviewed for destination restrictions, and the number of exceptions without a current expiry. Keep counts as observed program metrics and provide denominators.

NIST’s AI RMF Playbook is voluntary guidance covering Govern, Map, Measure, and Manage functions, and can help frame why a measure exists and how its results inform decisions. [5] The percentages below are not external benchmarks or a prediction. They are internal operational views that can be calculated when the organization supplies valid current evidence.

• Owner completeness = agents with current business and technical owners / in-scope agents.

• Retrieval verification = tested permission-sensitive sources/priority permission-sensitive sources.

• Negative-case coverage = passed denied-request cases / required denied-request cases in a documented test plan.

• Action review = high-consequence tools with verified scope and destination rules / all identified high-consequence tools.

• Evidence closure = actions to remove or restrict permission with verified retest/actions reported as completed.

Score Readiness

Agent Data Security Readiness Score

Rate each of the eleven domains from 0 to 4: 0 = absent; 1 = informal; 2 = documented; 3 = implemented and tested; 4 = regularly measured and improved. Total possible = 44. Readiness percent = 100 × total / 44. Illustrative CTI bands: Basic 0–24%; Developing 25–49%; Defined 50–69%; Managed 70–84%; Adaptive 85–100%. This is a CyberTech Intelligence internal decision aid, not an external audit, certification, assurance statement, security guarantee, or commercial forecast.

Readiness domain

Question to test

Evidence expected

Purpose and owner

Is each agent assigned a task, owner, data purpose, and retirement event?

Approved scope; owner; lifecycle record

Source inventory

Are approved systems, repositories, document classes, and connectors identified?

Current source map; connector owner

Agent identity

Are agent and delegated identities documented independently?

Role, token flow, account mapping

Data classification

Are sensitive records identified before indexing and prompting?

Classification tags; sample inspection

Retrieval permissions

Can unauthorized documents be excluded through tested controls?

Allowed/denied search tests and policy scope

Tool and action scope

Are write, export, and send actions separately authorized?

Tool inventory; grants; constraints

Untrusted-content defenses

Are retrieved instructions treated as data and tested?

Prompt-injection test record; mitigations

Sensitive-output handling

Are intended disclosures and masking/blocking exceptions documented?

Output tests; logging and filter coverage

Audit evidence

Can a decision be traced to source, identity, tool and policy?

Scoped audit record and retention schedule

Exception and change governance

Do exceptions expire and access changes prompt review?

Exception owner; expiry; change trigger

Revocation and validation

Can access be removed and verified without breaking needed work?

Revocation test; rollback; closure evidence

Run a 90-Day Agent Data Sprint

A 90-day plan should validate one workflow before expanding to an entire enterprise. Focus first on known owners, high-consequence sources, and safe test requests. New features should be added only when previous steps are understandable. A reduction in visible risks is not proof of zero risk; it is a reason to review the next priority boundary.

Worksheet 5. 90-Day Agent Data Sprint Planner

Period

Primary work

Evidence of completion

Days 0–30

Select agent use cases; inventory sources, agents and tools; classify sensitive material; name owners; define approved disclosure rules.

Approved scope, source map, identity list, class labels, first test fixtures.

Days 31–60

Test retrieval permissions and source refresh; run denied requests; separate read from write actions; challenge untrusted documents; record exceptions.

Allowed/denied tests, agent context inspection, tool approvals, exception register.

Days 61–90

Re-test after permission changes; verify revocation; measure coverage; review logging and retention; identify next sources and high-consequence actions.

Closure records, eleven-domain score, named owners, next 90-day plan.

CyberTech Intelligence Agent Data Boundary Framework

The eight layers below are CyberTech Intelligence synthesis. They provide a consistent vocabulary for business, security, data, identity, and engineering teams. They are not a new technical standard and cannot certify an agent deployment.

• 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.

Build Your 90-Day Agent Data Plan

Pick one agent, two sensitive sources, and one action-capable tool. Complete the five worksheets, test one permitted and one denied request, record the eleven readiness domains, and assign the next review owner. Use this first bounded cycle to plan the next 90 days before expanding access.

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. Microsoft Learn, “Best practices for security, Azure AI Search.” 2026 guidance covers role-scoped access and document-level access for agentic search. https://learn.microsoft.com/en-us/azure/search/search-security-best-practices 
  2. Amazon Web Services, “Set up permissions for Amazon Bedrock Knowledge Bases.” Current vendor documentation describes specific knowledge-base management and retrieval permissions. https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-prereq-permissions-general.html 
  3. Google Cloud, “RAG quickstart, Gemini Enterprise Agent Platform.” Current platform documentation identifies supported and unsupported security controls. https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/rag-quickstart 
  4. Amazon Web Services, “Block denied topics using Amazon Bedrock Guardrails.” Current feature guidance distinguishes configured topic detection from general authorization. https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-denied-topics.html 
  5. NIST, “AI RMF Playbook.” Voluntary guidance organizes AI risk management under Govern, Map, Measure, and Manage. https://airc.nist.gov/airmf-resources/playbook/ 
  6. NIST, “SP 800-218A: Secure Software Development Practices for Generative AI.” July 2024 final community profile extends secure-development practice to generative AI. https://csrc.nist.gov/pubs/sp/800/218/a/final