Free learning / 90-minute team practice

First scoped-context receiving session

A paired Python session: compare identical happy-path context with actual permission checks, remove a grant and give identity, data, model and action owners the remaining work.

Begin reading Download a working copy

No account needed. Use your own copy for writing and keep the original as a reference.

Engineering lab library / Run locally

Choose your next agent lab.

Start with the durable workflow reference, then choose the boundary you want to test. Open its walkthrough for setup, commands and expected observations.

Synthetic records. No provider key or model inference. Runs locally with the standard library.

Start here / Python 3.11+ · Standard library
Scoped context receiving fixture
Compare allowed and removed-grant context without mistaking supplied identity or a successful read for authentication evidence.
Python 3.11+ · Standard library · In-memory SQLite · Supplied fictional principal · No login, model or network
Open walkthrough Download file

Prepare Python 3.11+ and the complete tool-boundaries kit before this ninety-minute paired practice. Preview the prepared agenda before explicitly choosing whether to use it. This is a planning estimate, excluding setup, reading and breaks. An agenda creates no assignment, attendance or training entitlement; leave unavailable execution unrun.

Each participant extracts a separate folder and keeps the unchanged identity companion and first tool-boundary worksheet. The stated commands use standard-library Python and in-memory SQLite. No packages, model, account, network or real records are required. Redirected JSON files are local reports; use new filenames to preserve an earlier attempt.

Keep individual predictions, exact commands, first output, assistance and later corrections. Supplied output is not another person's run. Declare prior reading, combined roles or solo self-review. These published conditions are practice, not a held-out test of unaided performance.

Minutes 0–35: establish the read boundary

← Back to lab library Download Scoped context receiving fixture ↓

Follow worksheet sections 1–3. The rounds and review below replace its section 4. Keep the five read reports and complete-versus-missing-tenant join comparison. Retain the useful allowed control, refused scope change, no permitted row and first delivered observation after grant removal. Do not treat a safe not_available response as proof that the requested document does not exist.

Locate Principal, read_document and the complete grant/document relationship in the original source. The host supplies a fictional principal; its constructor does not verify identity. The requested tenant is untrusted data, while the read action is fixed by the function. Bound SQL parameters do not repair a missing tenant relationship. Both receiving rounds use the unchanged original, not an optional repaired comparison copy.

Minutes 35–55: receive the happy path and its limits

A builds and B receives. A supplies the unchanged program and boundary notes. B predicts both paths' context, reads and unattempted candidates before running:

Code example

python3 fde-identity-boundary-lab.py context-selection --candidate-order north-first --north-grant present > receiving-present.json

The program compares two independently reset local databases. The deliberately_unchecked path reads a candidate without authorization; the scoped path calls read_document before adding permitted data to context. These are two teaching policies, not two production services.

With North/P-7 first and its read grant present, both paths produce the same North context. Each makes one SQL read and leaves two candidates unattempted. That matching output does not establish that both enforced permission. B locates the actual calls and attempt states: checks_bypassed versus allowed. Unattempted candidates provide no observation of their access behavior.

Retain B's prediction, command, JSON and explanation before A discusses the result. The context is a local list, not a prompt sent to a model. The comparison report declares model_calls: 0 and establishes no generated-answer quality.

Minutes 55–75: swap roles and remove only the read grant

B now builds and A receives. Keep the trusted North principal and north-first candidate order. A predicts the effect of changing only the grant fixture:

Code example

python3 fde-identity-boundary-lab.py context-selection --candidate-order north-first --north-grant revoked > receiving-revoked.json

Compare the original and changed reports without replacing either. Here revoked removes the North read grant before candidate selection. It does not revoke a real login or race a request already in progress.

Path	Actual observation to locate	Remaining limit
Deliberately unchecked	One SQL read still adds North/P-7 to context; the other two candidates are unattempted	A happy-path result concealed missing authorization
Scoped	North/P-7 has no permitted row; South/P-7 is refused before a query; North/P-8 has no permitted row	Two actual SQL reads yield empty context; no model response is observed

A locates all three scoped attempts, the unchanged trusted principal, actual sql_reads, empty context and zero model_calls. Do not report that the scoped path made no database queries. Refusing the South request before SQL is different from querying North and finding no permitted row.

The earlier present-grant report remains useful evidence of an earlier condition; it does not authorize this later read. Removing access cannot erase information already delivered. Each path uses a fresh sequential fixture, so these runs do not establish cache invalidation, concurrent revocation or distributed safety. Exit 0 means the local report ran, including denied cases. A Python/import error or interrupted run is a different condition, not the expected access result.

Minutes 75–90: give the next owners answerable work

Each receiver explains their own evidence before the team agrees a bounded receiving decision. Keep actual rows and debug traces in the synthetic exercise; their detailed states are not a proposed public error or logging contract.

Receiving role	Work still to establish
Host/identity owner	Verify the caller and active workspace in the real host; a supplied principal is not that evidence.
Data/service owner	Enforce the complete current resource/action relationship and define safe responses and operational diagnostics.
Context/model owner	Bind permitted source revisions to an actual model request and define supported-answer cases; no inference ran here.
Write owner	Specify separate update permission, resource-version conflict, duplicate handling and uncertain-effect reconciliation before implementing an update. A read grant does not permit it.
Pod lead	Retain cache, concurrency and action requirements as unrun; name the next bounded test, owner and update before committing delivery.

One copy per participant:

Text example

Alias / actual role / prior reading and help:
My first prediction / exact file revision and command:
Actual context / attempt states / SQL-read references / model_calls:
Attempted and unattempted candidates / what they establish:
Receiving action I performed / assistance or author takeover:
My first explanation / later correction and its evidence:
Unrun identity, model or write requirement / accountable role:
Next agreed test, expected behavior and update:

Assign actual people later. This practice creates no authenticated identity, MCP connection, production permission, independent delivery, qualification or client placement. Preserve each person's observations and unrun receiving work.