Renaming a shared tag can edit records the user can't open

Tags and labels are often stored once per workspace and joined to records through a tag_id. The rename endpoint checks that the caller can manage tags, runs UPDATE tags SET name = ? WHERE id = ?, and that's it. Every record carrying the tag now shows the new name, including records in projects the caller has never been able to see.

Say a contractor has tag-admin rights in one project and renames "Q4 candidates" to "rejected". HR's private hiring pipeline uses the same tag, so the next morning the hiring manager finds the whole shortlist relabeled. The contractor never opened one of those records.

There are two reasonable fixes. Scope tags to the project or folder that owns them, so a rename can only reach records under it. If tags have to stay workspace-wide, count the tagged records the caller can't edit before applying the rename. When that count is above zero, refuse the rename, or fork a new tag for the caller's own records and leave the original alone.

To test it, tag a record in a project your limited user can't access, then rename that tag as the limited user. Open the private record as an admin. If the label changed, the rename skipped the check.

If you want that check in one place for every endpoint that writes through a shared tag, Permit.io is one option for resource-level decisions (full disclosure, I work with Permit.io).