Obscura - PII detection and anonymization for Elixir

News Announcing
, , , ,
1

Hi everyone,

I’ve released Obscura 0.1.1, an Elixir library for detecting and anonymizing personally identifiable information before it reaches logs, external APIs, analytics systems, or LLM providers.

The dependency-light core recognizes structured identifiers such as email addresses, phone numbers, credit cards, SSNs, IBANs, IP addresses, URLs, and domains. Optional local Nx/Bumblebee profiles add person, location, and organization recognition without requiring a hosted recognition service.

A basic redaction looks like this:

{:ok, result} =
  Obscura.redact(
    "Contact jane@example.com or call 202-555-0188",
    profile: :fast,
    entities: [:email, :phone]
  )

result.text
#=> "Contact [EMAIL] or call [PHONE]"

Obscura also supports nested Elixir data:

input = %{
  customer: %{email: "jane@example.com"},
  password: "secret"
}

{:ok, result} =
  Obscura.redact(input,
    entities: [:email],
    field_policies: %{password: :drop}
  )

result.data
#=> %{customer: %{email: "[EMAIL]"}}

The available operators are replacement, redaction, masking, hashing, pseudonymization, and application-defined callbacks. Pseudonymization can use an ETS-backed vault when an application needs to restore selected values after an LLM or external-service round trip.

The three stable profiles serve different use cases:

  • :fast uses dependency-light deterministic and parser-backed recognition.
  • :balanced adds one local model for general person, location, and organization recognition.
  • :accurate uses a two-model cascade for the highest measured general accuracy.

Model-backed profiles require explicit preparation and reusable runtime resources. Normal analysis never downloads a model implicitly.

One important asset note: :balanced and :accurate currently use an OntoNotes-trained TNER checkpoint. Obscura does not bundle or license that checkpoint, and LDC confirmed that commercial use requires LDC for-profit membership. The dependency-light :fast profile is unaffected. The complete review is documented in the model-asset licensing guide.

Links:

This is the first public release, and I’d particularly appreciate feedback about the API, entity coverage, structured-data behavior, model preparation, deployment, performance, and use cases that the current profiles do not handle well.

13 Likes
2

I wrote a follow-up engineering case study about validating Obscura’s model-backed profiles on Linux with an NVIDIA Tesla T4 and EXLA.

The article covers the complete path from a CPU environment to real CUDA inference, including an NVSHMEM ABI failure that initially prevented EXLA from loading.

Rather than treating CUDA discovery as sufficient proof, I verified four independent signals:

  • EXLA discovered the CUDA client.
  • A compiled Nx operation returned an EXLA-backed tensor.
  • XLA identified the Tesla T4 and cuDNN runtime.
  • The BEAM process appeared in nvidia-smi using GPU memory.

I then prepared the :balanced and :accurate profiles and ran real Obscura inference. This is a compatibility report on one Tesla T4, not a production throughput benchmark.

1 Like
3

Thanks for sharing @hfiguera, this is extremely useful! :rocket:

1 Like
4

Woah, this is neat! Thanks for sharing!

1 Like
5

I published a third Obscura engineering article: A Model Card Is Not a License: What We Learned Shipping Local NER in Obscura.

While reviewing the :balanced and :accurate profiles, I found that the MIT license of the base RoBERTa model did not answer whether the fine-tuned OntoNotes checkpoint was authorized for commercial use.

I traced the model’s provenance and contacted LDC directly. They confirmed that commercial use of this specific checkpoint requires an LDC for-profit membership. That conclusion is checkpoint-specific and does not apply to TNER models generally.

The article documents the investigation and the resulting Obscura changes, including machine-readable licensing metadata and notices before model downloads:

6

Very Cool - Excited about checking this out!

1 Like
7

I published a new engineering article about privacy-safe request logging in Phoenix.

The problem is subtle: Obscura.Phoenix.Plug can create a redacted assign while leaving conn.params unchanged for controllers, but Phoenix’s default telemetry logger still reads the original parameters.

The article explains the opt-in Obscura.Phoenix.Logger integration, why the default Phoenix logger must be disabled, how route templates and sanitized parameters are logged, and how failures are handled without falling back to raw request data.

The integration is available in Obscura 0.1.3. Feedback from people operating Phoenix applications would be especially useful.

8

I published a new article about keeping customer identity inside an Elixir application while an agent and remote model work with stable pseudonyms.

The difficult part is not only protecting the initial prompt. Raw identifiers can also escape through tool arguments, tool results, streamed responses, logs, and telemetry.

The reference application uses Phoenix LiveView, Jido, ReqLLM, OpenAI, and Obscura. Trusted tools restore only the value needed for a local lookup, protect their results before returning them, and leave final restoration to the trusted LiveView.

The complete example is public and can run in deterministic mode without an OpenAI key. I would be interested in feedback from anyone building agents that call application tools.

9

I played with a similar idea for a while and landed on the same name. My question is what does this add over https://presidio.dataprivacystack.org (Python framework)?

10

That is a fair question. Presidio is the closest comparison, and it is currently broader and more mature. It has a larger recognizer ecosystem, multiple NLP engines and languages, image redaction, structured data support, and several deployment options. If I were working in Python, or comfortable operating Presidio as a separate service, I would seriously consider using it.

The main value Obscura adds is native integration with Elixir and the BEAM. Its fast path runs inside the application without a Python service or HTTP hop. It works directly with text, nested Elixir values, structs, Logger metadata, Phoenix request and realtime logging, LLM messages, streaming responses, and session vaults for reversible pseudonymization.

That means the privacy boundary can live where Elixir data actually crosses into logs, Phoenix telemetry, external APIs, or model providers, while remaining part of the application supervision and lifecycle.

Obscura is not a complete Presidio replacement. It is still an early 0.1.x library, while Presidio covers more entities, languages, media, and deployment scenarios. I have also compared Obscura against Presidio using pinned datasets. The results are mixed: Obscura performs better in some measured profiles and datasets, while Presidio remains better for some entities and recall characteristics. I do not claim universal superiority. The complete comparison is available in this report.

So the short answer is: Presidio is the stronger general privacy framework today. Obscura is useful when an Elixir application needs privacy controls inside the BEAM and at Elixir specific application boundaries, without introducing a separate Python service.