Why I built CustodIA
Companies want to use advanced AI, but not every request should be sent directly to an external model.
Some requests contain personal information, confidential identifiers, internal business data, or instructions that conflict with company policy. Completely blocking external AI wastes useful capabilities, but allowing unrestricted access creates privacy, security, and compliance risks.
I built CustodIA to provide a practical middle layer: every request is evaluated before any external model is used.
What CustodIA does
CustodIA selects a governed route for each request:
- Direct external model for approved public content.
- Protected external model when sensitive values must be removed locally first.
- Local-only processing when information must remain inside the trusted environment.
- Human review when policy requires an explicit decision.
- Blocked when the request is prohibited.
The Build Week demonstration focuses on three controlled scenarios using synthetic data.
Public request
The request contains no sensitive information and no policy violation.
CustodIA selects the direct route and makes one authorized call to GPT-5.6 Luna through the OpenAI Responses API.
Protected request
The request contains three synthetic sensitive values: a person's name, a contract identifier, and an email address.
CustodIA detects those values locally and replaces them with protected placeholders before the request leaves the trusted environment.
GPT-5.6 Luna receives only the protected version. The original values are not sent externally.
When the response returns, CustodIA verifies that every placeholder appears exactly once and has not been modified, omitted, duplicated, or invented. The final response is then reconstructed locally.
Blocked request
The request violates policy.
CustodIA blocks it before an external adapter or model call is made. The evidence records zero real provider calls.
Privacy and evidence
The demonstration stores only minimized governance evidence.
It does not persist:
- prompts;
- model responses;
- sensitive values;
- reversible placeholder maps;
- provider payloads;
- IP addresses;
- request headers;
- API credentials.
The OpenAI request uses store=false and does not use retries, streaming, tools, background execution, conversations, or fallback models.
How I used Codex
Codex was the main development agent used during Build Week.
I used it to:
- turn the existing CustodIA foundation into a hosted judge demonstration;
- implement the Railway deployment package;
- build the three-scenario interface;
- create and run tests;
- audit privacy and security boundaries;
- diagnose deployment and Responses API issues;
- correct realistic response parsing;
- validate placeholder protection and local reconstruction;
- remove temporary diagnostic code;
- prepare deployment and submission documentation.
Human authorization remained separate from Codex and from the presence of API credentials.
How I used GPT-5.6
GPT-5.6 Luna is used in the authorized external routes.
Public requests are sent directly after policy approval.
Protected requests are sent only after sensitive values have been replaced locally. The returned response is validated and reconstructed locally.
Blocked requests never call the provider.
Challenges I faced
The hardest part was not simply calling a model. It was preserving the governance guarantees across the entire hosted flow.
Railway deployment required careful handling of HTTPS ingress, Host and Origin validation, health checks, authorization controls, rate limits, and a kill switch.
Another challenge was parsing realistic Responses API payloads. Real responses can contain reasoning elements before the assistant message, multiple output elements, and nullable fields. A completed response containing error: null was initially treated as a failure. I reproduced the structure, corrected the parser, added tests, and verified the protected route with a real GPT-5.6 Luna call.
The protected scenario also required strict validation. CustodIA must fail closed if a placeholder is missing, changed, duplicated, or unknown.
What I learned
Governance cannot be added after a model call. It must be part of the execution path.
Credentials and authorization should also be separate. Having a valid API key must not automatically permit external execution.
I also learned that simplified test fixtures are not enough. Real provider responses expose assumptions that synthetic examples may hide.
Finally, a working demonstration is not the same as a production system. This submission proves the governed flow with controlled synthetic scenarios, but it does not claim production readiness.
What's next
The next stage is a professional client-server version of CustodIA with:
- an assistant-style user experience;
- long prompts and document attachments;
- multimodal requests;
- central administration;
- configurable organizational policies;
- roles and permissions;
- multiple external providers;
- local-model routes;
- human-review workflows;
- stronger audit and retention controls;
- multi-user and multi-device validation.
Current status
Ready for a controlled judge demonstration.
Not authorized for production.
Log in or sign up for Devpost to join the conversation.