sixfold-space/madtea

SHA256

Fork 0

feat(mcp): madt_auth_whoami dir= - report the smallest-scope identity for a target checkout #155

New issue

Closed

opened 2026-07-16 16:23:39 +00:00 by hexajon · 3 comments

hexajon commented

2026-07-16 16:23:39 +00:00

(Migrated from codeberg.org)

Context

auth whoami should answer from the smallest-scope identity: run against a subdir repo, it reports THAT repo's identity.

The CLI already behaves this way (checked 2026-07-16 in a multi-forge workspace): run from a clone root or any subdirectory of it, whoami reports that clone's own identity and credential source, per clone, across forges. The cwd-based resolution chain (ADR 0025) gives the CLI smallest-scope resolution for free.

The gap is the MCP surface: madt_auth_whoami takes only owner_repo and resolves identity against the server's launch-fixed scope. In a workspace-root launch (multi-repo layout), there is no way to ask "which identity would operations on THIS checkout use" - whoami answers for the launch scope / session forge instead.

Ask

A dir= form on madt_auth_whoami (DirScope embed) that reports the identity the resolution chain WOULD use for that checkout: url, user, source (masked token indicator at most), matching what the CLI reports from that cwd.

Boundary constraint (ADR 0027 - decide the shape before building)

dir= must never become a token selector. The two legs of today's whoami sit differently under that rule:

Local resolution report (url/user/source from the target dir's chain): reads my own config; no foreign token gets used. Looks admissible - but ADR 0027 rejected foreign-credential use "even for read-only calls" on the API plane, so this needs an explicit decision, not an assumption.
Server-side verification + scope audit (GET /user, scope probes): with a foreign checkout's token these hit user endpoints - exactly the class the boundary forbids (never user/org endpoints, only the checkout's own origin repo). The dir= form should skip server verification entirely, or verify only when the target resolves to the same credentials as the launch scope.

Depends on the #90/#59 enforcement work for the sanctioned resolution/refusal shapes; the parity test pinning foreign-credential resolution sites must cover whatever this adds.

Acceptance

madt_auth_whoami dir=<subdir repo> reports that checkout's identity (url/user/source), matching CLI whoami run from that dir.
No foreign-token API call unless the decision above explicitly admits one; record the chosen shape here.
Parity/dirscope guards updated for the new dir-taking surface.

## Context `auth whoami` should answer from the smallest-scope identity: run against a subdir repo, it reports THAT repo's identity. The CLI already behaves this way (checked 2026-07-16 in a multi-forge workspace): run from a clone root or any subdirectory of it, whoami reports that clone's own identity and credential source, per clone, across forges. The cwd-based resolution chain (ADR 0025) gives the CLI smallest-scope resolution for free. The gap is the MCP surface: `madt_auth_whoami` takes only `owner_repo` and resolves identity against the server's launch-fixed scope. In a workspace-root launch (multi-repo layout), there is no way to ask "which identity would operations on THIS checkout use" - whoami answers for the launch scope / session forge instead. ## Ask A `dir=` form on `madt_auth_whoami` (DirScope embed) that reports the identity the resolution chain WOULD use for that checkout: url, user, source (masked token indicator at most), matching what the CLI reports from that cwd. ## Boundary constraint (ADR 0027 - decide the shape before building) `dir=` must never become a token selector. The two legs of today's whoami sit differently under that rule: - **Local resolution report** (url/user/source from the target dir's chain): reads my own config; no foreign token gets used. Looks admissible - but ADR 0027 rejected foreign-credential use "even for read-only calls" on the API plane, so this needs an explicit decision, not an assumption. - **Server-side verification + scope audit** (`GET /user`, scope probes): with a foreign checkout's token these hit user endpoints - exactly the class the boundary forbids (never user/org endpoints, only the checkout's own origin repo). The dir= form should skip server verification entirely, or verify only when the target resolves to the same credentials as the launch scope. Depends on the #90/#59 enforcement work for the sanctioned resolution/refusal shapes; the parity test pinning foreign-credential resolution sites must cover whatever this adds. ## Acceptance - `madt_auth_whoami dir=<subdir repo>` reports that checkout's identity (url/user/source), matching CLI whoami run from that dir. - No foreign-token API call unless the decision above explicitly admits one; record the chosen shape here. - Parity/dirscope guards updated for the new dir-taking surface.

hexajon commented

2026-07-17 19:27:54 +00:00

(Migrated from codeberg.org)

Labelled status/needs-decision + security, with the decision now grounded in the ADR 0027 text rather than a general "boundary question":

ADR 0027 pins that the launch scope is the credential scope and dir= never selects a token, with exactly two carve-outs (contribute via the worktree flow; cross-repo issue REPORTING), both bound by the invariant that a foreign checkout's credentials may only authenticate operations against that checkout's own origin.

What this issue asks for - madt_auth_whoami dir= reporting the identity a checkout WOULD use - is neither carve-out. It performs no foreign-credential API call (pure local config resolution, no token bytes), which argues it is admissible as a read. The counter-argument from the ADR's own threat model: the ruling exists because "an agent that treats every authed clone on disk as an available identity is one cd away from every account configured on the machine" - and a dir= identity report is precisely the inventory step of that attack: it enumerates which checkouts hold working auth and for which forge/user, making the machine's identity map one loop away.

The decision: (a) admissible read - local resolution only, no server verification, documented as outside the two carve-outs but harmless because it authenticates nothing; (b) inadmissible - the inventory capability itself is the risk, refuse dir= on whoami and keep identity questions launch-scoped; or (c) admissible but degraded - report only THAT credentials resolve (a boolean + source label), never which user/forge, blunting the inventory value. A security-model call for the maintainer; (b) is the conservative reading of the ADR's spirit, (a) of its letter.

Labelled status/needs-decision + security, with the decision now grounded in the ADR 0027 text rather than a general "boundary question": ADR 0027 pins that the launch scope is the credential scope and dir= never selects a token, with exactly two carve-outs (contribute via the worktree flow; cross-repo issue REPORTING), both bound by the invariant that a foreign checkout's credentials may only authenticate operations against that checkout's own origin. What this issue asks for - madt_auth_whoami dir= reporting the identity a checkout WOULD use - is neither carve-out. It performs no foreign-credential API call (pure local config resolution, no token bytes), which argues it is admissible as a read. The counter-argument from the ADR's own threat model: the ruling exists because "an agent that treats every authed clone on disk as an available identity is one cd away from every account configured on the machine" - and a dir= identity report is precisely the inventory step of that attack: it enumerates which checkouts hold working auth and for which forge/user, making the machine's identity map one loop away. The decision: (a) admissible read - local resolution only, no server verification, documented as outside the two carve-outs but harmless because it authenticates nothing; (b) inadmissible - the inventory capability itself is the risk, refuse dir= on whoami and keep identity questions launch-scoped; or (c) admissible but degraded - report only THAT credentials resolve (a boolean + source label), never which user/forge, blunting the inventory value. A security-model call for the maintainer; (b) is the conservative reading of the ADR's spirit, (a) of its letter.

hexajon commented

2026-07-17 19:30:30 +00:00

(Migrated from codeberg.org)

I think read-only and ONLY for whoami is an okay scope. CLI operator (agent or human) can already move around through directories checking git configs/creds. if they want. We rely on the underlying operating system/user permissions and this is more for user or agent orientation or confirmation that the repo creds match expectations and requirements

hexajon commented

2026-07-17 19:32:03 +00:00

(Migrated from codeberg.org)

Decision recorded, label cleared - this is now workable. Pinned shape for the builder:

madt_auth_whoami accepts dir= and reports the identity that checkout's resolution chain WOULD use: url, user, source labels (and the resolution-chain rungs whoami now renders), from LOCAL config resolution only. No token bytes, no masked-token indicator beyond source names.
NO server-side call authenticates with the target checkout's credentials: the dir= form skips live verification, the repo probe, and the scope check entirely (or runs them only when the target resolves to byte-identical credentials as the launch scope). The output labels the result as local resolution, unverified.
Scope is whoami ONLY - dir= remains a repo selector, never a token selector, everywhere else; the decision here creates no precedent for other tools. Rationale as ruled above: a CLI operator (agent or human) can already walk directories reading git config; the operating system's own permission model is the boundary, and this exists for orientation and confirming a checkout's credentials match expectations.
Implementation notes the decided shape in a one-line ADR 0027 amendment (a third enumerated read-only carve-out, whoami-scoped), and the parity/dirscope guards cover the new dir-taking surface per the acceptance list.

Decision recorded, label cleared - this is now workable. Pinned shape for the builder: - madt_auth_whoami accepts dir= and reports the identity that checkout's resolution chain WOULD use: url, user, source labels (and the resolution-chain rungs whoami now renders), from LOCAL config resolution only. No token bytes, no masked-token indicator beyond source names. - NO server-side call authenticates with the target checkout's credentials: the dir= form skips live verification, the repo probe, and the scope check entirely (or runs them only when the target resolves to byte-identical credentials as the launch scope). The output labels the result as local resolution, unverified. - Scope is whoami ONLY - dir= remains a repo selector, never a token selector, everywhere else; the decision here creates no precedent for other tools. Rationale as ruled above: a CLI operator (agent or human) can already walk directories reading git config; the operating system's own permission model is the boundary, and this exists for orientation and confirming a checkout's credentials match expectations. - Implementation notes the decided shape in a one-line ADR 0027 amendment (a third enumerated read-only carve-out, whoami-scoped), and the parity/dirscope guards cover the new dir-taking surface per the acceptance list.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#155

No description provided.

Rows
Columns