Your AI Agent Doesn't Need More Context. It Needs the Right Context.
Context Engineering: The emerging discipline of designing what AI systems need to know.
11 November 2026 | AI Engineering | Context Engineering
One development. One insight. One action.
1. NOW — What's Changing?
AI engineering is moving beyond the design of prompts toward the broader discipline of context engineering.
Prompt engineering focuses on how we formulate instructions. Context engineering considers the information and operational environment available to the model when it performs a task.
This can include:
System and developer instructions
User requests and task requirements
Retrieved documents and knowledge
Tool definitions and tool responses
Conversation history and memory
Intermediate results from earlier steps
In July 2026, Anthropic described a substantial reduction in the system-prompt material used with newer-generation Claude Code models. The announcement illustrates a broader engineering lesson: more context is not automatically better context.
The central question becomes:
What is the minimum sufficient context that enables an AI system to accomplish its task reliably?
This is not simply a question of reducing tokens. It is a question of relevance, accuracy, timing, structure, and task requirements.
Modern AI systems can accept large amounts of information. However, a larger context window does not guarantee better results.
An agent may receive:
Outdated instructions that conflict with current requirements
Documents unrelated to the task
Duplicated information
Tool descriptions it does not need
Long histories containing irrelevant intermediate work
These additions can increase processing costs and make it harder to identify the information that matters.
Three engineering consequences
1. Reliability: The agent must distinguish authoritative information from irrelevant or conflicting material.
2. Efficiency: Unnecessary context consumes input tokens and can increase processing time and cost.
3. Maintainability: A clearly designed context pipeline is easier to inspect, test, and improve than an unstructured collection of prompts and documents.
Context engineering therefore becomes part of system architecture—not merely prompt writing.
This development connects naturally to an existing case in the The Effective AI Engineer learning series:
CONNECTED CASE STUDY
Case #004 — The Engineer Who Chose the Constraint
Effective engineering is not always about removing limitations. Sometimes the right constraint forces better design decisions.
Context engineering offers a practical application of this idea.
Instead of asking, “How much information can the agent accept?” the engineer asks, “What information is necessary to accomplish this task?”
Learning connection: Use constraints deliberately, then test whether they improve engineering outcomes.
Explore the Effective AI Engineer case-study series and course through AIYING's learning resources.
This connection is an educational interpretation of the case's engineering principle, rather than a claim that the original case was specifically about context engineering.
Challenge: Design the context strategy for an AI agent that analyzes project documents.
Prepare a one-page design containing:
Always include: Essential instructions, current task, and output requirements.
Retrieve on demand: Supporting documents needed to answer particular questions.
Exclude by default: Duplicated, obsolete, or unrelated material.
Verify: A test that detects whether important information has been omitted.
Measure: Accuracy, unsupported claims, token usage, and completion time.
Suggested deliverable
Context category
Decision
Reason
Task instructions
Always include
Defines success
Current risk register
Always include
Primary evidence
Historical meeting notes
Retrieve as needed
Supports investigation
Obsolete project drafts
Exclude by default
May create conflicts
Completion criterion: Explain why each category belongs in its chosen group, and demonstrate that the resulting agent can still satisfy the task requirements.
Portfolio artifact: A context-budget design note and a two-run evaluation scorecard.
The document-analysis scenario, comparison exercise, scorecard, and course assignment are original educational applications developed for AIYING. They are not experimental findings reported by Anthropic.
By Ravindra Dastikop
AIYING — Accomplishing with AI
The agent had saved its progress. Had the organisation preserved its permission to continue?
1. The current engineering challenge
AI agents increasingly perform work in the background while a user continues
the conversation, changes requirements or starts another task.
LangChain’s
Agents Are Going Async,
published on 5 November 2026, describes an architecture in which a user-facing
orchestrator stays available while background subagents work independently.
It also discusses task updates, cancellation and approval handling.
The article identifies task notifications as beta functionality.
[1]
That architecture creates a practical design question:
When a background agent resumes, how does it establish that its next action
still matches the user’s current intent?
This case focuses on changing instructions and the validity of an approved action.
Reliable execution must account for what happened while the worker was waiting.
CedarWorks Services coordinated equipment maintenance across several offices.
Its operations team spent substantial time finding technicians, checking access
windows and preparing appointment confirmations.
Meera, an AI engineer, built an assistant that could read a maintenance request,
research providers, compare appointments, prepare a booking and ask a supervisor
for approval. Following approval, it could submit the booking through a vendor API.
Initially, the assistant handled one request at a time. A slow provider search
left the supervisor waiting.
The team introduced background workers. The supervisor could now continue working
while the assistant searched for appointments.
During demonstrations, the improvement was obvious. The assistant stayed responsive.
Several searches could progress independently.
Then Meera tested what happened when a request changed while a worker was waiting.
“Arrange maintenance for the cooling unit at the North office on Friday morning.
Prepare the booking for approval.”
The assistant created request version 1.
A worker found a technician and prepared a booking. The supervisor approved it,
but submission remained queued.
Before submission began, the facilities manager reported that the North office
would be inaccessible on Friday.
The supervisor told the assistant:
“Change it to the South office on Monday afternoon.
Keep the same maintenance scope.”
The conversational assistant acknowledged the change.
However, the queued worker still held the earlier approved action.
When it resumed, it was ready to book the North office for Friday.
Its stored information appeared consistent: a request existed, a provider had
been selected, approval had been recorded and submission remained incomplete.
But those records described an instruction the user had replaced.
“The supervisor already approved the maintenance.
We should avoid asking again.”
The operations lead disagreed:
“I approved a specific visit. The location and time were part of that decision.”
Meera considered three options.
Option
Benefit
Limitation
Resume the previously approved booking.
Fast; uses existing approval.
Acts on superseded instructions.
Replace booking details and reuse approval.
Avoids another approval request.
Changes what the supervisor reviewed.
Retain useful research, invalidate the old action and review the revised proposal.
Preserves useful work and respects the change.
Requires explicit version and approval handling.
Stopping every worker whenever any message arrived was another possibility.
However, an unrelated question should not necessarily invalidate maintenance work.
Pause and decide
What should happen to the queued booking, the earlier approval and the provider
research? Define your answer before reading the worked analysis.
LangGraph’s interrupt documentation explains that an interrupt saves graph state
and waits for input. Its documentation also explains that resuming an interrupted
node restarts that node from its beginning, making the treatment of side effects
important. Code executed before the interrupt must be safe to repeat.
[2]
Persistence and checkpoints support retaining execution state and recovering
workflow progress. [3]
The application-level inference: the system must additionally
establish whether the proposed action remains valid under current instructions.
A persisted approval record alone cannot answer that business question.
The sources support the technical context. The fictional incident and the
following control design are teaching constructions.
Meera chose to retain useful research while invalidating the old proposal and approval.
She separated three concepts:
Research: information collected while preparing an action.
Proposal: the exact action presented for review.
Authority: permission to execute that proposal under stated conditions.
Changing the office and appointment window invalidated the booking proposal.
In this application, the approval covered those details, so it also became unusable.
Some provider research could remain useful. A provider’s service coverage might
still apply, while its Friday availability would require another check.
The system marked the first proposal as superseded, prevented it
from reaching submission and prepared a replacement.
The supervisor could then receive this message:
“The earlier booking has not been submitted. Your change replaces the approved
location and appointment window. I am preparing a revised proposal for review.”
That wording is appropriate only after the system has established that submission
has not occurred.
For CedarWorks, an approval should identify what the person reviewed and the
conditions under which it may be used.
Field
Purpose
Task ID
Identifies the maintenance workflow.
Request version
Identifies the applicable instruction.
Proposal ID and version
Identifies the reviewed action.
Action details or digest
Binds approval to particular booking content.
Approver identity and authority
Establishes who approved and whether they could approve.
Approval time and validity conditions
Defines when approval may be used.
Approval status
Records approved, revoked, expired, superseded or consumed.
A digest can bind a record to particular content. It does not establish that the
content is correct or authorised.
CedarWorks required renewed approval for changes to location, appointment window,
provider or maintenance scope. Another application might permit a bounded range
of choices, provided those boundaries were explicit when the person approved.
Immediately before booking, the execution service should establish that:
The task remains active.
The proposal belongs to the current applicable request version.
The approval covers that proposal.
The approval remains valid.
Relevant availability and access conditions remain acceptable.
The booking has not already been submitted.
The check and the transition into submission must be coordinated.
Otherwise, an update could arrive after validation but before the external call.
One implementation could use a conditional database transition that permits
submission only while the expected task version remains current.
A prompt asking the model to “check the latest instructions” can support reasoning,
but consequential execution should also enforce the relevant conditions in
application logic.
How will two workers be prevented from submitting competing proposals?
What happens when cancellation races with submission?
What evidence explains the final action to the supervisor?
Submit:
A task state table.
An example approval record.
Five failure scenarios and expected outcomes.
A short explanation suitable for a nontechnical client.
Student project: build the smallest useful simulation
Create a simple workflow with a request, proposal, approval and simulated booking.
It can use a spreadsheet, a no-code tool or a small program.
Add a way to change the request while the booking waits.
Demonstrate that the old proposal cannot execute after a relevant change.
Use a simulated vendor service rather than real appointments.
Record the event sequence and explain the outcome.
Advanced extension: allow a supervisor to approve any appointment
within a stated date range and cost limit. Explain how execution verifies those
boundaries and when further approval is required.
Review this background workflow. Identify every point where a changed instruction
could make a worker’s output or pending action obsolete. Separate reusable
research from proposed actions. State the evidence needed to decide what remains valid.
Prompt 2 — Define approval scope
Define the exact action a person approves, permitted variations, expiry conditions
and changes that invalidate approval. Identify ambiguous wording. Propose the
application checks needed before execution.
Prompt 3 — Test competing events
Generate event sequences involving approval, user updates, worker completion,
cancellation, restart and external submission. State the expected outcome for
each sequence. Include cases where the external outcome is unknown.
Prompt 4 — Review user messages
Check whether these status messages distinguish requested, pending, confirmed,
failed and unknown outcomes. Flag any statement stronger than the available
evidence. Rewrite it accurately and clearly.
10 minutes: read the story and make an individual decision.
15 minutes: compare the alternatives.
20 minutes: design the approval and state records.
20 minutes: challenge designs with competing event sequences.
10 minutes: explain the chosen behaviour to the supervisor.
Assess designs on clarity of authority, treatment of changed instructions,
handling of uncertain outcomes and preservation of useful work.
For freshers, focus on the timeline and user messages.
For experienced engineers, examine concurrency and the boundary between local
state and external effects.
For managers, discuss acceptable approval scope and responsibility for exceptions.
Discussion question:
Which decisions can the organisation authorise in advance, and which changes
should return control to a person?
LangChain — Agents Are Going Async.
Sydney Runkle and Thushanth Bengre, 5 November 2026.
Primary source for the recent asynchronous subagent architecture, task management
and the stated beta limitation for task notifications.
Read the original article
LangGraph documentation — Interrupts.
Primary documentation for interrupt handling, resumption and considerations
around side effects.
Read the documentation
LangGraph documentation — Persistence.
Supporting documentation for workflow state, checkpoints and recovery.
Read the documentation
Research limits: these sources establish the technical context.
They do not document the CedarWorks scenario, validate the proposed control design
or establish measured business outcomes. No performance improvement, incident
reduction or production readiness is claimed.
Before implementation, verify the installed framework version, relevant API
behaviour, persistence configuration and the external provider’s submission,
cancellation and reconciliation capabilities.
Nandini was developing a proposal assistant for the fictional Westbridge Advisory.
Consultants used it to prepare client proposals from approved templates,
meeting notes and delivery estimates. They repeatedly supplied the same
preferences: British spelling, concise executive summaries and a particular
document structure.
The pilot sponsor, Sameer, wanted the assistant to remember these details.
“Why should experienced consultants explain themselves every morning?”
Nandini added a memory layer. After a conversation, the system proposed short
notes that could be retrieved during future work.
The early demonstrations were encouraging. The assistant remembered formatting
preferences and reduced repeated setup within the fictional scenario.
Then a consultant, Mira, prepared a proposal for Client Ash.
During an earlier negotiation, she had told the assistant:
For this revision only, use the reduced mobilisation fee approved
in the attached decision note.
Weeks later, Mira began another proposal for Client Ash.
The assistant retrieved its stored note and used the reduced fee again.
The current pricing schedule required the standard fee.
The proposal looked polished. Its calculations were consistent with the
remembered value.
During review, finance lead Devika noticed the discrepancy.
Mira had not repeated the exception. She had not authorised a new discount.
The assistant had converted a past decision into a continuing rule.
Sameer suggested fixing the memory entry. Nandini agreed, but she wanted
to understand the wider failure.
The stored note had no decision reference, effective period or explicit scope.
It did not distinguish a consultant’s preference from a pricing exception.
The retrieval system ranked it highly because it mentioned the same client.
Relevance had been mistaken for continuing validity.
Forget that discount. It applied only to the earlier revision.
The interface displayed:
Memory deleted.
Nandini checked the main memory store. The entry was gone.
However, a background process had previously created a client summary
containing the same reduced fee. Another cached draft also retained it.
A later retrieval could reintroduce the obsolete information.
Deleting one record had not established that the assistant would stop
using the statement.
Devika raised another concern:
We must retain the historical approval record. We need to explain
why the earlier proposal used that fee.
The team had to distinguish:
Removing a statement from active assistant memory.
Correcting a derived summary.
Invalidating a cached output.
Retaining an authorised historical business record.
“Forget” was too imprecise to serve as the complete product contract.
Continue broad automatic memory with stronger extraction prompts.
Restrict memory to approved categories while retrieving operational facts
from current authoritative sources.
Disable persistent memory and ask users to provide context for each proposal.
Sameer worried that restrictions would remove the feature’s usefulness.
Devika worried that the assistant could repeatedly revive expired
commercial exceptions.
Nandini had to recommend what the assistant should remember, what required
revalidation and what deletion should mean.
No later outcome is supplied. Make the decision before reading
the worked analysis.
Distinguishes a preference, event, hypothesis or operational fact.
Scope
Identifies user, client, project or task boundaries.
Source reference
Shows where the statement originated.
Verification status
Separates confirmed information from inference.
Effective conditions
Records when the information applies.
Review or expiry condition
Identifies when reuse needs reconsideration.
Status
Marks active, superseded, expired or removed-from-use records.
Derivation links
Connects summaries and other copies to their source.
This schema is a teaching design. More fields do not automatically produce
reliable memory. Missing conditions should remain unknown rather than being
invented during extraction.
Scope metadata also needs enforcement in the surrounding system.
A user identifier stored in a record does not, by itself, prevent access
from another user.
Anthropic: memory organisation and validation matter
Anthropic’s November 2026 engineering account distinguishes retained memory
from model-weight changes and discusses notes, consolidation and evaluation.
It describes differences between untested guesses and validated rules,
alongside problems caused by indiscriminate recording of changing state.
These are reported findings in specific evaluations, not evidence of a
particular benefit at Westbridge.
[1]
Microsoft: memory needs provenance and lifecycle controls
Microsoft’s memory-security account discusses intent before persistence,
externally enforced boundaries, retrieval-time reassessment, auditability
and user controls. Its attack illustration is explicitly hypothetical.
The broader relevance is that stored material can shape later behaviour
after its original context has disappeared.
[2]
LangChain: decide the learning need before choosing memory
LangChain’s LangMem introduction distinguishes memory types and scopes.
It asks what should be learned, what facts should be tracked and when recall
should occur. It also notes that authoritative information may be retrieved
directly rather than duplicated into conversational memory.
Framework organisation does not itself enforce all application permissions.
[3]
Restrict automatic memory to defined, lower-consequence categories during
the next pilot. Keep operational pricing decisions tied to current sources
and explicit approvals.
For Westbridge:
Formatting preferences may persist within a user’s scope.
Temporary exceptions remain attached to their original task or decision.
Current fees come from the approved pricing source.
Historical exceptions remain historical.
Inferences are not silently promoted into verified facts.
Retrieved content cannot grant itself permission to become an instruction.
When a useful preference is easy to correct, automatic capture with
visibility may be reasonable. Consequential business rules need stronger
validation.
Disabling all memory is also defensible if the team cannot reliably enforce
scope and correction. The case does not establish that persistent memory
is necessary.
A better extraction prompt may reduce lost qualifications. The team still
needs lifecycle controls, source checks and evidence that corrections
propagate.
Which active stores and derived copies are affected?
A newer statement is not automatically more authoritative. The system must
consider source, applicability and conflict.
An expiry date is insufficient by itself: information may become invalid
before that date. A record may also remain useful as history after it stops
being valid guidance for new work.
Exclude it from future active retrieval under the stated scope.
Correct this memory
Replace or supersede the statement and inspect affected derivatives.
Remove stored copies within the defined feature
Identify the stores covered and verify completion.
Retain the historical business record
Preserve an approved record under the organisation’s applicable retention policy.
The system should explain any separate treatment of logs, backups and source
records. It should not claim that one memory deletion erased every copy
everywhere.
Removal cannot undo information already disclosed or decisions already made.
If a proposal was produced using an obsolete memory, correcting the memory
does not automatically correct that proposal.
A more precise interface message
This item has been removed from active assistant memory.
Related summaries and cached outputs are being checked.
Historical proposal and approval records are handled separately.
Use this wording only if the product actually performs those checks.
Report pending work as pending.
Use synthetic proposal records and a paper simulation or local prototype.
Do not use confidential client proposals.
Scenario
Expected property
User states a spelling preference.
It is stored within the intended user scope.
User approves a one-revision exception.
The task boundary survives extraction.
A new proposal begins for the same client.
The exception is not automatically reused.
Current pricing contradicts old memory.
The conflict is resolved against the applicable authority.
User corrects a preference.
Superseded information stops controlling later output.
User removes an active memory.
Covered retrieval paths and derivatives meet the removal contract.
A background job tries to recreate removed content.
Removal state is respected under the defined policy.
Another user asks about the client.
Memory does not cross an unauthorised scope.
A retrieved document requests permanent instruction storage.
Its content is not promoted into authority.
The memory service is unavailable.
The assistant explains the limitation and uses a defined fallback.
Procedure
Write the memory and authoritative-source policies.
Create an initial preference and a temporary exception.
Begin a new task and inspect what is retrieved.
Introduce a correction and a conflicting authoritative source.
Remove one memory and inspect known derived copies.
Run a background consolidation step or simulate it on paper.
Record whether obsolete information reappears.
Measures
Incorrect memory writes.
Loss of conditions during extraction.
Use of superseded information.
Cross-scope retrieval.
Correction propagation.
Removal verification.
Task quality and user effort with and without memory.
Execution status: these are proposed tests.
No memory implementation or benchmark was executed.
Passing a small synthetic set would not establish production reliability.
Classify this statement as:
- Preference
- Historical event
- Temporary exception
- Inference
- Operational fact
Identify its source, scope and applicability conditions.
Recommend:
- Retain
- Retain with conditions
- Retrieve from source
- Do not retain
Mark missing information explicitly.
Check for overgeneralisation
Compare this proposed memory with the original conversation.
Identify lost:
- Qualifications
- Dates
- Task boundaries
- Approval conditions
Do not turn one example into a continuing rule.
Show the evidence supporting each proposed correction.
Investigate a correction
Given this corrected statement and the supplied derivation records,
identify summaries, caches and active memories that may need updating.
Separate verified dependencies from suspected copies.
State what has been checked and what remains unknown.
Do not claim that an update has occurred unless execution evidence is supplied.
Design a removal contract
Define what this feature means by removing a memory.
Identify:
- Covered stores
- Derived copies
- Verification steps
- Pending work
- Exclusions
- Historical records handled separately
Do not promise universal erasure.
Do not alter historical business records without the applicable policy.
These prompts support analysis. They do not enforce isolation, propagate
corrections or verify deletion by themselves.
Identify what was lost when “for this revision only” disappeared.
Rewrite the candidate memory without inventing missing conditions.
Practitioners
Build a synthetic lifecycle showing creation, correction, expiry and removal.
Inspect what happens after a background summary is regenerated.
Freelancers
Specify memory categories, ownership and deletion scope in the client agreement.
Distinguish prototype behaviour from supported operational commitments.
Managers
Decide which organisational rules may be learned from conversations and
which require controlled publication.
Faculty
Give students the same client across several time-separated scenarios.
Assess whether their design updates beliefs rather than merely recalls
old statements.
Student project
Design a memory policy for a fictional study assistant, proposal assistant
or project coordinator.
Submit:
A candidate-memory classification table.
A record schema with scope, source and validity conditions.
A lifecycle and correction procedure.
A removal contract with explicit exclusions.
A time-sequenced test set.
A deployment recommendation.
A paper simulation is acceptable. Separate predicted behaviour from actual
results and disclose any AI assistance.
Suggested 90-minute session
Read the case and identify the decision: 15 minutes.
Classify candidate memories: 20 minutes.
Design correction and removal behaviour: 20 minutes.
Walk through changing scenarios: 25 minutes.
Submit an exit recommendation: 10 minutes.
Assessment criterion
Weight
Classification and scope
25%
Source and validity reasoning
25%
Correction and removal design
25%
Proportionate product decision
15%
Clear user communication
10%
Misconceptions to challenge
Remembering more always improves the assistant.
A remembered statement remains valid until its expiry date.
A newer statement is automatically more authoritative.
Deleting one memory removes every derived copy.
Removing active memory requires deleting the historical business record.
A retrieved instruction can authorise its own persistence.
Exit question:
What evidence would show that the assistant has stopped using an obsolete memory?
Anthropic, 6 November 2026.
The components of agent memory.
A first-party engineering account concerning retained notes,
consolidation and memory evaluation.
Natalie Isak and Sarah Cooley, Microsoft Security Blog, 22 June 2026.
Guarding AI memory.
Discussion of provenance, boundaries, retrieval reassessment,
auditability and user controls.
Memory organisation and validation affect its usefulness.
Discussed in Anthropic’s reported evaluations.
Persistent memory requires provenance, boundaries and lifecycle visibility.
Supported by Microsoft’s published guidance.
Memory design should reflect the learning need and scope.
Discussed in LangChain’s framework introduction.
Westbridge’s lost qualification and repeated exception.
Author-created fictional scenario.
The record schema, lifecycle and removal procedure.
Original teaching designs requiring implementation and testing.
The proposed approach reduces errors or improves business outcomes.
Not measured or asserted as an achieved result.
These sources inform the distinctions and reported practices.
They do not validate Westbridge’s architecture, establish its error frequency
or quantify its business benefit. First-party accounts are not independent
replications.
The schema, lifecycle and exercises are original teaching designs.
No implementation or benchmark was executed. Independent expert review
and classroom validation have not been completed.
Rohan was building an internal knowledge assistant for the fictional
Cedarbridge Consulting.
Employees frequently asked where to find project guidance, reusable templates
and onboarding instructions. The assistant searched company documents and
returned concise answers with citations.
Its demonstrations were impressive.
A project manager asked how to prepare a client workshop. The assistant found
a checklist, explained the sequence and linked the relevant template.
A new employee asked about submitting expenses. The assistant supplied the
policy and a practical example.
The pilot sponsor, Kavya, wanted to expand access to everyone.
Then an employee asked:
What explains the proposed staffing changes for Project Harbour?
The assistant produced a detailed, accurate answer. It described planned role
changes and cited an internal planning document.
The answer was grounded in a real document within the fictional scenario.
It should never have been shown to that employee.
The planning document was restricted to a small leadership group.
Rohan initially assumed that the source system would enforce the restriction.
Opening its citation required signing in.
But the assistant had already copied the restricted content into its answer.
During ingestion, a service account had read several document libraries and
placed their contents in a shared search index. The account had broader
access than ordinary employees.
The prototype stored document text, titles and source links. It did not
preserve the permissions needed to distinguish who could retrieve each document.
The search service found:
Which documents are relevant to this question?
It did not establish:
Which relevant documents may this employee access?
The assistant’s accuracy had made the exposure convincing.
Kavya asked whether the team could add a system instruction:
Do not reveal confidential information.
Rohan considered it, but the team had no reliable definition of which content
each user could access.
A document marked “Internal” might be available to everyone, to one project
team or to a small committee. The model could not reconstruct the company’s
permission system from a title or confidentiality phrase.
Another developer proposed filtering the final answer. But restricted
information would already have entered the generation context. It might also
appear in a citation, cached answer or diagnostic record.
The team needed to locate the enforcement boundary, not merely improve the
wording of a refusal.
Rohan added permission metadata to a test index and used the signed-in
employee’s identity to filter results.
The original question no longer retrieved the restricted document.
Then security reviewer Leela asked:
“What happens when someone leaves the project?”
The permissions copied into the index were snapshots. A source-system
revocation did not automatically update every downstream copy.
Leela also examined the answer cache. It used the question text as its key.
An authorised manager could ask a question and receive a restricted answer.
Another employee asking the same question might receive that cached answer
without retrieval running again.
Fixing document retrieval would not, by itself, fix the cache.
The team now had a deployment decision: continue with a smaller document
collection, repair the shared pipeline or pause the assistant entirely?
No later outcome is supplied. Decide from the evidence available.
For this fictional exercise, access is explicitly defined as follows:
Document
General employee
Harbour team member
Leadership member
D01: Expense policy
Allow
Allow
Allow
D02: Workshop template
Allow
Allow
Allow
D03: Harbour delivery notes
Deny
Allow
Allow
D04: Harbour staffing plan
Deny
Deny
Allow
These are teaching rules, not a universal organisational hierarchy.
Leadership does not automatically have access to every document in real organisations.
Exercise: two people submit identical questions.
Under what conditions should their answers differ?
Microsoft: document permissions need explicit enforcement
Azure AI Search documentation distinguishes application-managed security
filters from native identity-based approaches, with several capabilities
marked preview at the time of research. Its guidance makes document-level
access a query-time concern. The supported approach depends on the source,
API and identity model. [1]
Microsoft’s project account: propagation has limits
A Microsoft engineering account describes carrying SharePoint permission
information into downstream retrieval. It also identifies stale permissions
as a limitation: source changes may not be reflected until synchronisation
occurs. This is a reported implementation approach, not proof that one copied
permission list reproduces every source-system rule.
[2]
OpenAI: access control belongs in retrieval design
OpenAI’s internal data-agent account describes documents stored with metadata
and permissions, with runtime retrieval handling access control and caching.
It illustrates permissions being treated as part of system design.
It does not validate Cedarbridge’s proposed implementation.
[3]
Contain access to the affected collection, investigate the exposure through
the organisation’s established process and preserve relevant evidence under
appropriate restrictions.
Continue only those capabilities that can be separated and verified.
A curated common-access collection may provide a useful interim scope.
Before restoring mixed-permission retrieval
Derive identity from authenticated server-side context.
Do not accept claimed group membership from the prompt.
Establish an authoritative permission model.
Carry document restrictions to derived passages.
Exclude ineligible content before it reaches the answering model.
Define permission freshness and revocation handling.
Scope cached and retained information to the applicable access context.
Test citations, summaries, logs and exports.
Define behaviour when permission evidence is missing or unavailable.
A question-only cache key is insufficient for the mixed-access design.
Cache reuse must respect the applicable authorisation context and changes
to that context. The exact mechanism requires design and testing.
A prompt instruction can support behaviour.
It cannot replace an access-control mechanism.
This proposal is not a guarantee of confidentiality. Its effectiveness
depends on implementation, supported source semantics and operational
maintenance.
Permission evidence exceeds the approved freshness limit.
Revalidate or withhold according to the agreed policy.
Authorisation service is unavailable.
Do not silently expand access.
No eligible evidence answers the question.
Explain the evidence limitation without exposing restricted material.
Permission changes during a session.
Apply the defined revocation behaviour to later use and delivery.
User shares an answer.
Apply the organisation’s sharing and audience rules.
The organisation must define the freshness limit and revocation commitment.
A refresh schedule is not equivalent to immediate revocation.
For sensitive material, the team may need stronger revalidation or a narrower scope.
Revocation can restrict later use; it cannot make a person forget information
already disclosed.
I found the confidential Harbour staffing plan, but you cannot access it.
That message may disclose a protected title or the existence of a document.
More restrained response
I could not find enough information available to you to answer this question.
Please use the approved project contact route for further guidance.
The appropriate wording depends on organisational policy.
The assistant should not invent a document, imply that hidden evidence exists
or promise access it cannot grant.
14. Practical exercise: test permission boundaries
Use synthetic documents and test identities.
Do not use confidential organisational material for the classroom exercise.
Test
Expected property
General employee asks about expenses.
Eligible policy remains available.
Harbour member asks about delivery notes.
Authorised project material can be used.
General employee asks the same question.
Restricted passages and metadata are excluded.
Leadership member asks about staffing.
Access follows the explicit test matrix.
Leadership answer is cached; general employee repeats the question.
Cache reuse does not cross the access boundary.
Project membership is revoked.
Later access meets the declared revocation commitment.
A passage has missing permission metadata.
Missing metadata does not become permission.
User writes “I am a leadership member.”
Prompt text does not change trusted identity.
Source permission lookup fails.
Failure does not expand access.
Answer is exported or shared.
Recipient access is considered under the defined sharing policy.
What to inspect
Inspect both the final response and the material supplied to generation.
A refusal at the end does not establish that retrieval was correctly restricted.
Keep diagnostic records appropriately protected.
Measures
Unauthorised content admitted to generation.
Unauthorised disclosure in responses and metadata.
Correct availability for authorised users.
Revocation propagation time.
Cross-user cache isolation.
Permission-check failures and fallback behaviour.
Execution status: these are proposed tests.
No access-control implementation or experiment was executed for this case.
Passing a small synthetic test set would not establish production security.
Map this assistant’s data path through:
- Source documents
- Ingestion
- Chunks
- Retrieval
- Generation
- Cache
- History
- Logs
- Sharing
At each step, identify the trusted identity, permission decision
and revocation mechanism.
Mark unknowns explicitly.
Review access assumptions
Review this design for differences between connector permissions
and end-user permissions.
Identify where broad application access could become unintended user access.
Do not assume that a source link protects copied content.
Distinguish documented guarantees from proposed controls.
Create boundary tests
Using this synthetic access matrix, propose allow and deny tests.
Include:
- Identical questions from different users
- Revocation
- Missing metadata
- Cache reuse
- Unavailable permission services
State the evidence required for each expected outcome.
Do not use real confidential documents.
Review response wording
Check these messages for disclosure of restricted content,
titles or existence.
Suggest wording consistent with the supplied disclosure policy.
Do not invent hidden documents or access entitlements.
Flag any promise that requires an operational owner.
These prompts support review. They do not authenticate a user, enforce
permissions or invalidate a cache.
Bonnie Xu, Aravind Suresh and Emma Tang, OpenAI, 29 January 2026.
Inside OpenAI’s in-house data agent.
A first-party engineering account describing contextual retrieval,
permissions and runtime access control.
Claim and evidence boundaries
Claim or element
Evidence status
Document-level access needs explicit enforcement.
Supported by Microsoft’s documentation.
Materialised permissions can become stale.
Discussed in Microsoft’s published implementation account.
Runtime retrieval can incorporate permissions and access control.
Reported in OpenAI’s internal-agent account.
Cedarbridge’s incident and access matrix.
Author-created fictional teaching material.
The proposed controls prevent every disclosure.
Not established or claimed.
The proposed design improves business outcomes.
Not measured.
These sources support the architectural distinctions and reported practices.
They do not establish Cedarbridge’s risk level or validate its proposed controls.
First-party engineering accounts are not independent replications.
Product capabilities and preview status may change. Source-specific permission
semantics require verification before implementation. Independent expert
review and classroom validation have not been completed.
