AI Assistants Must Enforce User Permissions, Not Service Account Privileges

Business Relationships Don't Equal Access Permissions

An ontology expresses relationships among products, warehouses, orders, and purchase orders, helping applications locate data. However, finding a relationship does not mean the caller may view the record at the other end. A purchaser who knows what "inventory allocation" means, can see which order consumes how much stock, and can modify that order are three separate capabilities. Knowing a concept does not grant query access to all its records; querying Warehouse 1 does not imply permission to create purchase orders.

For example, a purchaser may query their assigned warehouse, while a manager may approve purchases up to a certain amount. Both role, warehouse scope, and amount conditions exist. The ontology can capture these relationships and conditions, but query services, business procedures, and legacy systems must still enforce them — they cannot rely on the model to decide what not to say.

OWASP's Authorization Cheat Sheet recommends least privilege, deny by default, and validate permissions on every request. Applied here: grant only the permissions needed for the task; reject any request not explicitly allowed; do not allow subsequent queries just because the user once logged in. Reference:

https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

Concept, data access, and business operation managed separately; connected lines do not mean granted access.

Service Account Privileges ≠ User Permissions

Tools often call legacy systems using a single service account that may query all warehouses. Yet the purchaser is still responsible only for Warehouse 1. The integration must know on whose behalf it acts, then check what data and operations that identity is allowed.

This "who" must come from server-verified login or delegation information. A user ID filled in model parameters or a claim like "I am admin" in the conversation cannot serve as identity proof. Once identity is confirmed, permissions must be checked separately.

If the legacy system supports caller-identity or delegation checks, use them. If it only recognizes the service account, the integration layer must verify the caller's permissions, and all assistant calls must pass through it — no bypass by switching tools. The service account itself should only expose required interfaces and operations, never be handed directly to the model or client.

When creating a purchase order, the system must record who initiated, who approved, which service executed, and under which authorization. Logs showing only "Agent" make it impossible to trace decisions. A service account permitted to call an API cannot sign for a purchaser.

Warehouse parameters passed to query interfaces are also untrusted. Whether the user changes to Warehouse 2, the model fills the wrong warehouse, or a tool is called directly, the server must validate. Hiding options in the UI only reduces mistakes; it does not secure the interface.

Verify on whose behalf the action runs, then call per their permissions; do not expand scope via the service account. Diagram shows integration path when legacy system only recognizes the service account.

Don't Retrieve All Data Then Ask the Model to Keep Secrets

When querying inventory, the server must first restrict warehouses and returnable fields by the purchaser's permissions. It must not fetch all warehouses' stock, customer names, and order details, then ask the model to pick only the allowed parts.

Output filtering may be needed as a safeguard if source interfaces return extra fields. But output filtering cannot be the sole measure: once the model has read a customer name, later instructing it "don't say it" means the information has already entered the processing pipeline.

Caching follows the same rule. If an admin just queried Warehouse 2 stock, and a purchaser asks a similar question, the system must not reuse the admin's answer to save a query. Caches must retain data scope and access conditions; on read, verify the current user still has permission. Cache isolation cannot rely solely on textual similarity of questions.

Old sessions and long-term memory also require checks. If someone could query Warehouse 2 yesterday but had that permission revoked today, the application must not continue feeding restricted details or summaries from the old session to the model for new answers. This restriction applies to post-revocation reads; already-seen information cannot be recalled.

Audit logs themselves may contain prices, documents, and customer data. Logging calls is for accountability, not to let all developers read all business data. Collect logs on a need basis, restrict access and retention, and keep credentials out of ordinary logs.

Permission checks must limit data retrieval and historical content usage; output filtering is only supplementary. Revocation controls subsequent reads, not recall of already-viewed information.

Aggregated Outputs Can Also Leak Facts

The first article in this series discussed risks of composite queries. The same risk exists in warehouse queries.

Consider a different authorization: a user may see the total allocation in Warehouse 2 but not individual customer details. This differs from the purchaser who can only query Warehouse 1.

Suppose the user first learns total 6204 bearing allocation is 200 units, then queries "allocation excluding Customer A" and gets 180 units. If product, unit, timestamp, and all other conditions match, subtracting the two reveals Customer A's 20 units. No customer detail was returned, yet restricted information leaked.

Allowing aggregates may serve legitimate business needs. But when opening filter conditions, evaluate whether they enable isolating a single customer's data. Decide which conditions to block, how coarse the aggregation must be, and how to rate-limit consecutive queries based on data sensitivity. Merely hiding customer names or phrasing results in natural language does not prevent this subtraction inference.

Error messages must not leak extra information. If the existence of a purchase order is itself restricted, the error must not confirm the order exists, let alone explain which customer it belongs to.

Returning to the opening scenario: the assistant can still answer Warehouse 1 stock, explain that current permissions cannot verify other warehouses, and guide the purchaser to the authorized role for confirmation. Unauthorized queries must not be answered as "zero stock" or "no goods in other warehouses."

Details not directly returned may still be inferred via filter differences. Diagram uses an account allowed to see Warehouse 2 totals but not customer details to illustrate composite-query risk; it is not an example of permitted customer-allocation disclosure.

Switch Accounts, Change Parameters, Test Again

Start with the authorized Warehouse 1 purchaser testing normal queries, then change warehouse parameter, switch accounts, revoke permissions. Aggregation inference is tested separately with the aggregate-query account. The following checks are based on this example's authorization rules; real projects must substitute their own policies.

Authorized user queries Warehouse 1 bearings

Expected: Return allowed fields and sources normally

Where to check: Query service & source system

Same user changes to Warehouse 2

Expected: Reject over-privileged query; do not treat rejection as zero stock

Where to check: Server-side warehouse scope check & answer verification

Impersonate admin in conversation or tool parameters

Expected: Identity and permissions unchanged

Where to check: Login/delegation verification, server-side auth check

Can query but lacks create permission

Expected: Do not create purchase order even with complete parameters

Where to check: Action integration layer & original execution system

Initiator asks to approve own request

Expected: Reject per segregation-of-duties rule

Where to check: Original approval workflow

Use old session after permission revocation

Expected: New calls re-check; do not continue using old restricted content

Where to check: Session content read, query & execution services

Regular user hits high-privilege cache

Expected: Do not feed restricted results to model or return to user

Where to check: Cache read permission check

Infer customer data via filter differences

Expected: Restrict related queries and combinations per policy

Where to check: Metric or query service

Direct tool calls, task resumption, and scheduled jobs must all be tested — not just the chat UI. Scheduled jobs must clarify whose authorization they run under and whether it remains valid. Happy-path authorized samples must also pass: blocking all requests would equally prevent the purchaser from working.

The model may explain rejections or guide authorization requests, but the program must guarantee that switching tools cannot bypass the same restriction. Permission expansion must follow formal management processes; a chat promise cannot make it effective.

Test chat, direct tool calls, and scheduled jobs: authorized actions succeed, over-privileged are rejected. Diagram lists test requirements; actual results must be recorded.

Summary

When the purchaser asks "can we transfer from other warehouses?", the assistant can help find the application channel. Whether to check stock first or apply directly, both must follow the purchaser's permissions — not borrow the service account to scan all warehouses.

After switching the query entry to chat, these checks cannot be omitted. If unauthorized, say so; let the authorized person handle next steps. Do not peek via the service account, and do not fill unqueryable stock as zero just to give a complete answer.

Permission checks pass, the call is made — can the assistant then say "done"? The next article examines how to confirm the actual purchase order result.

References

OWASP, Authorization Cheat Sheet, Least Privilege, Deny by Default, Validate the Permissions on Every Request. Used to illustrate server-side authorization principles; this article's warehouse scope, segregation of duties, and test matrix are designed for a hypothetical project. URL:

https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html