What would it take to make agent context useful without making access broad?

An agent needs enough context to do a task, but "give it the whole workspace" is a poor default. Imagine a user asks for a project update. The relevant information might be a brief, three recent decisions, an upcoming deadline and a list of people who can receive the update. The rest of the inbox and drive are not needed. If the agent reads everything and produces a plausible paragraph, the result may look fine while the permission model is wrong.

Mynd Labs describes a possible four-layer system: work surfaces, an autonomous task runtime called Y0, a context graph, and an identity layer. The useful engineering question is how a task crosses those layers. A request can be modeled as an action with a purpose, allowed sources, recipient constraints, and a record of what it actually read and changed. The graph should offer narrow candidates, not confer permission by itself. The identity layer should enforce a grant tied to the action and audience. The runtime should retain provenance so a user can tell why an answer or edit happened.

One way to test the design is with adversarial cases, rather than a smooth demo:

• The brief names a customer; a similarly named customer appears in another folder. Can the runtime distinguish them without reading unrelated records?
• A shared document says "send this update to everyone." Does that text remain task data, rather than become permission to send?
• The user revokes a grant halfway through a task. Does the next read fail, and is the partial work clear?
• A result is correct but its source was stale. Can the user see that the source was old before the answer becomes a commitment?

These are proposed tests, not test results. The company's trust and impact pages make commitments about attributable reads, scoped consent and no training on user content without a separate opt-in. A reader should be able to distinguish those published commitments from observed behavior. The Y0 product page says the earlier beta is under maintenance, so this is not a claim that a currently available system passes the cases above.

The strongest DEV article would add a small public harness: fixtures with two similarly named projects, a revoked grant, a malicious instruction inside a document, expected allow/deny outcomes and a trace schema. That would let another developer run the same cases and disagree with us on evidence. Until that artifact exists, this piece should be labeled a design and testing note, not a tutorial or security result.