D3 · Context, Tools and Permissions

The second of the two heaviest domains — 18%, about 9 of 50 items. It tests two paired judgments: giving an agent enough context and tools to succeed, and giving it no more access than the task needs. Under-provision and the agent guesses; over-provision and you have handed a capable, literal worker keys to rooms it never needed to enter. The material rewards least-privilege thinking applied to a workspace agent that acts on your behalf and inherits reach you may not have thought about.

What you need to know

An agent needs four kinds of context: the task brief (from D2), the source documents for this task, relevant company knowledge (policies, standards, product facts), and prior decisions so it doesn’t relitigate settled questions. It needs tools and connectors to reach data and take actions — but each one is capability and blast radius. Least privilege means granting the minimum context and access the task requires and widening only on evidence of need. A workspace agent acts with real reach into shared files, connectors and systems, so its scope must be set deliberately: what it can read, what it can write, and where it must stop. Context and access are the two halves of the same setup: the right context makes the agent competent; the right access makes it safe.

Learning objectives

By the end of this page you should be able to:

1. Identify the four kinds of context an agent needs and supply each from the right place.
2. Distinguish context the agent needs from noise that degrades its work.
3. Match tools and connectors to what the task actually requires.
4. Apply least-privilege thinking to an agent’s access, separating read from write and internal from external.
5. Scope a workspace agent deliberately, reasoning about the reach it inherits.
6. Diagnose whether a failure came from missing context or from missing access.

3.1 The four kinds of context

An agent starts with only what you give it plus what its tools can fetch. Missing context is the most common cause of confidently wrong work — the agent fills the gap with a guess.

        what the agent knows
        ┌───────────────────────────────────────────┐
        │  TASK BRIEF     (why + what + done)          │  you supply
        │  SOURCE DOCS    (the inputs for this task)    │  you attach
        │  COMPANY KNOW.  (how we do things here)       │  workspace provides
        │  PRIOR DECISIONS(what's already decided)      │  you point to
        └───────────────────────────────────────────┘
                 gaps here ─► the agent guesses to fill them

3.2 More context is not always better

Context has a cost. Dumping every document you have into the task buries the relevant signal and can actively mislead the agent toward whatever was longest or most recent. The skill is supplying what’s relevant and authoritative, not everything available.

The connection to D2’s sources of truth is direct: name what’s authoritative and supply that, rather than everything and hoping the agent sorts it out. When in doubt, supply the specific source document and the relevant slice of company knowledge — not the entire drive.

3.3 Tools and connectors: matching capability to the task

Tools are how an agent reaches beyond the text in front of it — search, file access, connectors to shared systems, the ability to draft or send. Provisioning is a matching exercise: what does this task genuinely require?

The pattern: read before write, draft before send, one system before many. Every step up that ladder adds capability and blast radius together, so take each step only when the task requires it.

3.4 Least-privilege thinking

Least privilege is the governing principle of the whole domain: grant the minimum access the task needs, and widen only on evidence of need. It is the opposite of the tempting “give it everything so it never gets stuck” default.

              blast radius
        low ◄──────────────────────────► high
        read one    read shared    write     send /
        document    system         data      publish / pay
        │           │              │         │
        start here ─┘              │         │
        widen only if a run        │         │
        actually needs it ─────────┴─────────┘
                                   gate anything on the right

Why it matters specifically for agents: an agent is autonomous and literal. If it can reach something, it may — to satisfy the goal — touch data or take an action you never intended. Narrow access means a misunderstanding stays contained. Broad access means a misunderstanding becomes an incident.

3.5 An agent inherits reach — think about what it can touch

A workspace agent acts on your behalf and through the connectors and permissions it’s been given. That means it can reach whatever those connectors reach — which may be more than the immediate task suggests. Before delegating, ask what the granted access actually exposes.

The principle: the agent’s reach is the union of the connectors you enable, and it will use any of them if the goal seems to call for it. Scope each connector to the narrowest slice that works.

3.6 Diagnosing missing context versus missing access

When an agent underperforms, distinguish the two failure families — the fixes are opposite.

Agent's output is wrong or incomplete
│
├─ Did it act on wrong/generic facts, go off-brand,
│  or reopen a settled question?         ──► MISSING CONTEXT
│                                             fix: supply the source doc /
│                                             company knowledge / prior decision
│
└─ Did it say it "couldn't access", stop short of a
   step, or fail to reach a needed system? ──► MISSING ACCESS
                                              fix: grant the specific tool/connector
                                              (least privilege), not everything

Confusing the two wastes effort: granting more tools won’t fix an off-brand answer (that’s context), and pasting more documents won’t fix “I don’t have access to the CRM” (that’s a connector). Read the symptom, then apply the matching fix.

Decision framework

Use the CARE provisioning checklist before every delegation: Context, Access, Reach, Evidence. Fill each and you provision an agent that is both competent and contained.

Apply it tomorrow: for any task, write the four rows. If Access or Reach is broader than the task needs, narrow it before you run — that is least privilege in practice.

Common mistakes

Scenario challenge

Scenario. Amara, a customer-success lead on ChatGPT Work, wants an agent to draft renewal-summary emails for twelve accounts up for renewal this quarter. She connects the agent to the shared customer drive and to the team inbox so it “has everything it needs”, and gives it the goal. The drafts come back citing an outdated pricing policy, referencing details from unrelated customers’ files, and one draft quotes an internal margin note that should never leave the company. Amara wonders whether the agent is simply unreliable for this kind of work.

Expert reasoning trace.

1. Separate context from access. Two distinct problems are tangled here: the outdated pricing policy is a context failure (it used stale knowledge), while referencing unrelated customers and quoting an internal margin note are reach failures (it touched data it should never have reached).
2. Fix the context gap with authoritative sources, not more tools. The outdated policy means the current pricing policy wasn’t supplied as authoritative company knowledge; the agent fell back on whatever it found. Supply the current policy and name it as the source of truth (D2).
3. Diagnose the over-provisioning. Connecting the whole shared drive and the whole team inbox handed the agent reach across every customer’s files and every internal thread. It’s a literal, autonomous worker: given a renewal task and access to everything, it pulled from everything.
4. Apply least privilege / scoping. The task needs, per account, that account’s file — not the entire drive. Scope the connector to the specific renewal folder or the twelve account records, and remove the inbox connector entirely (drafting emails doesn’t require read access to the inbox history). The internal margin note should never have been reachable.
5. Add the read/write and draft/send distinctions. The agent needs read access to account data and the ability to produce drafts. It does not need send — the emails should land as drafts for Amara to review and send, gating the one irreversible step.
6. Provision, don’t abandon. The agent isn’t “unreliable for this work”; it was mis-provisioned. Re-run with scoped read access to the right records, the current policy as authoritative context, draft-only output, and the internal note out of reach — and the same agent produces safe, on-policy drafts.

The point. “Give it everything so it has what it needs” caused both the leakage and the noise. The fix is CARE: supply the right context (current policy), scope access to the account records, check reach so internal notes are unreachable, and widen only on evidence — none of which requires a different model.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• An agent needs four kinds of context: task brief, source documents, company knowledge, prior decisions — gaps get filled with guesses.
• More context is not always better; excess buries the authoritative signal and can anchor the agent on the wrong source.
• Match tools to the task on the read→write→send ladder; each step up adds capability and blast radius together.
• Least privilege: grant the minimum access the task needs and widen only on evidence — “to be safe, give it everything” is always the trap.
• A connector exposes everything it reaches; a workspace agent inherits that reach and will use it, so scope each connector narrowly.
• Distinguish missing context (off-brand, generic, reopens decisions) from missing access (“can’t reach the system”) — the fixes are opposite.
• Use CARE — Context, Access, Reach, Evidence — to provision an agent that is both competent and contained.