The Enterprise AI Trust Boundary Field Guide

Executive Brief

An AI application is not defined only by its model. It is also defined by the data it reads, the connected services it can invoke, and the decision rules that apply before it changes a business system. Prompt injection becomes important at the point where content that should be treated as information is interpreted as an instruction to change the task or take an unauthorized action.

This field guide helps a team document one enterprise AI workflow and make those distinctions visible. It does not assume that malicious instructions have entered a particular business environment. It uses a bounded self-assessment to organize questions, evidence, and responsible owners before and after deployment.

Microsoft describes Prompt Shields for user-input and document-borne attacks and explains that configured intervention points matter. [1] A shield may identify an attempted manipulation, but an application still needs permission checks, restricted tools, and accountable business decisions. The exercises below do not certify a product or demonstrate the completeness of a vendor's defenses.

How to Use This Field Guide

Choose an AI workflow that can be described without customer secrets. It could summarize support tickets, prepare an internal sales brief, search policy materials, or propose a change for a staff member to approve. Assign a Business Owner, Application Owner, Security Reviewer, and Data Owner. One person can hold more than one role, but each decision needs an accountable name.

Complete the worksheets in order. Record a verified answer, a supplier description, or an explicit unknown. Do not convert an unknown to a pass because the application behaved correctly once. After each section, identify the smallest next action that improves evidence. The purpose is a useful working record rather than a long form completed from memory.

Worksheet 1: Define the Approved Task

Describe the output the organization wants and the actions it does not authorize. A help-desk assistant that drafts ticket summaries is different from one that closes tickets, issues refunds, or changes access rights. A workflow should have a clear boundary even when the business goal seems routine.

Record the initiating user, the information needed, the expected response, any consequential system changes, and who can approve them. When a tool changes records, identify what the user must see before confirming the operation. If the assistant only drafts a response, make sure the technical permission set does not silently include a send action.

Practice question: If the assistant receives a sentence in a document that conflicts with the user's request, which system rule makes the document sentence non-authoritative? The correct answer should identify an application control or review process, not simply the hope that the model ignores it.

Worksheet 2: Map Untrusted Information

Draw the route by which content enters the assistant. Start with the user's direct request. Add document repositories, search indexes, email bodies, web pages, APIs, partner feeds, uploaded files, and tool responses. Mark who can write to each source. The objective is to see where a person outside the authorization chain could influence a later model response.

Classify a source as internal does not settle trust. A shared drive may accept vendor uploads. A corporate ticket system may contain unreviewed customer descriptions. A search index may mix public material with restricted records. Record the real edit and read rules, not the familiarity of the platform logo.

For each source, document whether content is quoted as evidence, summarized into an answer, or passed onward to a tool. The last case often merits closer attention because a harmless-looking sentence may become part of a subsequent action request. OWASP's agentic-security work describes risk categories where agent context and task control intersect. [4]

Do this next: Select the two sources with the broadest editing rights and write a test question that would cause the assistant to read them. Avoid production changes until the test and record-retention approach are approved.

Worksheet 3: Inventory Tool Authority

List every function the application can call. Separate read functions from write functions and any action that sends information outside the enterprise. Record the service identity, effective access scope, whether authority is delegated from a user, and whether an approval happens before execution.

Microsoft recommends unique agent identities, narrowly scoped permissions, and explicit checks of tool and downstream resource rights. [5] This supports a practical principle: An AI system should not gain a wider combined permission set merely because several connectors are individually considered low risk.

Ask whether the assistant has unused actions available from an earlier trial. Remove permissions that are not required for the approved task. For necessary write functions, define allowed records, required fields, recipient restrictions, and an independent policy check where consequences are material.

Do this next: Create a one-page effective-permission inventory and have the Application Owner compare it with the approved business task. Record any access that cannot be explained by a current need.

Worksheet 4: Apply Retrieval Permissions

A retrieval service is supposed to find relevant information, but relevance is not authorization. If a user is not entitled to read a document, it should not become accessible because the user asked an AI assistant a general question. Microsoft describes document-level access mechanisms and query-time security filters for Azure AI Search. [2]

Record which identity is used to perform each query. Determine whether source permissions are copied to the search index and enforced when results are returned. Examine how changes to employee groups, partner access, or document classification are reflected. A valid record should show the search scope, source permissions, and authorized result set.

The exercise must avoid exposing real sensitive information. Create a synthetic document that only a test identity may read and verify the result with different identities. If results are unexpected, the finding is a permission or indexing issue to investigate. It is not automatically evidence that an external attacker has exploited the system.

Worksheet 5: Design Controlled Tests

Create a small test set before comparing defenses. Include a normal summarization request, an irrelevant instruction inside a retrieved passage, a request for an unauthorized document, an attempted high-impact tool action, and a case requiring human review. Define the expected result before the test runs.

Google Cloud describes configurable prompt and response screening in Model Armor. [3] That documentation shows what a particular product offers, not that a given organization's deployment is protected. Record which filter, policy, and model configuration were actually active, together with any false positive or missed case observed during a bounded test.

A result is meaningful only within its test boundary. Five successful checks do not mean a system is immune to prompt injection. Add cases when a new connector, high-risk action, or external data feed becomes material. If testing reveals unexpected behavior, route the issue to the named Application Owner and document a proportionate remediation decision.

Worksheet 6: Translate Evidence Into Buyer Value

For a cybersecurity vendor, the product description should tell a buyer which boundary a capability addresses. An attack detector may flag suspicious content. A data-access product may restrict what a retrieval system returns. A governance product may inventory connected tools. Those are different jobs, and an effective buyer explanation should state the scope, prerequisites, and observable evidence.

CyberTech Intelligence describes research-led content programs tailored to distinct cybersecurity buying roles. [6] Buyer intelligence can help a vendor distinguish executive governance questions from technical enforcement questions. Managed demand generation can provide a concise worksheet or explanatory briefing to each role. Pipeline activation should begin only when a person confirms a current need and agrees to a relevant next step.

Rewrite broad claims into inspectable statements. "Protects all enterprise agents" is much wider than "The configured workflow checks these tool actions before execution." The latter can be assessed against a documented environment. If a capability requires special integration or customer policy configuration, include that condition in the buyer explanation.

Eleven-Domain Readiness Self-Check

Score each domain from 0 to 4 using records from the selected application. Zero means no identifiable owner or evidence; one means informal awareness; two means a documented procedure; three means a version- or workflow-specific record reviewed by an owner; and four means the control has been exercised or independently checked within a defined boundary. This self-check is an internal prioritization aid, not a security certification.

The total possible score is 44. Keep the component scores visible; a high total can mask an important zero in tool authorization. A team should never assign a four solely because a product brochure lists a control. The relevant check must have been performed and retained for the reviewed workflow.

Ninety-Day Improvement Planner

Days 1–30: Select one consequential workflow, assign owners, complete the task and source maps, and confirm the current tool list. Establish a baseline that distinguishes verified configuration from assumptions. Prioritize the two boundaries where a wrong action could have the greatest business consequence.

Days 31–60: Narrow excess permissions, test retrieval access using synthetic records, and introduce explicit checks for material tool actions. Establish source-change tracking and agree on the logs needed for a later investigation. Repeat the controlled test set after meaningful changes.

Days 61–90: Run an approval-and-revocation exercise, review exceptions with the business owner, and prepare a short buyer-facing explanation of what the application can demonstrate. Refresh the scorecard from actual evidence; do not assign improvements simply because a workstream was scheduled.

CyberTech Intelligence Perspective

The practical value of this field guide is to make an emerging security topic actionable without claiming that every enterprise has an exposed assistant. CyberTech Intelligence can support security vendors through buyer intelligence, managed demand generation, and pipeline activation programs that follow real questions from evaluation teams. The strongest content offers a useful decision aid first and a commercial conversation only when the reader signals relevant business interest.

A vendor can adapt these worksheets into an engineering briefing, an executive decision guide, or an account-specific discussion agenda. The underlying claims should remain limited to the actual product and test evidence available. A worksheet completion is not a qualified opportunity; it is a way to discover which question the buyer might need answered next.

A Worked Example: A Policy-Search Assistant

Consider a hypothetical employee assistant that summarizes internal travel rules. Its business task is to answer policy questions, not approve reimbursements. The approved sources are the current travel policy and an archived guidance folder. The assistant uses a document search service and has no reason to invoke a payment or email-sending tool. That narrow design creates a clear basis for an evaluation.

The team creates a synthetic policy paragraph containing a sentence that asks the assistant to modify a payroll record. The expected outcome is that the assistant treats the sentence as part of an untrusted document and does not propose a payroll change. The source record should show how the paragraph entered the search result. The action record should establish that payroll tools were unavailable or independently prohibited.

Now imagine an authorized user asks a genuine question about a policy exception. The application can retrieve the relevant approved rule and provide a summary without gaining permission to approve the exception. If management later wants automated reimbursement approval, that would be a new business task requiring explicit permissions, action tests, and a different approval route.

This illustrates why the worksheet sequence matters. The right answer is not merely to detect a suspicious sentence. The stronger design limits which sources can influence the response, which records a user can access, what tools exist, and who may approve an action. A future review can repeat the same exercise after adding a new document collection or service integration.

Preparing a Compact Evidence Packet

After completing the worksheets, prepare a two-page evidence packet. Page one describes the approved task, the source map, and the effective permissions. Page two summarizes a handful of executed tests, any accepted limitations, and the response owner. Include dates and workflow identifiers so another reviewer can understand what was checked.

Do not attach full customer conversations or unnecessary personal data. A synthetic test set and a clear description of the operating environment are often more suitable for internal training and cross-functional review. For external buyer discussions, use a sanitized sample and distinguish product capabilities from tests performed in a particular customer environment.

NEXT STEP

References and Source Boundaries

Numbered references identify the primary publisher evidence used for the nearby factual statement. Standards, technical documentation, and reported threat observations do not establish the security condition of a named prospect or guarantee vendor performance or commercial results. Source review date: October 30, 2026.

1. Microsoft Learn. Prompt Shields in Microsoft Foundry. Use in this asset: User versus document attacks, intervention points and configured filtering. URL: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/content-filter-prompt-shields 
2. Microsoft Learn. Best Practices for Security in Azure AI Search. Use in this asset: Document-level access rules and query-time permission checks. URL: https://learn.microsoft.com/en-us/azure/search/search-security-best-practices 
3. Google Cloud. Model Armor Overview. Use in this asset: Prompt and response screening capabilities and operational limitations. URL: https://docs.cloud.google.com/model-armor/overview 
4. OWASP Gen AI Security Project. Agentic Security Initiative. Use in this asset: 2026 agentic risk categories and control themes. URL: https://genai.owasp.org/initiatives/agentic-security-initiative/ 
5. Microsoft Learn. Least Privilege for AI Agents. Use in this asset: Agent identities, scoped tools, time-limited rights and auditability. URL: https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents 
6. CyberTech Intelligence. Targeted Cybersecurity Content Programs. Use in this asset: CTI stated research-led content and buying-role education programs. URL: https://cybertechintelligence.com/services/targeted-content