AI-2442: add read-only access control for guest and read-only roles

[vita-stejskal]

Description

Linear: AI-2442

Change Type

• Major (breaking changes, significant new features)
• Minor (new features, enhancements, backward compatible)
• Patch (bug fixes, small improvements, no new features)

Summary

Transplants the role-based access control fix from upstream PR #381:

• Filter tool list to read-only tools only for guest and readonly roles
• Block write tool calls for those roles with a clear error message
• Swallow 403 errors in the tool event trigger (expected for restricted roles that can't post analytics events)
• Add is_read_only_tool() helper to mcp.py, replacing the duplicate _is_read_only_tool() in authorization.py
• Bump version to 1.44.8

Testing

• Tested with Cursor AI desktop (Streamable-HTTP transports)

Optional testing

• Tested with Cursor AI desktop (all transports)
• Tested with claude.ai web and canary-orion MCP (SSE and Streamable-HTTP)
• Tested with In Platform Agent on canary-orion
• Tested with RO chat on canary-orion

Checklist

• Self-review completed
• Unit tests added/updated (if applicable)
• Integration tests added/updated (if applicable)
• Project version bumped according to the change type (if applicable)
• Documentation updated (if applicable)

[linear]

AI-2442 Enable read-only tools access for guest and RO users in chat

[Matovidlo]

It looks alright, the issue is that guest can use all tools except flows one, read only users cannot submit storage events. Therefore I am missing these 2 things. I would do guest role as all tools - excluding scheduler ones and for RO we need to somehow not report to AI/User of MCP when having RO role 403 forbidden when doing storage event or even better to not call it when such user is using the MCP

[vita-stejskal]

It looks alright, the issue is that guest can use all tools except flows one

Ok, this is now fixed in 109fbce. The quest role can access all tools except of those that are accessible only to admins.

... read only users cannot submit storage events. ... and for RO we need to somehow not report to AI/User of MCP when having RO role 403 forbidden when doing storage event or even better to not call it when such user is using the MCP

The 403 Forbidden responses from the SAPI Events API are silently swallowed (logged to DD) regardless of the user's role. This is a workaround which can be removed when the MCP server is allowed to call the SAPI Events API even for read-only user roles. I'd keep this workaround for now. The real fix needs to be done outside of the MCP server and once it's done the SAPI will simply stop responding with 403 Forbidden and so the emitted events will be recorded without any further changes needed in the MCP server.