Bound Context and Writes in Enterprise AI Agents

An internal AI agent should not decide who may see information or authorize a consequential change. Put two controls outside the model: enforce permissions before retrieval so only authorized material enters its context, and route consequential writes through a proposed-change plan that a person reviews and explicitly approves before execution.

This pattern is not a substitute for a sound identity, permission, or change-management system. It gives the model a bounded role: searching within authorized limits, synthesizing material it is allowed to receive, and preparing concrete changes for accountable people to assess.

Context is the text, records, tool results, and instructions available to a language model for a task. Once material is in context, the model can use it in a response or proposed action. Access therefore needs to be determined before the model sees the material—not left to the model to infer from social circumstances.

Use a policy gate for reads and a human gate for writes

A practical flow is:

User request
  → authenticated request context
  → policy enforcement point
  → permission-filtered retrieval
  → agent working context
  → proposed-change plan
  → human review and explicit approval
  → narrowly scoped write executor
  → audit record

A policy enforcement point is a service or layer that applies authorization rules at a protected-system boundary. It receives an authenticated request context—such as the requesting user, their role or attributes, the relevant workspace or project, and the requested operation—and returns only records and fields that policy permits.

The important design choice is that the agent uses a retrieval interface that has already applied those checks. It should not receive a broad corpus and classify passages as shareable. Likewise, it should not have a tool that effectively says, “retrieve anything, then decide whether to disclose it.” The model may help interpret a request, but it should not establish eligibility for protected data.

For writes, the agent produces a structured proposal rather than calling a general mutation tool directly. A person reviews the requested changes, affected records, operations, rationale, assumptions, and validation results, then takes a separate approval action. A deterministic executor performs only the approved, bounded operation.

These controls address different risks. Read controls limit what the agent knows in an interaction. Write controls make consequential changes visible and attributable before they take effect.

Treat authorization as part of context construction

People often use social context when deciding whether to repeat information: who asked, where a conversation occurs, who else can see it, and whether the material is privileged or sensitive. Agents do not reliably apply those human judgments. Privileged information can therefore reach contexts where it should not be.

The architectural response is not simply a stronger instruction to the model. Make the context builder permission-aware. A context builder is the component that selects and packages material for the model. It should retrieve only material the policy layer has authorized for the specific request.

Bind retrieval to explicit inputs

Authorization decisions should be explicit and structured. At minimum, bind retrieval to:

• Principal: The human or service identity on whose behalf the request runs.
• Tenant or workspace: The organizational boundary relevant to the request.
• Conversation or channel scope: Where the result will appear and who can receive it.
• Resource and field: The requested document, record, attachment, or individual attribute.
• Operation: Usually read for retrieval, rather than a vague catch-all permission.
• Purpose or task context, where supported: A bounded reason for access that policy can evaluate consistently.

The agent may formulate search queries, but the retrieval service should apply these inputs before returning candidates. Semantic indexes, caches, summary stores, and embedding stores belong within the same authorization boundary. Otherwise, a protected source system may be undermined by a less protected derivative store.

A useful rule is: every route by which text can enter model context needs an authorization story. That includes direct lookups, search results, snippets, conversation history, uploaded files, cached results, generated summaries, and tool output.

Preserve provenance and delivery scope

Attach machine-readable provenance to each retrieved item where feasible: its resource identifier, source system, the policy decision or scope that admitted it, and the recipient context for which it was retrieved. This metadata need not be displayed to an end user, but it can help the orchestrator avoid mixing material retrieved for one scope into another.

For example, a request in a shared channel should be evaluated against that channel’s permitted audience, not only the identity of the person who entered the prompt. Retrieving material for a requester and posting it into a broader setting crosses a second disclosure boundary. The policy layer should evaluate the delivery context, or the application should decline to place sensitive results in a scope it cannot represent.

Govern summaries and memory as derived data

Summaries, extracted facts, and agent-maintained memory may appear less sensitive than their sources, but they can preserve sensitive content while making its origin less visible. Treat derived knowledge as governed data:

1. Record the sources and scopes used to create it.
2. Assign a visibility rule no broader than the rules applicable to its inputs, unless an authorized process deliberately changes that classification.
3. Apply permission checks again when retrieving the derivative artifact.
4. Expire, recompute, or review stored summaries when source permissions change.

This may reduce recall where authorization metadata is incomplete or systems use incompatible permission models. That trade-off is real: a shared agent is only as broadly useful as the information it can validly receive. Improving permissions and resource taxonomy is generally a better response than allowing the model to bridge gaps through intuition.

Make writes proposed changes, not model decisions

A consequential write is a mutation that changes an authoritative record, affects another person’s work, alters access, sends an external communication, or has a meaningful operational effect. The threshold should be defined outside the model.

In this pattern, the agent can analyze data and prepare a plan, while a human decides whether it should happen. The plan should be structured enough that review concerns a concrete diff rather than a persuasive narrative.

Include the information needed for review

A proposed-change plan should contain the following:

For bulk work, reviewers need both aggregation and drill-down. A summary can show counts by operation, affected categories, and exceptions, while individual changes and representative samples remain inspectable. A plan that only says “update 500 records” asks for trust rather than enabling review.

The write executor should accept an immutable approved plan, not free-form instructions from the model. It should verify that approval applies to the submitted plan version, has not expired, and covers every operation. It should also re-check relevant preconditions before each change. If a record has changed since review, the executor should stop that item or require a new proposal rather than guess how to merge it.

Enforce separation through credentials and interfaces

The separation should exist in credentials and interfaces, not only as a user-interface convention. The agent can be given the capability to create proposals without a standing credential for production mutations. The execution service holds the write capability and invokes it only after validating an explicit approval artifact.

This boundary is testable:

• Can the agent retrieve a protected record without an authorized principal and recipient scope? It should not.
• Can the agent mutate an authoritative system using only its runtime credentials? It should not.
• Can an approved plan be changed between review and execution? The executor should reject it.
• Can a person approve broad intent without seeing the actual diff? The workflow should not treat that as approval of specific changes.

Make review a meaningful control

Human approval is not automatically protective. As confidence in an agent grows, reviewers may begin rubber-stamping proposed changes. Review is meaningful only when the workflow helps a reviewer exercise judgment.

Recommendations for resisting superficial approval include:

• Show material changes clearly. Present before-and-after values, not only a prose description.
• Surface uncertainty and exceptions. Do not bury low-confidence items in an otherwise successful batch.
• Route by risk. Apply more deliberate review to higher-impact, unusually large, or policy-sensitive changes.
• Constrain batches. Smaller, coherent batches make systematic errors easier to detect.
• Require active acknowledgment for defined risks. Approval can require confirmation that flagged deletions or access-related changes were examined.
• Sample and audit completed changes. Check whether approved plans were accurate and whether reviewers are disregarding warnings.
• Capture rejection reasons. Use them to improve instructions, validation, or data quality without treating feedback as automatic authorization.

These measures add friction, and a strict proposal schema can slow simple work. But autonomous consequential writes remove the moment when a responsible person can inspect and challenge the agent’s interpretation. Teams may tune review by impact, but should do so through explicit policy rather than gradually ignored prompts and habitual clicks.

Implementation checklist

Read boundary

• [ ] Each request is tied to an authenticated principal and defined recipient or conversation scope.
• [ ] Retrieval enforces authorization before returning documents, records, fields, snippets, or tool results to the agent.
• [ ] Search indexes, caches, conversation history, and summaries follow equivalent permission checks.
• [ ] The agent cannot broaden access by selecting a different identity, workspace, or recipient scope.
• [ ] Retrieved items retain provenance and scope metadata through context assembly.
• [ ] Derived memory and summaries are governed as data when later retrieved.
• [ ] Policy-denied material is not sent to the model for redaction or judgment.

Write boundary

• [ ] Consequential write categories are defined outside the model.
• [ ] The agent produces a versioned proposed-change plan with explicit diffs, scope, preconditions, exceptions, and validation.
• [ ] The agent lacks direct production-mutation credentials.
• [ ] A human approves the exact plan version through a separate action.
• [ ] The executor verifies approval, scope, expiry, and current-state preconditions before mutation.
• [ ] Execution logs connect the request, retrieved basis, plan, approver, result, and failures.
• [ ] Review screens surface high-impact changes and uncertainty rather than optimizing only for rapid approval.

The central principle is straightforward: let the agent reason and propose within boundaries established by systems and accountable people. Authorization belongs at the retrieval boundary, where protected information is selected. Accountability for consequential mutations belongs at the approval boundary, where a person can inspect a concrete plan before anything changes.