@integrity-labs/agt-cli 0.28.906 → 0.28.908

package/dist/mcp/augmented-admin.js

@@ -21877,7 +21877,7 @@ server.registerTool(
 );
 server.registerTool(
   "debug_query_audit_log",
-  { description: 'Read recent audit events to troubleshoot why/when agents bounced \u2014 primarily restart events. Defaults to the "agent.restart" action: each event returns { id, created_at, action, actor_kind, user_id, agent_id, organization_id, source, reason, detail, code_name, impersonated, impersonated_by_user_id, impersonated_agent_id, impersonation_session_id } \u2014 `user_id` is the identity the action was performed AS, `agent_id` the agent it was performed ON, `impersonated_by_user_id` the operator who was actually driving a user-impersonation session, and `impersonated_agent_id` the agent identity an operator was driving in the agent-impersonation flow (the two flows are distinct and a row carries at most one). `source` is the restart trigger (agent-self-request, channel-command, maintenance-window, stale-mcp, hot-reload-mcp, mcp-presence-reaper, day-rollover, auth-tuple-change, \u2026) and `reason` is the free-text rationale when one was given (e.g. the agent\'s own words for a request_restart). `detail` (ENG-8293) is the structured "what changed?" payload, null for sources that don\'t emit one. For `auth-tuple-change` it is { auth_tuple: { changed[], unchanged[], components[] } } naming WHICH credential/identity component moved and its before/after fingerprint \u2014 the auth tuple is deliberately NOT keyed on the rotating access token, so an auth-tuple-change is always a genuine credential or identity change, and `detail.auth_tuple.changed` is how you tell which one. Comparing `components[].to` across agents answers whether a restart WAVE was one control-plane push (same new value everywhere) or coincidental per-agent rotations. Two modes: (1) pass { agent_id } to scope to ONE agent (fails closed if you\'re not authorized for its org) \u2014 use when a specific agent went quiet. (2) OMIT agent_id for a CROSS-AGENT sweep across every org you\'re authorized for (optionally narrow with { org_id }) \u2014 use to spot fleet-wide restart storms or compare agents. Filter the action with `action` (pass "all" to drop the action filter and read every event type), and bound with { since_hours?, limit? }. Cross-agent results are org-walled in SQL; unauthorized orgs are invisible. ENG-9079 \u2014 IMPERSONATION: `user_id` is the identity an action was performed AS, which is not always who performed it. When `impersonated` is true an Integrity Labs operator was driving: `impersonated_by_user_id` is that operator and `impersonation_session_id` joins every action in the same session. `actor_kind` does NOT distinguish these \u2014 an impersonated user action still reads `user`, so read `impersonated`, not `actor_kind`, to answer "was this really the customer?". Two caveats an investigator must hold: rows written before ENG-9018 shipped (17 Aug 06:04Z) carry NULL because the information was never captured, so absence there is not evidence of a genuine customer action; and a small number of audit writers are still unthreaded, so `impersonated: false` on a recent row means "not recorded as impersonated", not "proven genuine".', inputSchema: queryAuditLogSchema },
+  { description: 'Read recent audit events to troubleshoot why/when agents bounced \u2014 primarily restart events. Defaults to the "agent.restart" action: each event returns { id, created_at, action, actor_kind, user_id, agent_id, organization_id, source, reason, detail, code_name, impersonated, impersonated_by_user_id, impersonated_agent_id, impersonation_session_id } \u2014 `user_id` is the identity the action was performed AS, `agent_id` the agent it was performed ON, `impersonated_by_user_id` the operator who was actually driving a user-impersonation session, and `impersonated_agent_id` the agent identity an operator was driving in the agent-impersonation flow (the two flows are distinct and a row carries at most one). `source` is the restart trigger (agent-self-request, channel-command, maintenance-window, stale-mcp, hot-reload-mcp, mcp-presence-reaper, day-rollover, auth-tuple-change, \u2026) and `reason` is the free-text rationale when one was given (e.g. the agent\'s own words for a request_restart). `detail` (ENG-8293) is the structured "what changed?" payload, null for sources that don\'t emit one. For `auth-tuple-change` it is { auth_tuple: { changed[], unchanged[], components[] } } naming WHICH credential/identity component moved and its before/after fingerprint \u2014 the auth tuple is deliberately NOT keyed on the rotating access token, so an auth-tuple-change is always a genuine credential or identity change, and `detail.auth_tuple.changed` is how you tell which one. Comparing `components[].to` across agents answers whether a restart WAVE was one control-plane push (same new value everywhere) or coincidental per-agent rotations. Two modes: (1) pass { agent_id } to scope to ONE agent (fails closed if you\'re not authorized for its org) \u2014 use when a specific agent went quiet. (2) OMIT agent_id for a CROSS-AGENT sweep across every org you\'re authorized for (optionally narrow with { org_id }) \u2014 use to spot fleet-wide restart storms or compare agents. Filter the action with `action` (pass "all" to drop the action filter and read every event type), and bound with { since_hours?, limit? }. Cross-agent results are org-walled in SQL; unauthorized orgs are invisible. ENG-9079 \u2014 IMPERSONATION: `user_id` is the identity an action was performed AS, which is not always who performed it. When `impersonated` is true an Integrity Labs operator was driving: `impersonated_by_user_id` is that operator and `impersonation_session_id` joins every action in the same session. `actor_kind` does NOT distinguish these \u2014 an impersonated user action still reads `user`, so read `impersonated`, not `actor_kind`, to answer "was this really the customer?". One caveat an investigator must hold: rows written before ENG-9018 shipped (17 Aug 06:04Z) carry NULL because the information was never captured, so absence there is not evidence of a genuine customer action. From ENG-9210 (13 Sep) every audit writer REACHABLE during an impersonation session is threaded, so on a row written after that, `impersonated: false` means the action was genuinely not impersonated. Writers that remain unthreaded are all classified `unreachable` \u2014 they cannot execute during an impersonation session at all (host-JWT and agent-MCP paths), so a NULL from them is correct rather than merely unrecorded.', inputSchema: queryAuditLogSchema },
   async (args) => {
     try {
       const result = await client.queryAuditLog(args);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/agt-cli",
-  "version": "0.28.906",
+  "version": "0.28.908",
   "description": "Augmented Team CLI — agent provisioning and management",
   "type": "module",
   "engines": {