Minimum Viable Audit

Module 7 candidate-extension audit · introduced in Lesson 7.2 · concept shape

What this is. The five-question audit every off-the-shelf extension passes before it is allowed into your register. If you cannot answer every question without guessing, you do not install.

How to use. Print one copy per candidate extension. Fill it in with the extension’s own documentation open beside you — manifest, description, changelog, repo. When complete, decide: Options A through E on the outbound matrix. File the completed worksheet at /capstone/extension-artifacts/audit-<extension-name>.md and reference it from the register row.

The off-the-shelf-first posture with its four carve-outs.

Prefer installing over authoring, unless: no off-the-shelf option fits, the permissions are too wide, the extension cannot pass this audit, or the workflow is genuinely novel. Then — and only then — you author your own.

Candidate:

Source URL:

Auditor:

Audit date:

Version audited:

Part 1 — Three-part read before the questions

Before answering any of the five questions, read these three artifacts. If the extension does not ship one of them, mark the cell missing and treat that as a partial answer to Q5.

Manifest

What the extension says it grants itself: tools, scopes, network calls. Look for the union if it is a plugin bundling multiple skills.

Description

What the extension says it does, and when. Read it as the classifier it will become. Note any of the three failure modes you see (vague / overfit / triggerless).

Changelog

What the author has changed recently. A flat or absent changelog is itself a data point. Look for widening permissions between versions.

Part 2 — The five audit questions

Q1 — what it does

What does the extension actually do, in one sentence?

Not what the marketing says — what the procedure actually executes. If you cannot write this sentence from the docs alone, the extension has failed the audit before it starts.

Q2 — what tools it grants

What tools, commands, and capabilities does installing give the agent?

Read the manifest. List every tool call. For plugins, list the union across all bundled skills. Shell execution, file write, network calls, scheduled triggers — each one matters.

Q3 — what data it reads

What data on my machine or in my accounts does the extension read?

Granted folder, specific files, Gmail labels, calendar scopes, keychain, environment variables. “Everything in the working folder” is a real and common answer — name it.

Q4 — what it sends out

What does the extension send outside my machine, and to whom?

A commonly-missed question. Network calls to the plugin author’s endpoint, LLM calls routed through a third party, telemetry, “anonymous” usage data — all count. “None” is a valid and common answer only if the manifest has no network scope.

Q5 — how it handles credentials

Whose credential runs this, and where do keys live?

Your API key? The plugin author’s? A shared team key? Rotated how often? Stored in plaintext, in the keychain, in an environment variable? An extension that reads .env files is a specific answer, not a vague one.

Part 3 — Outbound decision matrix

Once the five questions have real answers, choose one of the five options below. If the extension does not fit any option above D, the answer is D.

Option	When to choose it	Select
A. Install clean	Every question answered without guessing. Tool grant is narrow. Reads only what the workflow needs. Sends nothing, or sends only to an endpoint you control. Credentials are your own and rotatable. Use with default permissions.	□
B. Install drafts-only	Passes A’s bar except that the extension writes or sends on your behalf. Install with the extension’s “draft only” or “review before send” mode, never its auto-send mode. Carry the Module 5 “drafts, not sends” norm in.	□
C. Install with platform-scoped permissions	Passes A’s bar except that the default grant is too wide. Install only with tighter permissions that the platform supports (read-only OAuth, a single label instead of full Mail, a narrow folder grant). Document the tightening in the register.	□
D. Decline	At least one of Q1–Q5 could not be answered, or Q4 / Q5 came back with an answer that is incompatible with “audience = only you” and you cannot tighten the scope. File as a declined row in the register with the reason. This is the right answer more often than it feels.	□
E. Conscious override	You install despite a failed answer, for a specific reason you can name and put in writing. Requires: a write-up of why, a compensating control (a fence that makes the failure not reach you), a short “revisit by” date, and an honest conversation with a parent/instructor. Use rarely.	□

Part 4 — Decision write-up

Option chosen

□ A □ B □ C □ D □ E

One-sentence reason

Compensating control (required for B, C, and E)

What fence did you put around the install? A label-scoped OAuth, a project-scoped folder grant, a drafts-only mode, a weekly audit — name it and say where it lives.

Revisit-by date (required for D and E)

For D: when to re-check whether the extension has shipped a local-only mode or tighter scopes. For E: when the conscious-override expires.

Part 5 — Closeout

□ All three reads completed (manifest, description, changelog).
□ All five questions answered without “I’m not sure.”
□ Option chosen and recorded.
□ Compensating control named (if B / C / E) and documented in the register row.
□ Revisit-by date set (if D / E) and added to the next-review column of the register row.
□ Worksheet filed at /capstone/extension-artifacts/audit-<extension-name>.md.
□ Register row updated with Audit reference pointing at the filed worksheet.

Unanswerable question = audit failure. Audit failure = Option D. “Decline” is the most common correct answer in this audit.