Every team that uses AI works with sensitive data: support, finance, HR, legal, compliance, operations. Customer records, account numbers, BVNs, employee details, payment references, vendor contracts. When someone on these teams pastes a prompt into an AI tool, that data goes with it.
Most organizations know this is a problem. Fewer know what to do about it beyond "tell people to be careful" or "ban AI entirely." Neither works. People forget to scrub their prompts. Banning AI just pushes usage underground.
Ekō is an open-source proxy that detects and sanitizes sensitive data in AI prompts before they reach the AI provider. But before rolling it into production, you need a way to test it — to see what it catches, what it misses, and whether your teams trust what it does.
That's what the Ekō Playground is for.
What the Playground does
The Ekō Playground is a web interface where you paste a prompt, hit sanitize, and see exactly what Ekō detects and how it handles each piece of sensitive data.
There's no terminal involved. No API calls. No Docker. You paste text, you get results. It's designed so that a compliance lead, a head of finance, or an HR director can evaluate Ekō without involving engineering at every step.
You can try it right now at eko-playground.openray.workers.dev.
The Playground shows you three things for every prompt you submit:
- The sanitized version. What the AI would actually receive after Ekō processes the prompt. Sensitive values are replaced. Business context stays intact.
- The violations list. Every piece of sensitive data Ekō detected, including what type it is (PII, financial, credential), which pattern matched, and what action was taken (redacted or tokenized).
- Processing time. How long sanitization took, typically a few milliseconds. This matters when you're evaluating whether Ekō adds noticeable delay to workflows.
The Playground also includes built-in sample prompts covering Nigerian KYC data, payment information, health records, and compliance memos, so you can start testing immediately without writing anything.
Why your non-technical teams should use it
The people who most need to evaluate Ekō are not engineers. They're the people whose daily work involves the sensitive data Ekō is designed to protect. The Playground gives them a way to answer a specific question: if my team starts using AI for their regular work, what happens to the sensitive data in their prompts?
Compliance and risk teams can test whether Ekō catches the data types that matter for NDPR, PCI-DSS, or internal governance policies. They can evaluate whether the sanitized output still makes sense for the original task. They can document what Ekō does and doesn't catch, which feeds directly into an AI usage policy.
Finance teams can paste sample payment disputes, invoice notes, or vendor communications and confirm that account numbers, payment references, and transaction details are protected before they'd reach an AI model.
HR teams can test with sample employee complaints, disciplinary notes, or policy questions and verify that employee identities, NINs, and contact details are stripped out while the business context stays usable.
Support teams can test customer tickets, the kind they'd normally paste into AI for summarization or response drafting, and see whether customer names, BVNs, phone numbers, and account numbers are caught.
Legal teams can test contract excerpts, checking whether party names, financial terms, and confidential references are handled.
The point is not to turn these teams into security testers. The point is to let them see, concretely, what "AI sanitization" means for their work. A compliance officer who has pasted five realistic prompts into the Playground and reviewed the output understands Ekō better than someone who has read ten pages of documentation.
Testing with realistic prompts
The built-in samples are a starting point. The real value comes from testing with prompts that reflect how your teams actually use AI. Here are examples across common workflows.
Customer support
A support agent wants to summarize a complaint.
What they'd normally paste into AI:
Customer John Adewale, account number 2039483921, complained that his transfer of ₦500,000 to Vivian failed. His BVN is 22334455667 and he can be reached at
john.adewale@company.comor +234 802 111 3344.
What the AI would receive after Ekō:
Customer John Adewale, account number
[REDACTED_BANK_ACCOUNT], complained that his transfer of ₦500,000 to Vivian failed. His BVN is[REDACTED_BVN]and he can be reached at[REDACTED_EMAIL]or[REDACTED_PHONE].
The AI can still summarize the complaint, classify the issue, and draft a response. The account number, BVN, email, and phone number never leave the organization.
Finance
A finance team member needs help drafting a vendor follow-up.
What they'd normally paste into AI:
Vendor Greenfield Logistics says payment of ₦2,500,000 to account 0123456789 has not reflected. Customer paid with card 4111 1111 1111 1111. Reference: TRX-2026-04-1192.
What the AI would receive after Ekō:
Vendor Greenfield Logistics says payment of ₦2,500,000 to account
[REDACTED_BANK_ACCOUNT]has not reflected. Customer paid with card[REDACTED_CREDIT_CARD]. Reference: TRX-2026-04-1192.
The AI can draft a professional response or summarize the dispute. The bank account and card number are protected.
HR
An HR team member wants to summarize an employee complaint.
What they'd normally paste into AI:
Employee Mary Johnson reported an issue involving her manager, Tunde Bello, during the Lagos office review. Her NIN is 49009006021 and she can be reached at
mary.johnson@company.comor +234 803 222 7711.
What the AI would receive after Ekō:
Employee Mary Johnson reported an issue involving her manager, Tunde Bello, during the Lagos office review. Her NIN is
[REDACTED_NIN]and she can be reached at[REDACTED_EMAIL]or[REDACTED_PHONE].
The complaint summary still works. The NIN, email, and phone number are removed.
Compliance
A compliance officer is preparing an internal review memo.
What they'd normally paste into AI:
Internal review for Q1 2026: employee Daniel Okafor (NIN 49009006021, employee ID EMP-44218) flagged for expense overrides. Forward findings to
legal@acme.exampleand copy auditor Maria González atmaria.gonzalez@auditfirm.example, +234 800 022 7700.
What the AI would receive after Ekō:
Internal review for Q1 2026: employee Daniel Okafor (NIN
[REDACTED_NIN], employee ID EMP-44218) flagged for expense overrides. Forward findings to[REDACTED_EMAIL]and copy auditor Maria González at[REDACTED_EMAIL],[REDACTED_PHONE].
The review context is preserved. Regulated identifiers and contact details are stripped.
What to look for when testing
When you paste prompts into the Playground, you're answering a few practical questions:
Does Ekō catch the data types your organization cares about? BVNs, NINs, account numbers, card numbers, emails, phone numbers, and IBANs are caught by default. If your organization uses custom internal identifiers (employee IDs with a specific format, internal ticket references, vendor codes), note which ones Ekō misses. These can be added as custom patterns before you go to production.
Is the sanitized output still useful? Sanitization is only valuable if the AI can still do the job. If too much context is removed, the output becomes useless. If too little is removed, the risk isn't addressed. The Playground lets you judge this balance directly.
Are there false positives? Sometimes a pattern that looks like an account number is actually an order reference or a product code. Reviewing Playground output helps you spot where Ekō may be too aggressive for your specific data.
This is how you build an informed AI usage policy: not from theory, but from testing against the actual data patterns your teams work with every day.
Setting up the Playground internally
The public Playground at eko-playground.openray.workers.dev works for initial evaluation. But if you want to run it inside your own environment, connected to your own Ekō instance and reachable only on your internal network, your engineering team can deploy it in a few steps.
The Playground is a lightweight web app built with TanStack Start and deployed on Cloudflare Workers. The source is available in the Ekō Playground repo.
Prerequisites: Your team needs a running Ekō instance. The setup guide for Ekō itself is at openray.ai/projects/eko.
Deploy the Playground:
-
Clone the Playground repo:
git clone https://github.com/Openray-ai/eko-playground.git cd eko-playground -
Set the
VITE_EKO_URLenvironment variable to point at your internal Ekō instance:export VITE_EKO_URL="https://eko.internal.yourcompany.com" -
Install dependencies and deploy to Cloudflare Workers (or any hosting platform that supports Workers):
npm install npm run deploy
Once deployed, share the internal URL with your compliance, finance, HR, and support leads. They can test against your own Ekō instance with your organization's detection patterns, including any custom patterns your team has added.
From Playground to production
The Playground is a testing and evaluation tool. It's step one. Once your stakeholders have tested realistic prompts and are confident in what Ekō catches, the path to production involves three things:
Custom detection patterns for any organization-specific identifiers Ekō doesn't catch by default. These are regex rules added to Ekō's configuration.
Integration into existing workflows. Ekō works as a drop-in proxy: any tool that calls OpenAI or Anthropic can route through Ekō by changing a single URL. Support dashboards, internal AI assistants, CRMs, and workflow automation tools can all be pointed at Ekō without changing their application code.
Policy and governance. The Playground testing gives compliance teams the evidence they need to write an informed AI usage policy: which data types are protected, which workflows are approved, and what controls are in place.
The details on production deployment, proxy configuration, and custom patterns are covered in the Ekō documentation.
Ekō is open-source and MIT-licensed. Source at github.com/Openray-ai/eko. If you run into issues or want to suggest a detection pattern, open an issue on GitHub.