Skip to content

Backfill the owner segment on tool policy patterns (#2047) - #2075

Open
cjumeow wants to merge 1 commit into
UsefulSoftwareCo:mainfrom
cjumeow:fix/policy-pattern-owner-segment
Open

cjumeow wants to merge 1 commit into
UsefulSoftwareCo:mainfrom
cjumeow:fix/policy-pattern-owner-segment

Conversation

@cjumeow

@cjumeow cjumeow commented Sep 19, 2026

Copy link
Copy Markdown

Summary

Tool policies matched against dynamic (connection-backed) tools are keyed by the full four-segment id integration.owner.connection.tool, but the public policies.create tool description describes patterns in the pre-owner three-segment shape integration.connection.tool. A pattern written in that documented shape is one segment short of the matcher and can never match anything — silently for approve/require_approval, and dangerously for block, where the tool keeps running on every call with no indication the policy never fired.

policiesCreate/policiesUpdate now backfill a mid-pattern * for the missing owner segment via a new normalizePolicyPattern, so a pattern written in the documented shape matches as intended. *, integration.* (already unbounded), and patterns rooted at a static namespace (no owner segment to backfill) are left untouched. The policies.create description and a stale comment above normalizedPolicyId are also corrected to describe the real grammar.

Linked issue

Fixes #2047

Verification

  • bun run format:check
  • bun run lint
  • bun run typecheck
  • bun run test — ran scoped: vitest run on packages/core/sdk (949/949 passed), including new unit tests for normalizePolicyPattern in policies.test.ts and an integration regression test in executor.test.ts that creates a block policy in the documented pre-owner shape and asserts the tool call is actually blocked.
  • e2e — not applicable; this is a pure backend matching-logic fix with no UI change, fully covered by unit/integration tests.

Checklist

  • Added a changeset (bun run changeset).
  • Added or updated tests for the new behaviour.
  • No secrets, credentials, or private data in the diff.

…2047)

Tool policies matched against dynamic (connection-backed) tools use a
four-segment id, `integration.owner.connection.tool`, but the public
docs and UI describe patterns in the pre-owner three-segment shape
`integration.connection.tool`. A pattern written that way is one
segment short and can never match anything — silently for `approve`,
dangerously for `block`, where the tool keeps running with no warning
that the policy never fired.

`policiesCreate`/`policiesUpdate` now backfill a mid-pattern `*` for
the owner segment via `normalizePolicyPattern`, leaving `*`,
`integration.*`, and static-namespace patterns untouched.
@cjumeow
cjumeow force-pushed the fix/policy-pattern-owner-segment branch from c0f629e to eb29c66 Compare September 19, 2026 19:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] Tool policies written in the documented integration.connection.tool form never match and fail silently

1 participant