AI Agent Data Security: A Practical Control Architecture

Executive Summary

Data security for AI agents requires a control architecture that remains meaningful when information is retrieved, combined, and used to take an action. An organization can have well-defined permissions in its source applications while an agent introduces new identities, replicated indexes, intermediate context, or write-capable tools. An agent can also process untrusted content whose apparent instructions should have no authority over the agent’s approved purpose. The design problem is to preserve the right access and disclosure boundaries through that complete flow.

This whitepaper specifies an eight-layer control architecture with seven recurring questions, operational failure scenarios, decision rights, a qualification flow, and an eleven-domain readiness aid. The architecture combines four controls that must not be conflated: authentication of the requester; authorization to underlying data; limits on what the agent can retrieve, process, and disclose; and authorization for any downstream tool action. Prompt screening or output moderation can support those controls, but neither should be treated as a substitute for a source authorization decision.

OWASP’s late-2025 agentic AI material discusses risks associated with goal hijack, tool misuse, and agent identity or privilege abuse. [1] Microsoft describes a least-privilege design pattern for AI agents based on task-scoped identity, permissions, and auditability. [2] Google Cloud’s Secure AI Framework addresses configurable identity and data protections within its platform. [3] NIST’s AI RMF Core provides the cross-sector functions Govern, Map, Measure, and Manage. [4] These sources provide distinct and bounded inputs to the CyberTech Intelligence synthesis; none of them certifies any named agent product or private deployment.

CyberTech Intelligence Perspective

Data security cannot be reduced to “the model knows the rules” or “the documents are behind a login.” The correct unit of control is a request-specific information path: an identified person or process asks an approved agent to complete a defined task; a service or delegated identity accesses a source; a retrieval component selects context; a model produces or plans; a tool may act; and the result is shown, stored, or transferred. The owner should be able to trace who authorized every consequential boundary crossing.

A security assessment should also resist exaggeration. A permitted search result is not evidence of leakage. A malicious instruction hidden in a test file is not proof of successful exploitation. A configurable guardrail is not assurance that it was enabled. A denied test is evidence only for the identity, data, policy, model and runtime conditions used in that test. A responsible architecture records the distinction between published control capability and proven deployment behavior.

Evidence Base for the Architecture

OWASP’s agentic risk guidance provides an adversary and misuse perspective, including agent goal redirection, tool misuse, and identity or privilege abuse. [1] This supports the need for boundaries around what an agent may read and do; it does not provide a universal implementation checklist or a guarantee of risk reduction.

Microsoft’s published least-privilege pattern describes the need to define agent identity, permission scope, tools, and accountability before autonomy expands. [2] Its mechanisms and product examples have specific platform semantics, but the general architectural concern is portable: the task and agent should have a constrained authority envelope, rather than receiving all permissions of a broadly privileged technical account.

Google Cloud’s Secure AI Framework describes organizational policies, identity and access management, VPC service controls, and other configurable security features relevant to AI workloads. [3] Such controls address different layers of an application. A platform-level isolation or access feature does not automatically establish per-document user entitlements after content is copied into a separate search layer. The architecture must identify which component makes which decision.

NIST AI RMF defines Govern, Map, Measure, and Manage as four functions of risk management. [4] They are voluntary outcome categories, not a rigid software architecture. CyberTech Intelligence uses them to anchor responsibilities, test design, measures, and improvement. AWS documents account-level and organization-level Bedrock guardrail enforcement options with specific supported safeguards and exclusions. [5] Those controls can support content governance within their configured scope, not replace business authorization for all possible tool or data actions.

NIST SP 800-207 focuses on users, devices, and resources rather than granting implicit trust based on network location or ownership. [6] Its architecture principles were not written specifically for generative AI agents; they provide a useful basis for per-resource authorization reasoning. AWS Agent configuration guidance distinguishes selection of a service role and other agent setup controls. [7] Microsoft’s prompt-injection attack catalog describes direct and indirect manipulation paths where untrusted content may be interpreted as commands. [8] These sources support the separate design layers below.

Why Agent Data Security Needs Decision Rights

A connected agent can act at the intersection of several authorities. A business sponsor knows what the task should accomplish, a source owner knows who may use the documents, an identity administrator knows which technical role exists, and a security engineer knows how enforcement works. None of those roles alone can authorize every consequential data use. A workable architecture names who decides access, who configures it, who tests it, and who accepts temporary deviations.

A grant at the service level may allow the agent to query a knowledge base without establishing whether an individual user may see each returned passage. Equally, a user may be allowed to read a document without being permitted to send it to an outside recipient. Read, summarize, quote, write, export, and publish are distinguishable operations. Decision rights should reflect this separation and use stronger review where the possible business consequence is greater.

Agent identity must also have a lifecycle. When an agent is repurposed, receives a new plugin, changes source systems, or is retired, the permission model can change even if the model itself stays the same. Source permissions, delegated user context, technical role, tool grants, destination rules, and approval thresholds should be part of a single controlled change record. The reviewer’s task is to verify actual behavior after change rather than assuming a permission edit has covered every path.

Eight Operating Layers and Seven Control Questions

The CyberTech Intelligence Agent Data Boundary Framework consists of eight operating layers. At each layer, ask: Which task and requester are involved? What data or action is in scope? What evidence supports authorization? Which boundary narrows access? Who owns the decision? Which behavior is observed and tested? What event can revoke or reopen the decision? Answering those questions consistently is more valuable than adding a generic “secure by design” label to an untested workflow.

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

Operational Failure Scenarios

The following scenarios are illustrative control-design tests. They are not accounts of a named client incident or a claim that an identified platform has a particular vulnerability.

Scenario 1. The Agent Uses a Broad Service Identity

The business request is for approved team documents. The agent connector instead uses an account that can retrieve several departments’ restricted files. The control failure is not the mere existence of a service role; it is the absence of a trustworthy requester-specific data decision. Corrective design: require source-aware user authorization, restrict service reach where feasible, test a denied user and document, and retain an owner for the technical role.

Scenario 2. An Index Retains a Permission After the Source Changes

A source owner removes a person from a restricted document, but the retrieval index may still carry old permissions. The failure is stale or unverified authorization evidence. Corrective design: define permission update and invalidation behavior; test the denied request after a source change; and use an appropriate source-system check or synchronization process. Do not claim that all indexes have this defect; assess the configured freshness model.

Scenario 3. A Useful Summary Exposes Sensitive Combined Context

An agent combines a public company description with a restricted contract clause in one confident executive summary. The problem is not necessarily factual accuracy. It is unauthorized synthesis of data across sources whose audiences differ. Corrective design: classify the source passages, retain provenance, apply request-specific disclosure rules, and test mixed-authority questions. A summary to the authorized contract owner may be permitted while the same text for a general employee is not.

Scenario 4. A Retrieved Document Attempts to Redirect the Agent

An external file being summarized includes text instructing the agent to search for confidential information or send the answer elsewhere. Microsoft documents this kind of indirect prompt-injection mechanism. [8] Corrective design: treat the source text as data, constrain tools and destinations independently of model interpretation, and use safe adversarial fixtures to observe attempted retrieval and tool calls. A model refusal alone does not prove a complete technical boundary.

Scenario 5. A Content Guardrail Covers the Answer but Not the Tool

A configured response filter sees the final answer, while a connected tool sends structured information outside the response stream. The failure is treating one intervention point as coverage of every data path. Corrective design: enumerate input, output, memory, logs, tool arguments, tool responses, and destinations; state each filter’s coverage; enforce authorization and destination checks at the action layer. Guardrails may assist but do not universally replace such checks.

Scenario 6. An Agent’s New Tool Changes Its Authority

A team adds an action-capable connector to improve productivity. The tool can write records or send messages even though the original agent purpose was read-only. The concern is changed consequence without refreshed authorization. Corrective design: require a task-specific request, restrict enabled operations, validate target systems and recipients, route consequential actions to the right approver, and re-run tests before enabling the tool for general users.

Scenario 7. An Exception Outlives the Use Case

A temporary need for broad access is approved during rollout but never expires. The failure is not necessarily malicious behavior; it is loss of reviewability. Corrective design: record the exact scope, reason, approver, source data, permitted tools, expiry, compensating handling rules, and revocation route. Verify the change after the exception ends. A current exception register should support business continuity without normalizing permanent excess access.

Sample Agent Data Qualification Flow

1. Define the task: Is the use case bounded, with an approved audience, result, and source owner? Outcome: state what is in scope and which consequences require review.

2. Identify identities: Are requester, agent technical identity, and delegated authority known? Outcome: map who authenticates and which system authorizes each step.

3. Bound access: Which original documents, classes, records, and operations are permitted? Outcome: define source rules and a negative-case fixture.

4. Retrieve: How is verified requester permission carried into search, and how fresh is metadata? Outcome: test allowed and denied documents at query time, with platform limitations recorded.

5. Contain: Can untrusted content inside a document redirect the task or expand tools? Outcome: exercise controlled injection tests and record behavior across the context and tool chain.

6. Verify disclosure: Does the answer or downstream action stay within approved recipients and destinations? Outcome: test output, export, send, and write behavior independently.

7. Observe: Which privacy-aware logs, versions, owners, exception records, and source references make the result reviewable? Outcome: preserve only necessary evidence with restricted access.

8. Review and revoke: What change requires renewed approval and can permission removal be demonstrated? Outcome: retain, narrow, withdraw, or redesign with a verified closure record.

Governance and Decision Rights

Decision lane	Accountable role	Minimum evidence and exit decision
Agent scope	Business sponsor with data owner	Approved task, users, sources, outputs, consequence; authorize bounded use.
Identity and delegation	IAM/platform owner	Requester/agent identities, grants, token or role scope; validate narrow authority.
Source entitlement	Data owner and retrieval owner	Source permissions, classification, indexing rules, query-time tests; verify result scope.
Context and response	Application and security owner	Context classes, input and output checks, logging limits, negative test; protect permitted use.
Tools and destinations	Workflow owner and risk authority	Action grants, recipients, validation, explicit approval if needed; approve bounded action.
Exceptions and revocation	Risk owner with security operations	Owner, expiry, compensating control, rollback, retest; close or reapprove with evidence.

CyberTech Intelligence Agent Data Boundary Framework

The framework below is the canonical CTI operating synthesis for this campaign. Use it to reconcile policy with what an implementation actually does. No layer is automatically satisfied because a vendor offers a capability; it must be shown in the environment and reviewed within the product’s supported scope.