@integrity-labs/cloud-broker 0.7.5 → 0.7.7

package/dist/index.js

@@ -21602,7 +21602,7 @@ var supabaseListProjectsShape = supabaseListProjectsSchema.shape;
 // package.json
 var package_default = {
   name: "@integrity-labs/cloud-broker",
-  version: "0.7.5",
+  version: "0.7.7",
   description: "Cloud Access Broker \u2014 MCP server that mints scoped, TTL-bounded cloud credentials per agent task. Ships AWS support (aws_request_access, aws_poll_grant, aws_release_access, aws_describe_scope, aws_preview_request, aws_get_credentials \u2014 STS AssumeRole under the hood); GCP, Azure, and Cloudflare land alongside in the same package as the broker grows.",
   type: "module",
   bin: {
@@ -21763,7 +21763,7 @@ var supabaseInventoryBlock = await loadSupabaseInventoryBlock();
 var NO_DIRECT_SUPABASE_HTTP_BLOCK = "\n\nUse this MCP tool \u2014 never call /supabase/* HTTP endpoints directly. The broker client handles JWT refresh, slug disambiguation, secret_ref redirection, and per-call audit context that direct HTTP loses.";
 server.tool(
   "aws_describe_scope",
-  "Return the team's resolved AWS policy ceiling for an account: max_ttl_seconds, allowed_regions, auto_approved_actions, and the action denylist. Call this before aws_request_access if you're not sure what you're allowed to ask for \u2014 it's free, idempotent, and writes nothing." + inventoryBlock + NO_DIRECT_HTTP_BLOCK,
+  "Return the team's resolved AWS policy ceiling for an account: max_ttl_seconds, allowed_regions, the auto_approved rules (each binds an action set to a resource-ARN set, and a request auto-approves only when every requested action+resource pair is covered by one rule), and the action denylist. Call this before aws_request_access if you're not sure what you're allowed to ask for; it's free, idempotent, and writes nothing." + inventoryBlock + NO_DIRECT_HTTP_BLOCK,
   describeScopeShape,
   async (args) => {
     try {
@@ -21806,7 +21806,7 @@ server.tool(
   // accounts inline with the tool that consumes account_id. This is the
   // call site where a wrong/invented account_id would actually do harm
   // (route to a nonexistent enrolment → 404 → confusing failure mode).
-  'Request scoped, TTL-bounded AWS credentials for the current task. CALL aws_check_approval_channel FIRST on the FIRST request for a given account_id in a session \u2014 if it returns ok=false, DO NOT call this tool, surface the invite-the-bot message instead. agent_id and run_id are optional \u2014 the broker fills them from the host MCP env (AGT_AGENT_ID / AGT_RUN_ID). source_context is optional but you SHOULD pass it whenever the request was triggered by an inbound channel message: extract { channel_type, channel_id, thread_ts? } from the `<channel>` tag in the conversation that triggered this. Slack: channel_type="slack", channel_id=tag\'s `channel`, thread_ts=tag\'s `thread_ts`. Telegram: channel_type="telegram", channel_id=tag\'s `chat_id`. Direct-chat: channel_type="direct-chat", channel_id=tag\'s `session_id`. Without source_context the resolution notification dead-ends in your direct-chat instead of threading back to the original conversation. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason?, notification_channel_name?, notification_channel_id?, notification_permalink?, notification_bot_user_handle? }. status="active" means credentials are ready, use them now. status="denied" means the request was rejected (denial_reason explains). status="pending" means approval is still outstanding \u2014 DO NOT poll. Post a brief, jargon-free acknowledgement to the user first. When notification_channel_name is populated, QUOTE IT VERBATIM in the acknowledgement (e.g. "Requesting access to the <aws_account_name> account so I can <do the task> \u2014 pinged an admin in #<notification_channel_name> to approve, will resume the moment it lands"); NEVER invent or guess a channel name from training (e.g. "#aws-approvals" is wrong if the configured channel is "#agt-approvals"). When notification_permalink is populated, you MAY append it as a markdown link (e.g. "[approval card](<notification_permalink>)") so the user can jump straight to it; otherwise omit. When notification_channel_name is absent, fall back to the channel-agnostic phrasing ("pinged an admin to approve"). Then save the grant_id and return control. NEVER expose broker mechanics to the user \u2014 phrases like "firing a broker grant", "requesting a grant", "broker grant", "grant_id", "secret_ref", "STS", "AssumeRole", or any aws_* tool name must not appear in user-facing messages. Also NEVER paste the grant UUID into user-facing prose (e.g. "request c7a0b7be-5e09-\u2026 is queued") \u2014 it is operator-only metadata and reads as noise to the user. Talk about the task and the AWS account, not the plumbing. The broker pushes the resolution to you via direct-chat the moment a human approves or denies. The notification body will include an "Original conversation:" line naming the channel/thread to reply in \u2014 when it arrives, post a one-line acknowledgement there in the same jargon-free style ("Approval came through for <aws_account_name> \u2014 kicking off <the task> now" on active; "Couldn\'t get access to <aws_account_name> for <the task>: <paraphrased reason> \u2014 let me know how you\'d like to proceed" on denied) BEFORE calling aws_get_credentials or doing the work, then complete the user\'s task in that same channel/thread (not direct-chat). Going silent between the request and the work loses the human-in-the-loop signal. Only check notification_status if you need to flag a setup issue to the user: "sent" means a human was paged; "failed" or "not_attempted" means no human was paged (typically channel_not_found because the approval-bot is not a member of the configured channel). When notification_status is "failed" and notification_bot_user_handle + notification_channel_name are populated, name them specifically in the user message: "I queued the access request for <aws_account_name> but couldn\'t notify the approver \u2014 please run `/invite @<notification_bot_user_handle>` in #<notification_channel_name> and let me know when done so I can re-fire". When the handle/channel-name aren\'t populated, fall back to the generic version: "I couldn\'t reach an approver for the <aws_account_name> account (the approval bot isn\'t in the configured channel) \u2014 please ping an admin manually, or fix the AWS approval channel in Team Settings". Keep the user-facing text jargon-free and paraphrased. grant_id and notification_failure_reason are operator/escalation-only metadata; if and only if you are escalating to an operator, append "(reference: <grant_id>, failure: <notification_failure_reason>)" to the operator-facing escalation note. aws_poll_grant exists as an escape hatch for explicit re-checks but the autonomous flow does not need it. RETRY CONTRACT (ENG-5166) \u2014 if you have a cached grant_id from a prior aws_request_access in this conversation and the user asks you again to do work that needs AWS access (retry, continue, "try again", or any new task on the same account), DO NOT short-circuit on "I already have a request in flight": ALWAYS call aws_poll_grant({grant_id}) FIRST to re-validate. If aws_poll_grant returns status="pending", keep waiting and tell the user "the previous access request is still pending an approver \u2014 will resume the moment it lands". If status="active" and expires_at is still in the future, reuse the existing grant (skip straight to aws_get_credentials). If status="denied", "expired", "failed", "revoked", or "active" past its expires_at, DROP the cached grant_id entirely and call aws_request_access AGAIN with a fresh request; surface "the previous access request was denied/expired/was revoked/expired \u2014 submitting a fresh one" to the user (paraphrase to match the terminal status, jargon-free, no grant_id leakage). NEVER claim "request already in flight" without having just polled and confirmed a genuinely-pending or unexpired-active status. The dispatcher considers status terminal once it leaves the pending state, so a cached grant_id is only trustworthy after a fresh poll.' + inventoryBlock + NO_DIRECT_HTTP_BLOCK,
+  `Request scoped, TTL-bounded AWS credentials for the current task. CALL aws_check_approval_channel FIRST on the FIRST request for a given account_id in a session - if it returns ok=false, DO NOT call this tool, surface the invite-the-bot message instead. agent_id and run_id are optional - the broker fills them from the host MCP env (AGT_AGENT_ID / AGT_RUN_ID). source_context is optional but you SHOULD pass it whenever the request was triggered by an inbound channel message: extract { channel_type, channel_id, thread_ts? } from the \`<channel>\` tag in the conversation that triggered this. Slack: channel_type="slack", channel_id=tag's \`channel\`, thread_ts=tag's \`thread_ts\`. Telegram: channel_type="telegram", channel_id=tag's \`chat_id\`. Direct-chat: channel_type="direct-chat", channel_id=tag's \`session_id\`. Without source_context the resolution notification dead-ends in your direct-chat instead of threading back to the original conversation. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason?, notification_channel_name?, notification_channel_id?, notification_permalink?, notification_bot_user_handle? }. status="active" means credentials are ready, use them now. status="denied" means the request was rejected (denial_reason explains). status="pending" means approval is still outstanding - DO NOT poll. Post a brief, jargon-free acknowledgement to the user first. When notification_channel_name is populated, QUOTE IT VERBATIM in the acknowledgement (e.g. "Requesting access to the <aws_account_name> account so I can <do the task> - pinged an admin in #<notification_channel_name> to approve, will resume the moment it lands"); NEVER invent or guess a channel name from training (e.g. "#aws-approvals" is wrong if the configured channel is "#agt-approvals"). When notification_permalink is populated, you MAY append it as a markdown link (e.g. "[approval card](<notification_permalink>)") so the user can jump straight to it; otherwise omit. When notification_channel_name is absent, fall back to the channel-agnostic phrasing ("pinged an admin to approve"). Then save the grant_id and return control. NEVER expose broker mechanics to the user - phrases like "firing a broker grant", "requesting a grant", "broker grant", "grant_id", "secret_ref", "STS", "AssumeRole", or any aws_* tool name must not appear in user-facing messages. Also NEVER paste the grant UUID into user-facing prose (e.g. "request c7a0b7be-5e09-\u2026 is queued") - it is operator-only metadata and reads as noise to the user. Talk about the task and the AWS account, not the plumbing. The broker pushes the resolution to you via direct-chat the moment a human approves or denies. The notification body will include an "Original conversation:" line naming the channel/thread to reply in - when it arrives, post a one-line acknowledgement there in the same jargon-free style ("Approval came through for <aws_account_name> - kicking off <the task> now" on active; "Couldn't get access to <aws_account_name> for <the task>: <paraphrased reason> - let me know how you'd like to proceed" on denied) BEFORE calling aws_get_credentials or doing the work, then complete the user's task in that same channel/thread (not direct-chat). Going silent between the request and the work loses the human-in-the-loop signal. Only check notification_status if you need to flag a setup issue to the user: "sent" means a human was paged; "failed" or "not_attempted" means the agent's approval bot couldn't page the channel (typically channel_not_found because the approval-bot is not a member of the configured channel). When notification_status is "failed" but notification_operator_alerted is true, an operator WAS paged out-of-band on a fallback channel and the request is still pending + approvable from the console, so tell the user you've alerted an operator who will approve shortly, and still surface the invite fix below so future requests page normally. When notification_status is "failed" and notification_bot_user_handle + notification_channel_name are populated, name them specifically in the user message: "I queued the access request for <aws_account_name> but couldn't notify the approver - please run \`/invite @<notification_bot_user_handle>\` in #<notification_channel_name> and let me know when done so I can re-fire". When the handle/channel-name aren't populated, fall back to the generic version: "I couldn't reach an approver for the <aws_account_name> account (the approval bot isn't in the configured channel) - please ping an admin manually, or fix the AWS approval channel in Team Settings". Keep the user-facing text jargon-free and paraphrased. grant_id and notification_failure_reason are operator/escalation-only metadata; if and only if you are escalating to an operator, append "(reference: <grant_id>, failure: <notification_failure_reason>)" to the operator-facing escalation note. aws_poll_grant exists as an escape hatch for explicit re-checks but the autonomous flow does not need it. RETRY CONTRACT (ENG-5166) - if you have a cached grant_id from a prior aws_request_access in this conversation and the user asks you again to do work that needs AWS access (retry, continue, "try again", or any new task on the same account), DO NOT short-circuit on "I already have a request in flight": ALWAYS call aws_poll_grant({grant_id}) FIRST to re-validate. If aws_poll_grant returns status="pending", keep waiting and tell the user "the previous access request is still pending an approver - will resume the moment it lands". If status="active" and expires_at is still in the future, reuse the existing grant (skip straight to aws_get_credentials). If status="denied", "expired", "failed", "revoked", or "active" past its expires_at, DROP the cached grant_id entirely and call aws_request_access AGAIN with a fresh request; surface "the previous access request was denied/expired/was revoked/expired - submitting a fresh one" to the user (paraphrase to match the terminal status, jargon-free, no grant_id leakage). NEVER claim "request already in flight" without having just polled and confirmed a genuinely-pending or unexpired-active status. The dispatcher considers status terminal once it leaves the pending state, so a cached grant_id is only trustworthy after a fresh poll.` + inventoryBlock + NO_DIRECT_HTTP_BLOCK,
   requestAccessShape,
   async (args) => {
     try {
@@ -21911,7 +21911,7 @@ server.tool(
 );
 server.tool(
   "gcp_request_access",
-  'Request scoped, TTL-bounded GCP credentials for the current task. CALL gcp_check_approval_channel FIRST on the FIRST request for a given project_id in a session \u2014 if it returns ok=false, do not call this tool, surface the invite-the-bot message instead. agent_id and run_id default from the host MCP env. Pass source_context whenever an inbound channel triggered the request so the resolution notification threads back to the original conversation. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason?, notification_channel_name?, notification_channel_id?, notification_permalink?, notification_bot_user_handle? }. status="active" \u2192 credentials are ready, call gcp_get_credentials. status="denied" \u2192 request rejected, denial_reason explains. status="pending" \u2192 DO NOT poll, the broker pushes resolution via direct-chat. Post a brief jargon-free acknowledgement first. Quote notification_channel_name VERBATIM when populated ("pinged an admin in #<notification_channel_name> to approve, will resume the moment it lands"); never invent a channel name. Append the notification_permalink as a markdown link when present. Save the grant_id and return control. NEVER expose broker mechanics ("grant", "secret_ref", "IAM Credentials", "generateAccessToken", "MCP", any gcp_* tool name) in user-facing prose \u2014 talk about the task and the GCP project. When the resolution lands via direct-chat, post a one-line acknowledgement in the original channel/thread before calling gcp_get_credentials or starting the work; complete the task in that same channel/thread. Same notification_status branching as aws_request_access: "sent" \u2192 human paged; "failed"/"not_attempted" \u2192 no human paged, surface specific invite message when bot_user_handle + channel_name populated, generic recovery otherwise.' + gcpInventoryBlock + NO_DIRECT_HTTP_BLOCK,
+  `Request scoped, TTL-bounded GCP credentials for the current task. CALL gcp_check_approval_channel FIRST on the FIRST request for a given project_id in a session - if it returns ok=false, do not call this tool, surface the invite-the-bot message instead. agent_id and run_id default from the host MCP env. Pass source_context whenever an inbound channel triggered the request so the resolution notification threads back to the original conversation. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason?, notification_channel_name?, notification_channel_id?, notification_permalink?, notification_bot_user_handle? }. status="active" \u2192 credentials are ready, call gcp_get_credentials. status="denied" \u2192 request rejected, denial_reason explains. status="pending" \u2192 DO NOT poll, the broker pushes resolution via direct-chat. Post a brief jargon-free acknowledgement first. Quote notification_channel_name VERBATIM when populated ("pinged an admin in #<notification_channel_name> to approve, will resume the moment it lands"); never invent a channel name. Append the notification_permalink as a markdown link when present. Save the grant_id and return control. NEVER expose broker mechanics ("grant", "secret_ref", "IAM Credentials", "generateAccessToken", "MCP", any gcp_* tool name) in user-facing prose - talk about the task and the GCP project. When the resolution lands via direct-chat, post a one-line acknowledgement in the original channel/thread before calling gcp_get_credentials or starting the work; complete the task in that same channel/thread. Same notification_status branching as aws_request_access: "sent" \u2192 human paged; "failed"/"not_attempted" \u2192 the agent's bot couldn't page the channel, surface specific invite message when bot_user_handle + channel_name populated, generic recovery otherwise. When notification_operator_alerted is true, an operator was paged out-of-band, so tell the user an operator was alerted and will approve shortly, while still surfacing the invite fix so it self-heals.` + gcpInventoryBlock + NO_DIRECT_HTTP_BLOCK,
   gcpRequestAccessShape,
   async (args) => {
     try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/cloud-broker",
-  "version": "0.7.5",
+  "version": "0.7.7",
   "description": "Cloud Access Broker — MCP server that mints scoped, TTL-bounded cloud credentials per agent task. Ships AWS support (aws_request_access, aws_poll_grant, aws_release_access, aws_describe_scope, aws_preview_request, aws_get_credentials — STS AssumeRole under the hood); GCP, Azure, and Cloudflare land alongside in the same package as the broker grows.",
   "type": "module",
   "bin": {