@integrity-labs/cloud-broker 0.4.4 → 0.4.6

package/dist/index.js

@@ -21150,6 +21150,17 @@ var previewRequestSchema = external_exports.object({
   regions: regionListSchema,
   ttl_seconds: ttlSecondsSchema
 });
+var sourceContextSchema = external_exports.object({
+  channel_type: external_exports.string().min(1).max(64).describe(
+    'Inbound channel type (e.g. "slack", "telegram", "direct-chat"). Defaults from AGT_INBOUND_CHANNEL_TYPE if set.'
+  ),
+  channel_id: external_exports.string().min(1).max(256).describe(
+    "Inbound channel/conversation id (Slack channel id, Telegram chat id, etc). Defaults from AGT_INBOUND_CHANNEL_ID."
+  ),
+  thread_ts: external_exports.string().min(1).max(256).optional().describe(
+    "Optional thread/parent identifier within channel_id (e.g. Slack thread_ts). Defaults from AGT_INBOUND_CHANNEL_THREAD_TS."
+  )
+});
 var requestAccessSchema = external_exports.object({
   // ENG-4746: agent_id and run_id are optional. The MCP server fills them
   // from AGT_AGENT_ID / AGT_RUN_ID env at provision time, so the agent
@@ -21169,6 +21180,9 @@ var requestAccessSchema = external_exports.object({
   task_id: external_exports.string().min(1).optional().describe("Optional Augmented task identifier (e.g. kanban:task-7842)."),
   reason: external_exports.string().min(1).max(500).optional().describe(
     "One-sentence rationale shown to a human approver. Must be safe to render \u2014 never contains credentials."
+  ),
+  source_context: sourceContextSchema.optional().describe(
+    "Optional. Inbound conversation that triggered this request. The MCP server fills it from AGT_INBOUND_CHANNEL_* env vars when present. Persisted on the grant so the resolution notification can tell the agent to thread the answer back to the original conversation."
   )
 });
 var pollGrantSchema = external_exports.object({
@@ -21249,7 +21263,7 @@ server.tool(
 );
 server.tool(
   "request_access",
-  'Request scoped, TTL-bounded AWS credentials for the current task. agent_id and run_id are optional \u2014 the broker fills them from the host MCP env (AGT_AGENT_ID / AGT_RUN_ID). Only pass them explicitly to attribute the grant to a different agent or run. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason? }. 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. The broker pushes the resolution to you via direct-chat the moment a human approves or denies, so save the grant_id, return control, and resume when the inbound message arrives. 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) \u2014 quote grant_id + notification_failure_reason and recommend manual escalation. poll_grant exists as an escape hatch for explicit re-checks but the autonomous flow does not need it.',
+  'Request scoped, TTL-bounded AWS credentials for the current task. 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? }. 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. The broker pushes the resolution to you via direct-chat the moment a human approves or denies, so save the grant_id, return control, and resume when the inbound message arrives. The notification body will include an "Original conversation:" line naming the channel/thread to reply in \u2014 complete the user\'s task there, not in direct-chat. 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) \u2014 quote grant_id + notification_failure_reason and recommend manual escalation. poll_grant exists as an escape hatch for explicit re-checks but the autonomous flow does not need it.',
   requestAccessShape,
   async (args) => {
     try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/cloud-broker",
-  "version": "0.4.4",
+  "version": "0.4.6",
   "description": "Cloud Access Broker — MCP server that mints scoped, TTL-bounded cloud credentials per agent task. v1 ships AWS support (request_access, poll_grant, release_access, describe_scope, preview_request — STS AssumeRole under the hood); GCP, Azure, and Cloudflare land alongside in the same package as the broker grows.",
   "type": "module",
   "bin": {