approvals: an overlay teammate cannot be scoped, so it silently holds the company's widest grant

[oxoxDev]

Problem

OverlayAgent (src/ports/types.rs:2104) carries only id, name, role, description. There is no tools field, so an operator-added teammate cannot be scoped at all.

Both the harness and the console resolve that absence to the same thing — the widest grant the company has:

// src/harness/mod.rs:2014
fn overlay_agent_to_manifest(overlay: &OverlayAgent) -> ManifestAgent {
    ManifestAgent { id, role, description, tier: None, tools: Vec::new(), budget_usd_daily: None }
}

src/server/ops/team_agent.rs:346 mirrors it deliberately — "no per-agent tool line: it holds the company's standard grant". Empty tools then falls through agent_effective_grants to the full company allow. That inheritance rule is #264 working as designed and is not what this issue disputes.

The gap is narrower: a manifest teammate can be scoped with a tools line in company.toml; an overlay teammate has nowhere to write one. Every overlay teammate holds everything the company holds, permanently.

Why it matters now rather than later

add_agent is declared Reach::Nothing (src/policy/consequence.rs:169) and sits in INTRINSIC_TOOLS (src/harness/steps.rs:491), so it is always present and never asks. A model can therefore mint a teammate that holds the company's full grant with no approval anywhere in the path.

That is tolerable only while every write still parks per call. It stops being tolerable the moment #560 lands a broader policy tier or #563 lands durable allow rules: an overlay teammate would silently inherit the widest standing grant in the company, and there would be no way to express "this one is read-only". The scoping hole should close before, or with, whichever of those lands first.

Scope

1. Add an optional tools field to OverlayAgent, serde-additive (skip when empty) so existing company records serialise byte-identically.
2. Thread it through overlay_agent_to_manifest and the team_agent.rs projection in lockstep — if they drift, the console shows a grant the harness does not honour, which is the exact failure feat: an agent has no detail view — cannot be opened, read, or edited #264 exists to prevent.
3. Decide what add_agent may set. Recommendation: a model-minted teammate defaults to no wider than the minting agent's own effective grant, rather than to the company's.
4. Console: the teammate detail view should state where a teammate's grant came from — an explicit line, or inherited company allow — so an operator can tell a scoped teammate from an unscoped one by looking.

Out of scope

The empty-means-inherit rule itself (#264). That is correct and stays. This issue is only about being able to write a non-empty value for an overlay teammate.

[M3gA-Mind]

Verified satisfied on main @ cae21623. Closing.

Checked each of this issue's own scope items against the code that actually shipped, not
against the PR descriptions — and ran a positive control for every mechanism, because
passing tests alone cannot distinguish "the mechanism works" from "no test binds it".

Scope item by scope item

#	Requirement	Delivered by	Where it lives on main
1	optional tools on OverlayAgent, serde-additive	#713	ports/types.rs — #[serde(default, skip_serializing_if = "Vec::is_empty")], so a standard-grant teammate serialises exactly as before
2	threaded through the readers in lockstep	#713 + #745	harness/mod.rs overlay_agent_to_manifest, server/ops/team_agent.rs projection, and server/ops/mcp.rs roster_grants
3	add_agent no wider than its minter	#745	harness/orchestrator.rs AddAgentTool
4	console states where a grant came from	#713/#745	frontend/src/views/team/AgentDetailView.tsx + lib/agent.ts

There were three readers, not two. The issue named the harness and the console; roster_grants
in mcp.rs was a third, and it was hard-coded empty until #745 (filed as #740). Without it a
scoped teammate still read back as reaching every enabled MCP server — the console asserting a
connection the harness does not grant. Worth recording, because item 2's "in lockstep" argument
was right for a reason the issue had not fully enumerated.

Item 3 landed as two paths, both bounded. tools omitted mints the minter's own line
(so an unscoped minter still mints an unscoped teammate, and the teammate keeps tracking
[tools].allow rather than freezing today's list); an explicit list is narrowed to the
minter's effective grant, and a request entirely outside it is refused with a message naming
what the minter holds. That last branch matters: an empty narrowing result stored as tools
would read back as "inherit the whole company grant" — the exact inversion this issue exists
to remove.

Item 4 is a real line, not just a DTO field: the detail view says either "This agent lists
no tools of its own, so it holds everything the company allows" or "What this agent asked
for, narrowed by what the company allows", and separately lists what was asked for and
dropped.

Beyond the four: the overlay fingerprint hashes tools (so a re-grant rebuilds the roster
instead of being ignored until restart), PATCH …/team/{id} allows narrowing after creation,
and the mint is logged with its minter.

Evidence

Eleven tests, each run with its own filter — every one selected exactly 1 of 3390, so none was
a filter matching nothing:

overlay_agent_to_manifest_carries_the_tool_grant                ok
overlay_fingerprint_moves_on_a_tools_only_edit                  ok
a_minted_teammate_is_bounded_by_its_minter_not_the_company      ok
an_explicit_scope_is_narrowed_to_what_the_minter_holds          ok
a_scope_entirely_outside_the_minters_grant_is_refused           ok
an_unscoped_minter_mints_an_unscoped_teammate                   ok
add_agent_tool_empty_tools_is_the_standard_grant                ok
a_scoped_overlay_teammate_does_not_read_back_as_reaching_everything  ok
an_unscoped_overlay_teammate_still_inherits_the_company_grant   ok
requested_grants_reads_overlay_then_manifest_then_empty         ok
editable_names_tools_only_for_an_admin                          ok

Positive controls — each mechanism broken in turn, to prove a test actually binds it:

control	test that caught it
harness reader ignores overlay.tools	overlay_agent_to_manifest_carries_the_tool_grant — FAILED
roster_grants ignores overlay.tools	a_scoped_overlay_teammate_does_not_read_back_as_reaching_everything — FAILED
fingerprint stops hashing tools	overlay_fingerprint_moves_on_a_tools_only_edit — FAILED
explicit scope not clamped to the minter	an_explicit_scope_is_narrowed_to_what_the_minter_holds, a_scope_entirely_outside_the_minters_grant_is_refused — 2 FAILED
omitted tools reverts to the company grant	a_minted_teammate_is_bounded_by_its_minter_not_the_company — FAILED

Console side: frontend/test/unit/agent-detail.test.ts asserts standardGrant both ways, and
frontend/test/e2e/agent-detail.spec.ts covers the rendered list.

One thing that is NOT part of this closure

#745's 403/404 ordering fix did not reach main: 8f1ab438 is not an ancestor of
cae21623, require_admin still runs before the existence checks in edit_agent, and there
is no ordering test on main (0 occurrences). A non-admin PATCHing a teammate that does not
exist therefore gets a 403 rather than a 404.

That is a defect of the narrowing route's error semantics and belongs to #740/#745's
follow-up, which is going up separately. It is not one of this issue's acceptance criteria
— it does not affect whether a teammate can be scoped, whether all three readers honour the
scope, whether add_agent narrows, or whether the console names the provenance. Flagging it
explicitly so this closure is not read as covering it.

Closed as completed by #713 (scoping, fingerprint, two readers) and #745 (the third
reader, the add_agent clamp, post-creation narrowing, observability). #745 linked
Closes #740 only, which is why this stayed open.