Let's enable MFA for all Ruby gems

2026-04-21T00:00:00+00:00

A few weeks ago, Axios, the popular HTTP client for JavaScript, suffered a supply chain attack on NPM. An attacker compromised the lead maintainer’s NPM account through social engineering and published two backdoored versions that delivered a cross-platform remote access trojan (RAT) to macOS, Windows, and Linux systems. Axios has over 100 million weekly downloads. The blast radius was enormous.

Not long before that, LiteLLM, a popular Python AI gateway, had a similar incident on PyPI. Compromised credentials were used to push malicious packages that harvested environment variables, SSH keys, cloud credentials, and database passwords.

Both attacks followed the same playbook: gain access to a maintainer’s account, then push a new version with malicious code outside of the normal release process. No code review. No CI. Just a direct publish to the package registry.

Ruby is equally vulnerable to this type of attack

RubyGems is not immune

RubyGems hasn’t had a major attack like this yet, but we should be proactive in securing the ecosystem before it happens. Nate Berkopec (maintainer of Puma and a longtime voice in the Ruby community) estimates that 75% of the gems on RubyGems are vulnerable to this type of attack.

The fix is straightforward: gems can require multi-factor authentication (MFA) for all pushes by adding a single line to their gemspec:

spec.metadata["rubygems_mfa_required"] = "true"

After releasing a new version with this set, RubyGems.org will reject any gem push from an account that doesn’t have MFA enabled. Even if an attacker compromises a maintainer’s password or API key, they still can’t publish a new version without the second factor. It doesn’t make the gem invulnerable, but it raises the bar significantly.

What you can do

The good thing about open source is that we can all help make it more secure. Here’s what I propose:

1. Audit your app’s gems

Nate wrote an audit script you can run in your project to see which gems in your Gemfile don’t require MFA on push. Run it. The results might surprise you.

2. Open PRs on gems you use

Pick one or a few gems that don’t require MFA and open a PR adding the line above to their gemspec. The change is a one-liner and the PR description mostly writes itself. You can link to this post or to the Axios incident and explain why it matters.

3. Enable MFA on gems you maintain

If you maintain any gems, add rubygems_mfa_required to your gemspec and make sure all owners on RubyGems.org have MFA enabled on their accounts.

It takes a community

I’ve been opening PRs on thoughtbot gems and other open source projects, and I encourage you to do the same. Maintainers have been receptive, so these PRs tend to get merged quickly. I also got a PR merged on Bundler adding a commented-out rubygems_mfa_required line to the bundle gem template to nudge authors of new gems to enable this.

If we all do our part, we can make the Ruby ecosystem safer for everyone. Let’s get to work!

PII filtering for RubyLLM with Top Secret

2026-04-17T00:00:00+00:00

If you’re building LLM-powered features in a regulated industry, sending unfiltered PII to a third-party provider isn’t just risky, it may violate compliance requirements like HIPAA or GDPR.

That’s why we originally built Top Secret. However, when we first released it, RubyLLM was still in its early days, and I found I was working with provider APIs directly, such as Ruby OpenAI or OpenAI Ruby. This meant I needed to manually orchestrate the filtering and restoration process, which looked something like this:

require "openai"
require "top_secret"

openai = OpenAI::Client.new

original_messages = [
  "Ralph lives in Boston.",
  "You can reach them at ralph@thoughtbot.com or 877-976-2687"
]

# Filter all messages
result = TopSecret::Text.filter_all(original_messages)
user_messages = result.items.map { {role: "user", content: it.output} }

messages = [*user_messages]

chat_completion = openai.chat.completions.create(messages:, model: :"gpt-5")
response = chat_completion.choices.last.message.content

# Restore the response from the mapping
mapping = result.mapping
restored_response = TopSecret::FilteredText.restore(response, mapping:).output

Even with RubyLLM, there was no way to filter and restore conversation history, since Chat#ask handles the message life cycle internally.

Enter RubyLLM::TopSecret

The introduction of RubyLLM::TopSecret aims to make filtering sensitive information from RubyLLM chats as simple as possible. All you need to do is wrap your existing in-memory chats with RubyLLM::TopSecret.with_filtering:

RubyLLM::TopSecret.with_filtering do
  chat = RubyLLM.chat
  response = chat.ask("My name is Ralph and my email is ralph@thoughtbot.com")

  # The provider receives: "My name is [PERSON_1] and my email is [EMAIL_1]"
  # The response comes back with placeholders restored:
  puts response.content
  # => "Nice to meet you, Ralph!"
end

Working with ActiveRecord-backed chats is even easier. All you need to do is add the acts_as_filtered_chat class macro, and the gem will take care of the rest.

class Chat < ApplicationRecord
  acts_as_chat
  acts_as_filtered_chat
end

If you want more granular control, you can simply pass an if: condition. For example, you might only need to filter customer-facing chats that process health data, but not internal admin conversations. A simple way to model this would be to add a filtered boolean column to the chats table:

class Chat < ApplicationRecord
  acts_as_chat
  acts_as_filtered_chat if: :filtered?
end

In either case, the goal is to create an opt-in approach that just works. If you want to see it in action, check out this live demo.

If you’re interested in exploring the gem yourself, follow the installation guide and refer to the usage section for a more detailed overview.