Stop an AI agent from reaching restricted data by enforcing permissions in the services that retrieve information, before content enters the model's context. Carry the requesting identity and tenant through each call, restrict returned fields, and apply the same boundaries to search, memory, caches, and logs. Instructions in a prompt are insufficient access controls.
Define the data boundary before choosing retrieval
A data boundary describes which principal may read which resource for which purpose. The principal might be a requesting employee or an explicitly configured service identity. The resource includes more than a document: individual fields, attachments, derived summaries, and the existence of a record can require protection.
Consider a hypothetical assistant preparing a supplier review. The requester can read delivery notes but cannot access confidential commercial negotiations. A broad search that retrieves both and asks the model to ignore the negotiation file has already crossed the intended boundary. Filtering the final answer cannot undo disclosure to the model or downstream processing systems.
Write the access rule at the point where data leaves its source. Decide which system owns the rule, how the connector receives identity, and what happens if permissions cannot be checked. A request with unresolved authority should stop rather than silently use a broad service account.
Keep identity attached to every retrieval
A connector should receive identity from trusted application context. A user-supplied tenant name or model-generated role is a search argument, never proof that access is permitted. Resolve organisation membership and resource entitlement in application or integration code before returning evidence.
The OWASP authorization guidance recommends denying access by default and validating permissions on every request. Applied to an agent workflow, this means that a successful initial login does not replace checks on later document, attachment, or record requests.
Keep source permissions authoritative where practical. If access rules are copied into a retrieval index, define how changes are propagated and how requests behave while that copy is stale. Removing a user from a source group should not leave an indefinite alternate reading route through the agent's knowledge store.
Make search obey the same rules as direct access
Search creates several places for information to escape. A title can reveal a confidential project. A snippet can expose a sensitive passage. A similarity result can disclose that a document exists even when its body remains hidden. Apply the relevant access rule to each part of the response.
Retrieval filters should narrow eligible records before restricted content is supplied to the model. When the search system cannot enforce the required document or field permissions, redesign the retrieval path or restrict the workflow. A prompt asking for discretion does not repair an index that mixes inaccessible material into the context.
Test direct record retrieval and broad semantic searches separately. A connector may correctly reject a forbidden identifier while a search endpoint still returns a passage from that record. Also test related-record expansion: following a link from a permitted purchase order must not automatically grant access to its restricted attachments.
Treat memory and caches as additional data stores
A conversation can outlive the permissions under which it began. If an employee changes teams, earlier retrieved material may still exist in saved messages or agent memory. Decide which retained content remains accessible, which requires renewed checks, and which should no longer enter future model calls.
Cache isolation needs the same attention. A result cached for a privileged requester should not be reused for another requester merely because the question matches. Cache keys and eligibility checks should account for the access context, while invalidation should respond to permission and source changes that affect correctness.
A generated summary is also derived data. Do not label it unrestricted because the original document is no longer attached. Preserve the source relationship and apply an appropriate access policy to summaries, embeddings, exported reports, and saved proposals that carry protected information.
Restrict fields and destinations deliberately
Access to a record does not necessarily imply a need for every field. A workflow checking delivery status may need an order reference and expected state, without personal contact details or internal negotiation notes. Define the connector's returned shape for the task instead of forwarding complete database objects.
Review where the permitted result goes next. The model endpoint, trace system, approval screen, support export, and analytics pipeline are distinct destinations with their own access and handling requirements. Redacting only the final response leaves earlier copies untouched. Remove unnecessary sensitive content before it reaches destinations that do not need it.
This is part of enterprise AI integration: the contract controls what may leave a source and who may receive it. The model's role is to interpret permitted evidence inside that contract, not to decide its own disclosure authority.
Separate evidence gathering from outward action
CodeDTX's Propose–Decide–Execute pattern lets agents prepare evidence-backed proposals while a named human decides and a separate executor carries out approved outward writes. That separation limits action authority, but it does not automatically secure reading. Read connectors still need explicit data scopes.
The approval interface must also respect information boundaries. An approver may be authorised to decide on a workflow without being entitled to every supporting document. Design the evidence view around the actual review role, and escalate when the person cannot access material needed to make a responsible decision.
Never solve that mismatch by putting confidential evidence into an unrestricted notification. A notification can identify a pending review and link to the protected application. The application can then resolve the reviewer's permissions and show the permitted decision context.
Prove denial paths with concrete fixtures
Create synthetic records that differ in tenant, owner, field sensitivity, and permission state. Ask the same question as different users and inspect the retrieved context, tool responses, visible answer, stored proposal, and trace. An answer that looks harmless is insufficient evidence if a forbidden passage entered the prompt.
Include an attachment containing instructions to search another tenant, a revoked user, a stale index entry, and a cache hit created by a different principal. Expected behaviour should name where the request is denied and what the user sees. Avoid error wording that confirms the existence of confidential records unnecessarily.
Keep those cases alongside agent evals, while testing the permission code independently. Model behaviour can change; resource authorization should remain enforceable even when the agent requests something outside its scope. Record denied attempts in a protected audit channel so operators can distinguish a confused request from a broken boundary.
Frequently asked questions
Is telling the agent not to reveal confidential data enough?
No. A prompt can describe expected behaviour, but it cannot enforce access to a database, document store, or retrieval index. Restrict information before it reaches the model, validate the requesting principal at the integration boundary, and prevent later copies in memory or logs from creating a route around the original permissions.
Can an agent use a shared service account?
It can use an explicitly governed service identity where the workflow requires that access, but sharing an account does not make every user entitled to its data. The integration must still enforce the requesting context and allowed scope. Avoid broad fallback credentials that turn a denied user request into a successful privileged lookup.
Do summaries need the same protection as source documents?
A summary may preserve sensitive facts even when it omits names or direct quotations. Treat it as derived information with a defined access policy and a traceable relationship to its sources. Review where it is stored, who can open it, and whether source permission changes should restrict its future use.
What should happen when access permissions cannot be verified?
Stop the affected retrieval and show a useful, non-disclosing explanation that the required access could not be established. Preserve enough protected diagnostic context for the integration owner to investigate. Do not broaden permissions, substitute an administrator identity, or let the model infer protected information from cached results while the check is unavailable.
