Shared phones and wrong-person memory

TL;DR: A phone number can help route a call, but it cannot establish which person is entitled to private memory. Resolve a verified subject, enforce exact tenant and subject scope before retrieval, and recheck the session authority before recalling prepared information.

---

Two people use the same household phone. The first caller discusses a private task, and the second caller later hears the agent continue that task without being asked who they are.

The memory lookup can be technically accurate: it found history associated with the incoming endpoint. The mistake is treating endpoint continuity as person continuity and disclosing that history before the person boundary was established.

The first useful rule is simple: phone routing and person authority are separate. Public help can begin on an unverified call, while private recall waits for an appropriate verified identity and current permission.

This guide provides exact-scope selection and final-admission functions with runnable cross-caller fixtures. It covers shared endpoints, subject changes, delegated callers, cache isolation, and evidence collection without prescribing a universal authentication ceremony.

All names, identifiers, records, and traces are synthetic. The examples are generic reference contracts and do not describe private 60db Agent systems or a measured security outcome.

Table of contents

1. Separate endpoint from person
2. Define private recall authority
3. Filter before private retrieval
4. Run cross-caller isolation fixtures
5. Handle subject changes during a call
6. Keep caches and summaries scoped
7. Review delegated and shared access
8. Diagnose wrong-person recall
9. Test the full disclosure boundary
10. Roll out a verified recall path
11. Exercise isolation beyond the obvious lookup
12. Preserve isolation during ordinary maintenance
13. Frequently asked questions
14. Prove isolation before personalization

Separate endpoint from person

A phone number describes a route through the communications system. Households, workplaces, reception desks, forwarded lines, and reassigned subscriptions can put different people behind the same apparent endpoint.

A call can also move between people without reconnecting. Someone can hand the phone to a colleague, let a family member answer a question, or ask a representative to speak on their behalf.

Those cases break a design that binds memory to the transport connection alone. The application needs a person or authorized relationship boundary that remains distinct from the call and endpoint identities.

NIST's digital authentication guidance describes authentication of a subject through authenticators. Use an appropriate identity flow for the task instead of treating a known incoming number as an equivalent proof.

Transport authenticity is another separate boundary. Twilio's webhook security guidance describes validating requests from its platform; validating a webhook does not establish which human is speaking on the call it represents.

Keep these distinctions in the event schema. A provider call identity, endpoint reference, session identity, verified subject, tenant, and authorization revision can each answer a different diagnostic question.

Do not label a caller as the remembered person merely because a lookup found one matching endpoint. That can influence greetings, retrieval, summaries, and outgoing notifications before the system has made an explicit access decision.

A neutral opening can ask what the caller needs without revealing private history. Public information and nonpersonal routing can proceed while the private recall path remains closed.

The local versus managed voice AI guide helps inspect data boundaries. Whether identity and memory run locally or through managed services, the application must still connect the current person to the authorized record scope.

A familiar endpoint is useful operational context. It can help route a request or locate candidate verification paths, provided the application does not expose a private relationship merely by saying what it found.

Define private recall authority

A verified subject is necessary for many private recall tasks, but it may not be sufficient. The subject must also be authorized for the tenant, record, purpose, and action the current task requires.

OWASP's authorization guidance recommends deny-by-default behavior and validating permissions on every request. Apply that rule to a memory search as well as to a business record update.

Use exact identifiers at the authority boundary. A fuzzy name match, voice similarity, or semantic relationship can propose a candidate identity, but it should not silently authorize disclosure.

Keep the verification result immutable and owned by the trusted adapter. A model-generated tool argument or caller-supplied dictionary should not be able to rewrite the subject after the access decision was made.

Bind the result to a session and authorization revision. A valid result from an earlier session must not be replayed as current authority after logout, revocation, or a change of person.

OWASP's session management guidance discusses session lifetime and invalidation. Memory recall should consume the current trusted session state, rather than caching an earlier allowed decision indefinitely.

A person's authority can also be purpose-limited. Access to a shared business account does not automatically permit recalling every personal preference or private conversation associated with another authorized user.

Write the relationship explicitly when delegation is supported. "Representative may discuss this shipment" is a different grant from "representative may hear the account owner's historical conversations."

The repeat-call memory contract adds consent and expiry. Identity isolation is one requirement, and the record can still be ineligible after an exact owner match.

Avoid a confidence threshold as the final authorization rule for a high-consequence disclosure. A model's confidence in a name or voice is evidence about a recognition task, not a permission grant under the application's identity policy.

The explicit comparison prevents a visual shortcut too. A line from "same phone" directly to private memory would encode the very mistake the contract is designed to stop.

Filter before private retrieval

Restrict private candidates by trusted scope before sending them to a model or broad semantic search result consumer. Filtering only the final spoken text can be too late if unauthorized passages have already entered a prompt, log, or cache.

The data-access adapter should derive the scope from verified state. A query string such as "show the other caller's notes" must not change the tenant or subject constraints applied by the store.

PostgreSQL's row security documentation describes policies and default-deny behavior when enabled, along with bypass caveats for privileged roles. Verify the actual database role and query path rather than assuming a policy name establishes coverage.

Row security is one possible enforcement layer. The application still needs a current subject mapping, appropriate purpose checks, and care around derived caches or external indexes that do not share the same database policy.

A vector store namespace can help organize records but is not automatically an authorization system. Confirm that every query path applies the current namespace and that a caller cannot select a different one through generated arguments.

Use the final admission check as another boundary. A scope-correct result can become ineligible if the person changes while retrieval or answer generation is waiting.

The table compares design properties. A check means the design explicitly provides the property; a cross means it needs another mechanism.

Scope enforcement should fail closed when the trusted subject is absent. Continue with public help or an appropriate verification step instead of broadening retrieval to every record associated with the endpoint.

Run cross-caller isolation fixtures

Save this complete fence as caller_isolation.py and run Python 3.11 or later. It uses an in-memory sequence of synthetic records to demonstrate filtering and final authority comparison.

Authority is trusted adapter output, not a credential that arbitrary application code may mint from caller speech. The program does not authenticate anyone; it shows how a verified result should constrain later memory use.

The supported records contain immutable strings. Caller-owned record collections are copied into a tuple at selection, and prepared results retain an immutable authority snapshot for the final comparison.

import asyncio
from dataclasses import dataclass, replace, FrozenInstanceError


@dataclass(frozen=True)
class Authority:
    tenant: str
    subject: str
    session: str
    revision: int
    active: bool = True

    def __post_init__(self):
        if any(type(v) is not str or not v for v in
               (self.tenant, self.subject, self.session)):
            raise ValueError("verified scope strings required")
        if type(self.revision) is not int or self.revision < 0:
            raise ValueError("invalid authority revision")
        if type(self.active) is not bool:
            raise ValueError("boolean active flag required")


@dataclass(frozen=True)
class Record:
    tenant: str
    subject: str
    value: str

    def __post_init__(self):
        if any(type(v) is not str or not v for v in
               (self.tenant, self.subject, self.value)):
            raise ValueError("immutable record strings required")


def select(records, authority):
    if authority is None or not authority.active:
        return ()
    return tuple(r for r in records
                 if (r.tenant, r.subject) ==
                    (authority.tenant, authority.subject))


def admit(records, issued, current):
    if current is None or not current.active:
        return "unverified", ()
    if issued != current:
        return "stale_authority", ()
    if any((r.tenant, r.subject) != (current.tenant, current.subject)
           for r in records):
        return "wrong_owner", ()
    return "eligible", tuple(r.value for r in records)


async def recall(records, issued, current_authority, wait):
    selected = select(records, issued)
    await wait()
    return admit(selected, issued, current_authority())


async def tests():
    # Both people can use one phone; endpoint is never an authority key.
    records = [Record("demo", "person-a", "synthetic amber preference"),
               Record("demo", "person-b", "synthetic blue preference"),
               Record("other", "person-a", "synthetic other tenant")]
    a = Authority("demo", "person-a", "session-a", 0)
    b = Authority("demo", "person-b", "session-b", 0)
    selected = select(records, a)
    records.clear()
    assert len(selected) == 1
    assert admit(selected, a, a) == ("eligible", ("synthetic amber preference",))
    assert admit(selected, a, b) == ("stale_authority", ())
    assert select(selected, b) == ()
    assert select(selected, None) == ()
    assert admit(selected, a, None) == ("unverified", ())
    assert admit(selected, a, replace(a, active=False)) == ("unverified", ())
    assert admit(selected, a, replace(a, revision=1)) == ("stale_authority", ())
    assert admit(selected, a, replace(a, session="new")) == ("stale_authority", ())
    assert admit((Record("demo", "person-b", "private"),), a, a) == ("wrong_owner", ())
    try:
        a.subject = "person-b"
        raise AssertionError("authority was writable")
    except FrozenInstanceError:
        pass
    started, release = asyncio.Event(), asyncio.Event()
    live = [a]

    async def wait():
        started.set()
        await release.wait()

    pending = asyncio.create_task(recall(selected, a, lambda: live[0], wait))
    await started.wait()
    live[0] = b
    release.set()
    assert await pending == ("stale_authority", ())
    assert admit(selected, a, replace(a, active=False)) == ("unverified", ())
    print("synthetic cross-caller isolation fixtures passed")


if __name__ == "__main__":
    asyncio.run(tests())

The authority comparison includes session and revision as well as owner. That prevents an old prepared result from becoming current again when the same subject later establishes a different session.

The program intentionally excludes consent, purpose, expiry, and source freshness so it can teach one boundary. Compose those checks with this isolation boundary before claiming a real record is ready for private recall.

Handle subject changes during a call

A person change should invalidate dependent retrieval, answer plans, cached permissions, and queued private audio. Updating a display label while leaving those objects alive creates a mixed-owner session.

Introduce a new authority revision when the trusted identity or access context changes. Prepared work keeps the old snapshot, so final admission can reject it without guessing which person the callback intended.

Do not use arrival time as authority. An old lookup can finish after a new verification, and its late completion must remain attached to the old subject rather than being relabeled as the current person's evidence.

The query correction guide provides a related versioned contract. For identity changes, retain the stronger exact-owner check as well as the conversation revision.

The interruption ownership guide covers queued output invalidation. A caller handing over the phone can require output cancellation even when the next person has not yet said enough to trigger an ordinary semantic correction.

An exact retry of old work should preserve its current stale or closed disposition. A previously successful lookup is historical evidence, not permission to replay its private text under the new authority.

The adapter must recheck after waiting. Retrieval, answer generation, synthesis, and transport readiness can each introduce an asynchronous interval in which the current subject or authorization changes.

If a final local submission is synchronous under one event-loop owner, check immediately before it. Additional asynchronous work requires another check, and distributed submission requires its own atomic authority boundary.

Keep caches and summaries scoped

A memory store can be correctly scoped while a derived answer cache leaks the same information. Inspect every representation that can feed a response, including summaries, embeddings, transcripts, generated audio, and evaluator traces.

Key private reusable data by the actual ownership and policy dimensions. A normalized phone number, caller name, or semantically similar question is insufficient as the sole key for a private answer.

The spoken answer caching guide separates scope from freshness. An entry can be both current and wrong-owner, so a short TTL does not repair an isolation defect.

Keep public reusable wording separate from personalized clauses. A neutral explanation can be shared when its evidence remains applicable, while the private amount or historical detail must come from the current authorized subject's source.

A broad conversation summary is an easy bypass. If the summarizer included the previous person's private facts, passing that summary into the new subject's prompt has already crossed the boundary before the next memory search runs.

Make summaries ownable records with lineage and eligibility. Do not treat generated text as public merely because a model rather than a human wrote it.

The retrieval-to-speech guide shows how to keep evidence separate from wording. That makes it easier to invalidate a private claim without confusing its polished phrasing with independent authority.

When a cache cannot establish its complete scope, refuse private reuse and fetch through the authorized path. Guessing the missing owner can disclose information before a later correction is possible.

Review delegated and shared access

Some callers legitimately act for another person or a shared organization. Support that through an explicit relationship grant rather than by weakening the person boundary for every shared endpoint.

Identify the actor and the subject separately. The actor is the verified person making the request; the subject identifies whose record the task concerns under the allowed relationship.

Attach purpose and action to the grant. A person authorized to schedule an appointment may not be authorized to hear an earlier private conversation or change the subject's memory preferences.

A shared business account can also contain person-specific preferences. Keep account-wide settings and individual memory separate so one authorized account user does not receive another user's personal history by default.

The workflow enforcement guide explains why a spoken claim does not establish business authority. "I handle their calls" is untrusted evidence until the appropriate verification and relationship checks succeed.

Avoid storing the grant only in a natural-language summary. A later rewriter can omit a restriction, so trusted structured state should carry the actor, subject, allowed scope, and current revision.

Revocation must invalidate prepared work under the old grant. The same delayed-result fixture used for a person switch can hold a delegated lookup, revoke the relationship, then release the result.

The diagram keeps the columns separate because routing convenience does not imply disclosure authority. Legitimate delegation belongs in the verification and authorization path, not in an arrow that bypasses it.

Diagnose wrong-person recall

When wrong-person recall is reported, identify the first private fact that crossed the boundary. A personalized greeting, topic hint, or confirmation that history exists can be a disclosure before the detailed answer begins.

Trace the endpoint, call, session, verified subject, tenant, authority revision, selected record owner, and final admission outcome. Keep those identities distinct instead of storing one overloaded caller_id field.

W3C's PROV overview describes provenance relationships. In practice, connect the spoken claim to the record and selection activity that supplied it, including any cache or summary between them.

A community discussion asks about cross-thread context isolation. That is a useful problem shape, while its report is not proof of your system's cause or an established vendor-wide defect.

Use source and adapter evidence to decide where the leak began. A correct database filter followed by a contaminated summary needs a different repair from a cache keyed only by phone number.

The voice observability guide provides the boundary-oriented trace pattern. Restrict access to the diagnostic bundle and use harmless synthetic canaries for routine reproductions.

Do not ask a reporter to share another person's private content in a broad channel. Capture the minimum evidence necessary under an authorized incident process and keep the reproduction separate from the original data.

Test the full disclosure boundary

A local selector test is necessary and incomplete. A live path can still reveal data through a greeting, generated summary, tool description, timing difference, or already queued audio.

Start with two synthetic subjects using one endpoint and deliberately distinct canary preferences. The second subject must never receive the first canary through any response path.

Add a second tenant with the same local subject identifier. This catches code that filters by subject while forgetting the tenant dimension in a cache, index, or tool adapter.

Test an unverified caller asking whether a named person's history exists. The response should avoid confirming private record existence and should offer the appropriate public help or verification path.

Test a subject switch while retrieval waits, while generation waits, and while private audio waits for submission. Each stage should reject the old authority at its protected boundary.

The audio backpressure guide covers held output and age checks. A queue draining to empty must not erase the generation-wide history needed to reject an older same-generation arrival.

The playback acknowledgment guide distinguishes submission and provider evidence. A clear command must be interpreted through the actual transport contract rather than assumed to retract sound already heard.

Include negative cache retries after closure. The old result can remain available for authorized diagnosis, but it must not restore the closed or canceled response's ability to speak.

Roll out a verified recall path

Begin with private recall disabled until trusted authority is available. This gives you a simple baseline: public help remains usable, and no endpoint-associated history enters the prompt before verification.

Add one narrowly scoped memory feature and retain the non-memory path. A caller should be able to complete an ordinary public task without accepting unnecessary personalization.

Review the complete data flow before expanding. Database row policies do not cover an external vector index, and a scoped vector query does not cover an answer cache or a generated audio asset.

The repeat-call memory guide adds the remaining record eligibility dimensions. Treat isolation as a requirement rather than a substitute for purpose, consent, expiry, or deletion.

Measure wrong-owner attempts, blocked stale authority, and successful eligible recall separately. A blocked synthetic cross-caller attempt is evidence the boundary worked; it is not a count of real disclosures prevented in production.

The voice regression guide helps keep that distinction reproducible. Preserve the fixture inputs and expected outcomes so later personalization changes must pass the same isolation contract.

This article reports no production incident rate, authentication accuracy, or acoustic non-disclosure result. The reference verifies local selection and current-authority checks, while real authentication, distributed submission, and physical playback require separate evidence.

Exercise isolation beyond the obvious lookup

The most visible private-memory path is a direct question about the previous call. Isolation tests should also cover the less visible paths that shape a response before the caller asks for any history.

Start with the greeting. A message that names a prior task can reveal a relationship even when the system never reads the stored details aloud, so include greeting generation in the private-recall inventory.

Then inspect suggested actions. Offering to continue a specific unfinished request can expose its existence, and the suggestion may come from a summary rather than the memory API your team already tested.

Next inspect tool selection. A model that received another subject's context can choose a private lookup or destination based on that context, even if the final response text omits the original fact.

The same issue applies to outgoing notifications. A remembered destination or contact preference must belong to the currently authorized subject and purpose before the system uses it to send information elsewhere.

These are disclosure and action boundaries, not reasons to retain more logs by default. Inventory the representations and use synthetic canaries to expose unintended reuse without collecting real conversations for routine tests.

A synthetic household fixture can use one shared endpoint and two verified subjects with unrelated preferences. Before either verification, the agent should provide neutral public help; after verification, only that subject's eligible preference can influence private recall.

Repeat the fixture with the same local subject identifier in another tenant. The expected result is separation even when every other field, including the question text and endpoint reference, is identical.

Repeat it again after a subject switch inside one call. Hold a prepared response from the first authority, establish the second authority, then release the old response and assert that no first-subject content is admitted.

Do not rely on the model to notice the change in a transcript. The trusted authority revision should invalidate prepared work even when the person switch was established through another verified channel rather than spoken aloud.

An application can also face an uncertain person change. Background speech or a different voice is not automatically proof of a new subject, so define the product policy for pausing private recall and requesting clarification under uncertainty.

That policy should protect data without pretending the detector is infallible. Keep recognition evidence separate from the verified authority state, and evaluate false alarms and missed changes under representative conditions before making performance claims.

A model confidence score is not automatically a calibrated probability. If you use one to request an additional verification step, measure the decision's errors against reviewed cases and retain the exact boundary the score informs.

The authorization rule remains explicit. A high similarity score should not directly change the owner scope or bypass the approved authentication flow just because the system is eager to personalize the call.

For a delegated caller, add an actor-subject fixture. The actor can be authorized for one task involving the subject while remaining unable to hear unrelated personal memory, and the result should reflect that narrow relationship.

Test both grant and revocation. Hold a request under the delegated grant, revoke the grant, and release the result; its historical success must not authorize present disclosure.

A later grant creates current authority with its own revision. Do not reuse an old prepared response simply because the actor and subject identifiers match again, since the allowed purpose or scope may have changed.

Use a separate fixture for an account-wide preference. If the product intentionally shares a setting among authorized account users, label and store it as account-wide data rather than pretending it is one person's private memory.

This avoids accidental policy inheritance. A shared business opening-hours preference and an individual's previous support discussion can live in the same application while requiring different owners and disclosure rules.

The workflow enforcement guide helps keep those grants tied to actions. A response can explain public account procedures while still withholding a private historical detail or refusing an unauthorized change.

Review cache behavior under each fixture. A correctly filtered store can be bypassed by a normalized-question cache, an endpoint-level conversation summary, or an audio asset generated for the first subject.

Require each private cache entry to carry the owner and current authority dependencies that justified its creation. If the consumer cannot establish those dependencies, it should use the authorized source path instead of making a best-effort identity guess.

The cache freshness guide explains the lifetime dimension. A cache can be fresh in time and wrong in ownership, so expiration and isolation must remain separate checks.

Prepared audio deserves particular attention because its content is harder to inspect after synthesis. Carry approved claim and owner identities alongside the asset, and reject the whole asset if its private clause no longer belongs to the current authority.

The sentence boundary guide can help organize smaller response units. Smaller units can improve recovery, but they do not make an unauthorized clause acceptable to submit.

At the transport boundary, distinguish queued locally, accepted by a provider, and observed through the provider's documented playback events. An output clear can prevent some future buffered output without undoing speech already heard.

If the system discovers a person change after private speech was submitted, report what the evidence establishes. Avoid claiming acoustic non-disclosure based only on a local queue deletion or a successful clear request.

The latency boundary guide shows how to preserve event boundaries. For isolation, use the same discipline to avoid subtracting unrelated clocks or describing one transport event as proof of a human experience.

Test unavailable verification separately from failed verification. An outage can justify a public fallback or a different approved verification route, while a failed check should not trigger repeated guesses against private records.

Do not expose detailed internal denial reasons to an unverified caller. Engineers need controlled diagnostics, but the caller-facing response should avoid confirming which subjects, accounts, or historical tasks exist.

Record the trusted authority source and revision used by each test. A derived outcome such as wrong_owner is useful, while the original scope values explain whether the selector, adapter, or current-state supplier made the error.

Keep the fixture's synthetic endpoint identity stable across runs. Changing endpoint, subject, tenant, question, and source together can hide the specific defect the test is meant to catch.

When a failure appears, identify the first boundary where another subject's canary became visible. Fix that shared cause rather than adding a phrase filter to each greeting, summary, and spoken answer separately.

A phrase filter can miss paraphrases and can suppress innocent public text that happens to resemble the canary. Ownership enforcement belongs before private evidence is selected and again before prepared work is admitted under current authority.

The voice regression guide supplies the durable replay approach. Retain the failing fixture so a later refactor cannot restore endpoint-keyed reuse behind a different helper or cache implementation.

For release review, list the private paths exercised and the paths still outside the test. Passing the in-memory example proves its local contract, while real database roles, external indexes, authentication, and live audio need separate adapter evidence.

That bounded report is more useful than a blanket claim that memory is secure. It tells the next engineer which assumptions are verified, which policies are explicit, and where another independent data path could still bypass the intended owner boundary.

Preserve isolation during ordinary maintenance

An identity boundary can regress during a seemingly routine cache or logging change. Require migration tests to preserve tenant and subject scope when keys, namespaces, summaries, or record schemas change.

A compatibility fallback deserves special attention. If a new scoped lookup misses, falling back to an old endpoint-keyed entry can recreate wrong-person recall even though every new write uses the correct ownership fields.

Treat an old entry with missing ownership as ineligible for private reuse. Recollect through the authorized source path or use an explicit reviewed migration rather than guessing which person the historical value belonged to.

Test privileged maintenance roles separately from application roles. A database owner or migration job can legitimately bypass ordinary row policies, so verify that its output does not enter an unrestricted cache or response path afterward.

An export and restore can create the same problem. Preserve the ownership fields and current eligibility evidence needed for the restored system, and reject records whose scope cannot be established under the destination's identity mapping.

For an ordinary support workflow, use synthetic canaries or scoped diagnostic access. A broad production search for matching phone numbers can expose multiple people's records while investigating the very isolation problem it is supposed to repair.

Keep the accepted product policy visible during incident fixes. If account-wide recall is intentionally allowed for a narrow record class, do not silently remove it because another private class leaked; repair the specific ownership and eligibility boundary with evidence.

Conversely, a historical convenience is not an explicit authorization policy. Where a path only happened to reuse endpoint history, replace it with a trusted scope decision before presenting that behavior as supported personalization.

The release proof should name the changed path and the negative fixture that now blocks cross-caller reuse. Preserve the remaining limitations so a local fix does not become an unsupported claim about every transport, store, or identity scenario.

---

Frequently asked questions

Why is a phone number an unsafe memory owner?

A phone number can be shared, forwarded, handed to another person, or reassigned. It helps route a call but does not establish the current human's entitlement to another person's private history.

Can a signed webhook verify the caller?

A valid webhook signature establishes the request's origin under the provider contract. It does not authenticate the human speaking or grant permission to recall a particular person's private memory.

What should happen before identity verification?

The agent can provide public help and neutral routing. Keep private memory and its existence withheld until the required identity and authorization checks succeed for the present task.

Is a matching name enough?

A matching or similar name can help locate a candidate for verification. It should not be the final authorization decision, because names can collide, be misrecognized, or be supplied by someone without access.

Can voice similarity establish authority?

Voice similarity is evidence from a recognition task and needs its own validated risk policy. Do not treat a model confidence value as an automatic permission grant for private recall or business action.

Why include tenant and subject?

A subject identifier can be unique only inside one tenant. Exact tenant and subject scope prevents collisions and keeps a shared cache or index from treating unrelated local identifiers as the same owner.

Why include session and revision too?

Session and authority revision bind prepared work to the current access context. A result from an earlier session or pre-revocation state stays stale even when the same subject later returns.

Should private filtering happen before the model?

Apply trusted scope before private candidates enter the model or broad result consumer. A final spoken-text filter cannot undo unauthorized evidence already sent to a prompt, telemetry service, or cache.

Is row-level security enough?

Row-level security can enforce an important database boundary when configured and used correctly. Verify privileged-role bypasses and every query path, then cover derived stores and current session authority separately.

Can a vector namespace replace authorization?

A namespace can organize records but needs a trusted access path that chooses and enforces it. Generated tool arguments or caller speech should not be able to select another person's private namespace.

What if the phone changes hands mid-call?

Invalidate dependent work when the trusted person or access context changes, and establish the new scope before private recall. Old prepared responses must fail final admission rather than being relabeled as the new caller's evidence.

Can a cached answer leak correctly stored memory?

A cache keyed by endpoint or question can bypass an otherwise correct memory store. Scope every derived private representation and recheck current authority before reusing text, summaries, embeddings, or audio.

How should delegated callers be represented?

Keep the verified actor separate from the record subject and attach the allowed purpose and action. An explicit relationship grant can authorize a narrow task without exposing all historical memory by default.

Does account access imply access to personal memory?

Shared account permissions do not automatically cover each user's personal preferences or prior conversations. Define account-wide and person-specific data separately and enforce the current relationship for the requested purpose.

Why does the sample omit phone numbers?

The sample makes phone routing irrelevant to private authority so two people can share an endpoint without sharing records. A real transport adapter can retain an endpoint reference for routing while keeping it outside the ownership key.

What does the asynchronous fixture verify?

It holds a scoped recall, changes current authority to another subject, then releases the result. The final gate rejects the old authority and returns no private values under the changed context.

Can old cached success restore revoked access?

A historical successful lookup cannot renew current authority. Exact retries must check the present stale, revoked, canceled, or closed disposition before any private text or audio is admitted.

What should an isolation trace contain?

Keep call, endpoint, session, tenant, subject, authority revision, selected owner, and disposition distinct. Record minimal private content and preserve controlled reproduction evidence rather than copying another person's conversation into broad logs.

What remains outside the reference program?

The program does not authenticate a caller or implement consent, expiry, database roles, distributed atomicity, or physical playback. Those adapters need their own tests before the complete system can claim private-recall isolation.

Where should the first regression test start?

Create two synthetic subjects on one endpoint with distinct harmless canaries. Assert that unverified and second-subject calls cannot receive the first canary through selection, summaries, caches, greetings, or queued output.

Prove isolation before personalization

Trace one private memory from its owner through retrieval, prepared response, and final output admission. Use the shared-endpoint fixtures to prove that every derived path preserves the current verified subject and authority revision.

Then add the record's purpose, consent, freshness, and expiry checks. A useful personalized response is one whose evidence and eligibility can be explained at the boundary where disclosure would occur.