Mandatory Attachment Security Changes

I agree completely! 

We don’t have a customer facing KB, with this setting enabled, end users clicking on an attachment from an email thread, will be lead to our KB and prompted to log in. This is not a good customer experience.

The only recourse I can think of at the moment, is to change our comment placeholders in notification triggers to only send the current comment, and not the whole thread. This sacrifices context for no gain what so ever.

We should be able to opt out here.

Hmm. This is going to be tricky with embedded attachments/images in emails because it can’t authenticate, for agents and end-users alike.

I feel like the security goal can be achieved further upstream without introducing the bad customer experience currently proposed.
If end user attachments are just scrubbed from the email comment threads, this should be a closed issue as far as I can see.

We have automations that generate descriptions of attachments using AI. It was trivial before to simply send the content URLs to something like the OpenAI API. This change vastly complicates that workflow. I’m also annoyed at the lack of information about how to access private attachments programatically; it turns out adding an Authorization header works but I had to discover this through testing. I wish there was an easier way to secure the attachment while keeping the URL portable, similar to a presigned S3 URL.

Hi everyone,

Thank you for taking the time to share such thoughtful and detailed feedback. You’ve highlighted a critical principle: robust security should protect your operations, not disrupt the workflows and productivity your teams rely on every day.

Listening to your feedback made it clear that enforcing a single, mandatory approach without configuration options created friction for many. Because of this, we have officially canceled the planned security enforcement.

What’s Next? We agree that security and usability must go hand in hand. Instead of forcing a rigid requirement, we have shifted our focus toward a One-Time Passcode (OTP) approach for attachment access.

Our goal with this discovery effort is to:

• Maintain security: Ensure both agent and end-user attachments remain safe and protected.

• Minimize friction: Allow easy access to attachments without breaking established processes or a need of a help center/Guide activated

• Support diverse workflows: Give teams the flexibility needed to fit their specific operational environments.

We are currently evaluating the technical details and user experience for the OTP feature. 

Thank you again for candidly sharing your needs—it directly shaped this decision and is helping us build a better product experience for everyone