@integrity-labs/agt-cli 0.28.1030 → 0.28.1031

package/dist/{chunk-VUC5XNUP.js → chunk-TFFXAGBJ.js}

@@ -5509,7 +5509,10 @@ var FLAG_REGISTRY = [
     // Disabling this RESTORES the shared host-wide key to every container, and
     // with it the cross-agent credential read ENG-8992 closes. A credential-scope
     // reduction should not be one click away without confirmation — same posture
-    // as `github-broker-credentials`, the other credential-delivery flag.
+    // as the credential-delivery flags `github-broker-credentials` and
+    // `xero-broker-credentials`. (This said "the OTHER credential-delivery flag"
+    // while there was one; ENG-10939 added the second, so the singular had to go
+    // rather than silently become a claim that github is the only sibling.)
     sensitive: true,
     // The reader is host-side (`hostFlagStore().getBoolean(...)` in the manager),
     // so a host on an older agt-cli has no consumer code: it keeps forwarding the
@@ -6656,6 +6659,12 @@ var FLAG_REGISTRY = [
     // are the precedent: pinned ABOVE every published release ON PURPOSE,
     // labelled as a placeholder, and gated on a post-publish bisect.
     //
+    // ENG-10939: `xero-broker-credentials` is the worked example of the other
+    // half of that convention - the bisect that DISCHARGES a placeholder. Its
+    // `since` is a real published version read off `npm pack` tarballs, with the
+    // markers it was bisected on written down, so the two entries together show
+    // both states this field is allowed to be in.
+    //
     // (This cited `claudecode-agt-bin-credential-helpers` until obi-wan
     // `8f9d3c43076c` pointed out no such key exists anywhere in the repo - the
     // only occurrence in the tree was this citation. The precedent was real and
@@ -7422,6 +7431,56 @@ var FLAG_REGISTRY = [
     // flips); shipping a guessed number is not.
     since: "0.29.0"
   },
+  {
+    key: "xero-broker-credentials",
+    description: 'Deliver the Xero OAuth access token to the vendor Xero MCP server through the broker credential endpoint at USE time, instead of materializing it onto the agent host at spawn (ENG-10939, step 1 of the Xero lockdown ENG-10927). Mechanically the sibling of `github-broker-credentials`; the REASON and the cost of a bad flip are both different. ON: POST /host/agent-integrations strips `access_token`, `refresh_token` and `token_expires_at` from the xero row and marks it credential_delivery=broker, so XERO_ACCESS_TOKEN stops being written to .env.integrations. Nothing replaces it host-side and nothing needs to: the vendor MCP server has fetched a fresh token per call from POST /host/agent-integrations/:id/credential since ENG-4920, and `brokerMode` is true for every install carrying an id - so XERO_CLIENT_BEARER_TOKEN: ${XERO_ACCESS_TOKEN} is already not emitted and no dangling reference is left behind. `granted_scopes` and `read_only` are deliberately KEPT: they are consent metadata the host reports scope drift from, not credentials. OFF (default): byte-for-byte today\'s behaviour. WHY THIS IS NOT THE GITHUB FLAG. For github, an under-`since` host on a flipped flag LOSES `git`/`gh` - an outage. For xero the equivalent host LEAKS: before ENG-10939 the ENG-8344 broker guard was a loop-level `continue` that also skipped the config-derived env vars, so a broker-marked xero row dropped XERO_TENANT_ID, and per ENG-4898 the vendor MCP server then falls back to `tenants[0]` - a CROSS-TENANT DATA LEAK with no error anywhere. The dangerous fleet is therefore an INTERVAL, not "old hosts", and BOTH edges are bisected from published tarballs rather than named by issue: below agt-cli 0.28.508 a host carries no `credentialDelivery` handling at all, so it ignores the marker and is SAFE; from 0.28.508 up to (not including) 0.28.1015 it honours the marker with the WIDE skip and LEAKS; at 0.28.1015 and above the skip is narrowed and the behaviour is correct. `since` is a lower bound, so it classifies BOTH ends of that interval as `stale` and cannot tell a safe pre-0.28.508 host from a leaking-middle one. THE FLIP GATE IS THEREFORE NOT "the modal shows reach": it is zero xero-bearing hosts below 0.28.1015 per hosts.agt_version, counting NULL and stale as UNCONVERGED (the heartbeat writes that column conditionally on presence, so a host that stopped reporting keeps its last value - the async-export-rollout pattern). AND A SECOND GATE THE MODAL CANNOT SEE AT ALL: the rewritten Xero skills (ENG-10961) must be live in the catalog AND have reached hosts BEFORE this is flipped. Reversed, a host has no token while its own skills still tell it to read one - a silent read outage with no error at the write site. The catalog reaches prod through `pnpm db:catalog:seed` on deploy, not through the code deploy itself, so "merged" is not "live". EXPECTED ON FLIP DAY, so it is not a surprise: the payload shrinks, so computeIntegrationsHash moves once and XERO_ACCESS_TOKEN reads present->absent in the env diff. That does NOT respawn the session. `liveProxyTokenVars` collects AGT_REMOTE_MCP_TOKEN_VAR from .mcp.json (= XERO_ACCESS_TOKEN in broker mode) and the manager filters it out of `respawnVars` BY NAME, kind-blind - so a removal is exempt on exactly the same line a rotation is (ENG-8264). The ENG-5318 child-kill path is likewise unreachable, because broker mode never emits the ${XERO_ACCESS_TOKEN} reference the stale-mcp-reaper keys on. Both restart paths that touch this var are already quiet. Evaluated API-side only, per agent, in POST /host/agent-integrations. The host does not read this flag - it keys off the resulting credential_delivery marker - so there is deliberately NO host-side envVar that could put the token back on its own. Roll back from the flag.',
+    flagType: "boolean",
+    // Declared safe value is `false` = today's env delivery. Fail-safe here is
+    // not symmetrical with github's: OFF leaves a credential on the host (bad,
+    // but the status quo this epic is closing), while a wrongly-ON flip on an
+    // under-`since` host LEAKS ANOTHER TENANT'S DATA. `false` is still the right
+    // default, because the ON path is the one with a reach precondition — but
+    // the reason is "do not arm this until the fleet is measured", not "a flag
+    // blip must not break the agent".
+    defaultValue: false,
+    // Flipping ON changes how every Xero agent on the scope authenticates, and
+    // on an unconverged host it is a cross-tenant leak rather than an outage. A
+    // deliberate, confirmed action (ADR-0022 §4).
+    sensitive: true,
+    // A REAL bisected threshold, not the placeholder `github-broker-credentials`
+    // and `per-agent-host-credentials` had to ship with: the host-side code this
+    // flag depends on (ENG-10939 item 0, narrowing the ENG-8344 broker guard so
+    // it skips the CREDENTIAL and not the whole row's config) landed in PR #6443
+    // and has already published.
+    //
+    // Read off the published tarballs rather than inferred from the merge
+    // timestamp. #6443 merged at 2026-09-24T01:54:41Z; 0.28.1015 published at
+    // 01:59:23Z. `npm pack` of 0.28.1013/1014/1015/1016 + grep of the extracted
+    // bundle agrees in both directions on four independent markers:
+    //   0.28.1014 — `writeTokenFile` present (4 files), `isRespawnExemptEnvVar`
+    //               and `RESPAWN_EXEMPT_CONFIG_TAILS` absent, and the only
+    //               broker-guard spelling is `credentialDelivery === "broker"`
+    //               (the wide skip).
+    //   0.28.1015 — `writeTokenFile` gone, both new exports present, and
+    //               `credentialDelivery !== "broker"` (the narrowed block form)
+    //               appears for the first time.
+    // The `!==` form is the one that matters: it is the guard that keeps
+    // XERO_TENANT_ID on a broker-marked row, i.e. the thing whose absence is the
+    // ENG-4898 leak.
+    //
+    // The interval's OTHER edge was bisected the same way, so the description
+    // above can name a version instead of an issue: `credentialDelivery` appears
+    // in no file of 0.28.507 and in five files of 0.28.508, so ENG-8344's marker
+    // handling first shipped in 0.28.508. A host below that is genuinely safe
+    // rather than merely old — it has no code to honour the marker with.
+    //
+    // Same caveat as every other `since` in this registry: it is ADVISORY. It is
+    // read only by `computeFlagReach` behind GET /flags/admin/reach, so it
+    // changes what an operator is TOLD and does not stop a flip on an
+    // under-`since` host. What holds the line is `defaultValue: false`, plus
+    // `sensitive: true`, plus the two gates spelled out in the description.
+    since: "0.28.1015"
+  },
   {
     key: "help-kb-auto-grant",
     description: "Auto-grant the `augmented-help-kb` integration at ORG scope when an organization is provisioned (ENG-8542), so every agent in that org gets product-doc search without a per-agent operator action. One organization_integrations row reaches every agent in the org: POST /host/agent-integrations merges org -> team -> agent and buildMcpJson's predicate reads that merged set with no scope filter. ON: the two org-provisioning call sites write the row (status=active, created_by=the org owner). OFF (default): they write nothing - byte-for-byte today's behaviour. STAGED ROLLOUT IS THE POINT. ENG-8332 argues against widening distribution of the help KB until two things close, because distributing a corpus with wrong articles \"converts one agent's wrong answer into everyone's\": (1) a live 200 from GET /host/kb/search as the anon role has still never been observed - ENG-7260 was closed on remediation evidence, not on a live call, and the deploy seed log is SERVICE-ROLE evidence that says nothing about the anon grant; (2) the `site-structure` article is unverified against the current IA. Turning this on for ONE org and watching that org's help-kb connectivity-probe verdicts (ENG-8332 added a real mcp_stdio probe that calls search_knowledge_base) is the cheap positive control for (1) - an ENG-7260-class 500 then reports as `down` per agent instead of as silence. Widen only after it comes back healthy. REVOKING IS DELETING THE ROW, not flipping this off: the flag gates GRANTING, so an already-granted org keeps its row when the flag goes off. Evaluated API-side only, per org, inside grantHelpKbToOrg; no host-side envVar and deliberately no sst.config.ts entry (a literal default there would pin it - ENG-8303).",
@@ -15491,4 +15550,4 @@ export {
   peekCurrentSession,
   readDailySessionPin
 };
-//# sourceMappingURL=chunk-VUC5XNUP.js.map
+//# sourceMappingURL=chunk-TFFXAGBJ.js.map