Inspiration

Employees already use frontier AI, but organizations often face a false choice: allow uncontrolled copy-and-paste or block the tool entirely. Generic controls can also miss Thai identifiers and locally meaningful risk. We built a policy point that sits before AI egress and makes each route visible and testable.

Who it is for

REDACTRA is designed for Thai healthcare, financial, legal, HR, and contact-center teams that want employees to use managed AI web apps without copying raw customer, patient, or employee identifiers into external services. Instead of forcing organizations to choose between unrestricted AI and blocking AI entirely, REDACTRA provides a visible and testable path to tokenize, review, block, or allow each request.

What it does

REDACTRA intercepts prompts before send. Local detectors find Thai sensitive entities, while Rule/ML controls hold locally recognized risky intent. Detected sensitive data stays on-device on tokenize, review, or block paths. For approved workflows, reversible placeholders can leave the device and the authorized user sees values restored only in the originating local session.

Local checks and GPT-5.6 have different jobs. Local detectors answer: does this request contain data that must not leave the device? Only after those checks pass, GPT-5.6 answers: could the identifier-free business intent still create organizational risk? The current PoC sends only policy-eligible prompts—zero detected sensitive entities, no local hold, and sufficient context for semantic review—to GPT-5.6 through the OpenAI Responses API. GPT-5.6 returns a strict structured allow, review, or block recommendation, and the Local Agent applies the final decision. The current context threshold controls cost and review coverage; it is not used as a safety score.

How we used Codex and GPT-5.6

Codex accelerated the Build Week implementation by tracing the existing Browser Guard and Local Agent trust boundary, implementing the isolated GPT-5.6 structured-risk route, building the judge-facing Proof Console, creating executable zero-call integration tests, and keeping the documentation and submission claims aligned with verifiable code. The human team retained ownership of the problem definition, privacy boundary, policy decisions, and final claims.

GPT-5.6 has a narrow runtime role after the local privacy and intent gates. It evaluates organizational meaning that identifier matching alone cannot understand and returns a structured risk assessment. It never receives the local restore capability and does not make the final egress decision.

How we built it

  • Manifest V3 Browser Guard for approved AI web apps
  • Loopback Node.js Local Agent with an Origin allowlist, policy engine, in-memory Token Vault, response guard, and SHA-256 audit chain
  • GPT-5.6 Responses API with strict Structured Outputs and store: false
  • Versioned Thai Enterprise and Healthcare language packs
  • Reversible placeholder tokens restored only for the originating local session
  • React/Vite Proof Console showing the routing boundary in four stages
  • Integration request capture proving detected-sensitive and locally held prompts make zero OpenAI calls

Challenges we ran into

The hardest part was proving the negative without overclaiming. Our executable tests prove that routes with locally detected sensitive data do not call OpenAI, while public-safe audit evidence excludes raw values. No detector is perfect, so we explicitly document false-negative risk, keep the policy and language packs versioned, and fail closed for unsupported or uncertain document-processing states.

Accomplishments that we're proud of

The novelty is not the generic gateway category. It is the combination of Thai-first language packs, reversible local tokenization, and executable privacy evidence. Cheap and detected-sensitive decisions stay local; GPT-5.6 is used only after the privacy and intent gates, where semantic organizational context adds value. The demo makes that boundary visible as Local Scan, What GPT-5.6 Saw, Semantic Result, and Final Egress Control.

What we learned

Privacy claims need executable negative tests, not only architecture diagrams. We also learned to distinguish detected-sensitive data from an impossible guarantee, separate repeatable fixture mode from live evidence, and label synthetic evaluation honestly rather than presenting it as production accuracy.

What's next for REDACTRA

Thai is our beachhead. Next we will expand the versioned language-pack interface, replace the simple PoC context threshold with calibrated detector-confidence and uncertainty policy, add per-installation Local Agent authentication and managed-browser deployment, and validate detection quality on representative data under an approved privacy process.

Built with

OpenAI Responses API, GPT-5.6, Codex, React, Vite, Node.js, TypeScript, Manifest V3, fastText, and deterministic evaluation fixtures.

Built With

Share this project:

Updates

posted an update

As one of the developers, I am really proud of what our team built with REDACTRA. We worked on a real problem that many Thai organizations are facing (PDPA law). People want to use AI at work, but customer, patient, and employee data should not be sent outside without protection. REDACTRA checks Thai sensitive data locally before anything goes to AI. We also built tests to prove that sensitive requests make zero OpenAI calls. It was not an easy project, and we learned a lot while improving the system and the demo. I believe REDACTRA is a practical step toward safer AI use in Thailand. I am very happy to be part of this team and see our idea become a working product.

Log in or sign up for Devpost to join the conversation.