@checkstack/integration-teams-backend 0.1.11 → 0.2.0

package/CHANGELOG.md

@@ -1,5 +1,69 @@
 # @checkstack/integration-teams-backend
 
+## 0.2.0
+
+### Minor Changes
+
+- ebef442: feat(automation): gate integration actions on the runAs service account's permissions
+
+  **BREAKING.** Integration automation actions resolve credentials through a
+  trusted service rather than the bounded `runAs` client, so they previously
+  bypassed the runAs least-privilege model entirely: anyone able to author an
+  automation could create Jira tickets, send Teams/Webex messages, etc. on any
+  configured connection, with a zero-permission service account. This closes that
+  gap.
+
+  - **Actions declare `requiredAccessRules`** and the dispatch engine enforces
+    them against the resolved `runAs` principal BEFORE the action runs (failing
+    the step if missing) - the authorization point integration actions lacked.
+  - **Each integration plugin defines per-action access rules**, e.g.
+    `integration-jira.create_issue.manage` / `search_issues.read` /
+    `transition_issue.manage` / `add_comment.manage`,
+    `integration-teams.post_message.manage`,
+    `integration-webex.post_message.manage`.
+  - **`automation.propose` checks the same up front**, surfacing a per-action
+    missing-permission error on the review card; `listActions` now exposes each
+    action's `requiredAccessRules`, and `getBindableApplications` now returns each
+    app's effective `accessRules`.
+  - **New `integration.read` rule** gates `listConnectionSummaries` /
+    `resolveConnectionOptions` (previously open to any authenticated user), so
+    discovering connections and resolving their field options requires a grant.
+  - **The AI assistant picks a capable runAs up front.**
+    `automation.listServiceAccounts` now returns each account's `accessRules` and
+    `automation.getCapabilitySchema` returns each action's `requiredAccessRules`,
+    so the model selects a service account whose permissions cover the actions it
+    uses instead of proposing and being rejected. When the operator did not name a
+    runAs and more than one account qualifies, it ASKS which to use rather than
+    choosing the automation's identity itself; when none has the needed rules it
+    says which rule(s) to grant.
+
+  **Migration:** existing automations whose service account does not hold the new
+  rules will fail at the gated action until an admin grants the matching rule(s)
+  to the service account's role (e.g. add `integration-jira.create_issue.manage`).
+  Admin (`*`) service accounts are unaffected. Grant `integration.read` to roles
+  that author integration-using automations so the editor's connection pickers and
+  dropdowns keep working for non-admins.
+
+### Patch Changes
+
+- Updated dependencies [ebef442]
+- Updated dependencies [ebef442]
+  - @checkstack/integration-backend@0.6.0
+  - @checkstack/automation-backend@0.7.0
+  - @checkstack/backend-api@0.21.7
+
+## 0.1.12
+
+### Patch Changes
+
+- Updated dependencies [c4bebbb]
+- Updated dependencies [c4bebbb]
+- Updated dependencies [c4bebbb]
+- Updated dependencies [c4bebbb]
+- Updated dependencies [c4bebbb]
+  - @checkstack/automation-backend@0.6.0
+  - @checkstack/integration-backend@0.5.0
+
 ## 0.1.11
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/integration-teams-backend",
-  "version": "0.1.11",
+  "version": "0.2.0",
   "type": "module",
   "main": "src/index.ts",
   "checkstack": {
@@ -15,9 +15,9 @@
     "pack": "bunx @checkstack/scripts plugin-pack"
   },
   "dependencies": {
-    "@checkstack/backend-api": "0.21.6",
-    "@checkstack/integration-backend": "0.4.6",
-    "@checkstack/automation-backend": "0.5.8",
+    "@checkstack/backend-api": "0.21.7",
+    "@checkstack/integration-backend": "0.6.0",
+    "@checkstack/automation-backend": "0.7.0",
     "@checkstack/common": "0.15.0",
     "zod": "^4.2.1"
   },
@@ -25,7 +25,7 @@
     "@types/bun": "^1.0.0",
     "typescript": "^5.0.0",
     "@checkstack/tsconfig": "0.0.7",
-    "@checkstack/test-utils-backend": "0.1.40"
+    "@checkstack/test-utils-backend": "0.1.41"
   },
   "description": "Checkstack integration-teams-backend plugin",
   "author": {

package/src/automations.ts

@@ -14,7 +14,12 @@ import {
 } from "@checkstack/backend-api";
 import type { ActionDefinition } from "@checkstack/automation-backend";
 import { connectionStoreRef } from "@checkstack/integration-backend";
-import { extractErrorMessage } from "@checkstack/common";
+import {
+  access,
+  extractErrorMessage,
+  qualifyAccessRuleId,
+} from "@checkstack/common";
+import { pluginMetadata } from "./plugin-metadata";
 
 import {
   getAppToken,
@@ -23,6 +28,22 @@ import {
   type TeamsConnectionConfig,
 } from "./provider";
 
+/**
+ * Access rule a runAs service account must hold to post Teams messages from an
+ * automation. The dispatch engine enforces it before the action runs, so the
+ * capability is granted deliberately to a service account's role rather than
+ * implied by being able to author automations.
+ */
+export const teamsAccess = {
+  postMessage: access(
+    "post_message",
+    "manage",
+    "Post Microsoft Teams messages from an automation",
+    { pluginId: pluginMetadata.pluginId },
+  ),
+};
+export const teamsAccessRules = Object.values(teamsAccess);
+
 const GRAPH_API_BASE = "https://graph.microsoft.com/v1.0";
 
 const teamsMessageDataSchema = z.object({
@@ -153,6 +174,9 @@ export function createTeamsActions(): ActionDefinition<unknown, unknown>[] {
     category: "Microsoft Teams",
     icon: "MessageSquareMore",
     connectionProviderId: TEAMS_PROVIDER_QUALIFIED_ID,
+    requiredAccessRules: [
+      qualifyAccessRuleId(pluginMetadata, teamsAccess.postMessage),
+    ],
     config: new Versioned({
       version: 1,
       schema: teamsPostMessageConfigSchema,

package/src/index.ts

@@ -8,12 +8,15 @@ import { pluginMetadata } from "./plugin-metadata";
 import { teamsProvider } from "./provider";
 import {
   createTeamsActions,
+  teamsAccessRules,
   teamsMessageArtifactType,
 } from "./automations";
 
 export default createBackendPlugin({
   metadata: pluginMetadata,
   register(env) {
+    // A runAs service account must hold this rule to post Teams messages.
+    env.registerAccessRules(teamsAccessRules);
     env
       .getExtensionPoint(providerExtensionPoint)
       .addProvider(teamsProvider, pluginMetadata);