CH16-04: Retrieval, Tool Use, and Authorization Boundaries

Goal

Assistants are powerful because they can combine language, retrieval, and tools. They are risky for the same reason. A model may answer from retrieved content, summarize customer history, draft seller guidance, or call an API. If authorization is weak, the assistant can cross boundaries faster than a normal screen would.

This section applies Chapter 14's agentic controls to e-commerce roles: customer, seller, support agent, employee, and internal operator.

The durable idea is:

AI does not erase authorization boundaries; it makes them easier to cross accidentally.

The Short Version

The easy question is:

Can the assistant answer this question or call this tool?

The better architecture question is:

Is the current user allowed to see the retrieved source and perform the requested action?

Retrieval and tool use need the same authorization discipline as normal application features.

Role Contexts

Different users see different parts of the commerce platform:

Role	Can Usually See	Must Not See
Customer	Own orders, own profile, public product data, approved support guidance.	Other customers' orders, seller private data, internal fraud notes, support-only policy.
Seller	Own listings, own orders, seller policies, seller support cases.	Other sellers' data, private customer data beyond allowed fulfillment context.
Support agent	Assigned customer cases, policy docs, relevant order context.	Unassigned or unnecessary customer data, internal secrets, unrelated seller data.
Employee or operator	Internal operational data for their role.	Data outside their job scope or regulatory boundary.
AI application identity	Only the APIs and stores required for its workload.	Broad owner-level access or unrestricted database access.

The assistant should inherit or enforce these boundaries. It should not become a shortcut around the application security model.

Authorization-Aware Retrieval

Retrieval-augmented generation means the system retrieves relevant content before asking a model to answer. In commerce, retrieved content may include product descriptions, seller policies, refund rules, support articles, order summaries, or internal troubleshooting guides.

A safe retrieval design includes:

Metadata filters for tenant, seller, customer, region, policy version, content type, and sensitivity.
Source visibility rules so only authorized documents are retrieved.
Freshness rules for policy, catalog, and support content.
Citations or source references where users need evidence.
Index ownership and update processes.
Tests that prove one user cannot retrieve another user's content.

One large knowledge index with no permission model is usually not enough. The design can use separate indexes, filtered indexes, document-level metadata, or application-enforced filtering depending on the platform and requirements. The key is that retrieval must be permission-aware before the model sees the content.

Tool Use Boundaries

Tool use lets an assistant call APIs or functions. In e-commerce, possible tools include:

Look up order status.
Create a refund request.
Draft a seller support response.
Update a product listing draft.
Check inventory availability.
Open a customer service workflow.
Escalate a fraud or abuse case.

Tools should be behind a controlled layer:

User role and request
	-> assistant orchestration
	-> authorized retrieval
	-> model response
	-> validated tool layer
	-> enterprise API
	-> audit log and outcome

The model should not call broad internal APIs directly. The tool layer should validate inputs, enforce authorization, apply business rules, log requests and outcomes, and require approval for sensitive actions.

Delegated User Context Versus Application Identity

There are two common identity patterns:

Pattern	Meaning	Risk to Manage
Delegated user context	The assistant acts with the current user's permissions.	The app must preserve user context and avoid privilege expansion.
Managed application identity	The assistant service uses its own managed identity to access resources.	The service must enforce user-level authorization before returning or acting on data.

Managed identities are useful because they avoid storing credentials. They do not automatically solve user authorization. If a managed identity can read all order records, the application still needs to filter results by what the current user is allowed to see.

Actions That Need Extra Control

Some assistant actions should require validation, human approval, or policy checks:

Issuing refunds or credits.
Changing seller listings that affect public product pages.
Updating customer addresses or account details.
Escalating fraud decisions.
Sending customer-facing messages.
Accessing sensitive customer or payment-adjacent information.
Changing policy or knowledge-base content.

The assistant may draft, summarize, or recommend, but final execution may need a user confirmation, support-agent approval, or workflow checkpoint.

Example: Support Agent Assistant

A support agent assistant can summarize an order and suggest a refund workflow. It retrieves approved refund policy, order status, shipping events, and prior support interactions for the assigned case.

It should not expose another customer's data. It should not approve a refund beyond policy limits without validation. It should not invent policy. It should log the retrieved sources, the generated recommendation, the tool call request, the agent approval, and the final API outcome.

That audit trail matters because customer support decisions affect trust, money, and policy compliance.

Refusal and Escalation

A well-designed assistant needs safe refusal and escalation paths.

It should refuse or escalate when:

The user asks for data they are not allowed to see.
Retrieved sources conflict or are stale.
The requested action is high impact or outside policy.
The model has low confidence.
A tool call fails validation.
Safety checks detect harmful or policy-violating content.

Refusal is not a failure of the assistant. It is part of controlled architecture.

Common Mistakes

Building one knowledge index with no permission model.
Letting the model call broad internal APIs directly.
Forgetting that seller, customer, support, and employee data have different access rules.
Using a powerful managed identity without enforcing user-level authorization.
Logging sensitive prompts, retrieved content, or tool results without governance.

If Someone Asks You

How do you keep AI assistants from crossing commerce data boundaries?

A good answer is:

I preserve the user's authorization context through retrieval and tool use. Retrieval indexes need metadata filters, source visibility rules, freshness controls, and tests that prove users cannot retrieve unauthorized content. Tool calls should go through a validated layer that enforces authorization, business rules, approvals, audit logging, and safe refusal. Managed identities help the service access Azure resources, but the application still has to enforce what the current customer, seller, support agent, or employee is allowed to see and do.

What You Should Remember

Retrieval and tools need the same authorization discipline as normal application features.

Questions to Check Understanding

Why is application access not enough for user-specific retrieval?
Which commerce tool calls should require extra validation?
What evidence should be logged for assistant actions?