DataGate - USC TrojanHacks 2026 1 DataGate Permission, review, and evidence before data reaches AI. A human-in-the-loop governance gateway that minimizes, redacts, reviews, and rechecks company data before any approved payload is dispatched. Team: Priyanka, Ishita, Yuxin, and Aishwarya | Event: USC TrojanHacks 2026 | Track: AI Data Governance Devpost short description DataGate is a privacy and access-control checkpoint between company datasets and AI services. It verifies who may use a dataset, limits the request to an approved purpose and destination, keeps only necessary fields, detects and redacts sensitive information, lets an authorized analyst review the exact outbound content, and checks permission again at Send. Every outcome produces metadata evidence, while blocked requests make zero receiver calls. Inspiration Teams increasingly use AI to summarize support tickets, analyze feedback, and accelerate routine work. However, the moment a spreadsheet is pasted into an AI tool, an organization can lose visibility into which fields were shared, whether the employee had permission, and whether the selected use was allowed. Redacting obvious identifiers alone does not solve this problem: unnecessary columns can still leave the organization, permissions can change after a preview, and there may be no reliable record of the decision. We built DataGate to make the path from company data to AI controlled, reviewable, and testable. What it does A support analyst signs in with a demo account and sees only datasets that account may access. The analyst chooses a purpose and destination. DataGate evaluates the owner policy, validates the source, retains only the fields required for that purpose, and prepares a minimized payload on the backend. Access and purpose enforcement Dataset access, allowed purposes, approved destinations, and sharing mode are enforced by the backend. Unauthorized datasets, model-training requests, and public-chatbot destinations are blocked before dispatch. Sensitive-data protection Email addresses and phone numbers are redacted by default. Optional policy-controlled detectors cover person names, SSNs, credit-card-like values, street addresses, IP addresses, and dates of birth. DataGate - USC TrojanHacks 2026 2 Interactive review The analyst compares permitted source text with the outbound version, hides complete messages, or manually redacts selected text. Mandatory policy redactions remain locked and cannot be reversed. Context-preserving pseudonyms Repeated detected person-name surfaces can receive stable request-scoped placeholders such as [PERSON_1], preserving conversational structure without sending the original name. Policy explanations The interface explains why each field was included, excluded, or redacted, making the decision understandable rather than presenting a mysterious allow/block result. Send-time recheck Approval is bound to the account, dataset revision, policy fingerprint, transformation pipeline, review revision, and payload hash. Revoked access or changed data/policy invalidates the old approval. Audit history and receipts Creator-only history records previews, reviews, sends, blocks, permission changes, redaction counts, hashes, and receiver outcomes without storing full customer messages in receipts. Security evidence A dashboard displays actual isolated regression-test evidence and clearly labels missing, stale, partial, or failed reports instead of treating tests as timeless guarantees. How we built it Frontend: React, TypeScript, and Vite provide the request form, dataset passport, comparison review, policy explanation, approval flow, receipt history, and security-evidence views. Backend: FastAPI and Pydantic expose a strict API. Python handles policy evaluation, CSV validation, field minimization, identifier detection, redaction, canonical JSON creation, SHA-256 hashing, and the request state machine. Storage: SQLite stores accounts, policies, grants, request metadata, events, and receipts. Raw source data stays in backend-held fixtures, and complete outbound messages are not stored in receipts. Dispatch: Every delivery passes through one receiver-adapter boundary. The hackathon demo uses a local capturing receiver, so it requires no external API key and does not claim that an external model was called. The end-to-end flow 1 Choose Analyst selects an accessible dataset, approved purpose, and destination. 2 Evaluate Backend checks identity, access, owner policy, destination, and source validity. 3 Minimize Only purpose-required fields are retained; unexpected fields are never forwarded. 4 Protect Configured identifiers are redacted and person surfaces may be pseudonymized. DataGate - USC TrojanHacks 2026 3 5 Review Analyst sees the exact outbound payload and may hide or redact additional content. 6 Approve The current review revision and canonical payload hash are explicitly approved. 7 Recheck Access, source, policy, detector pipeline, review, and hash are checked again. 8 Dispatch Only the winning atomic Send reaches the receiver; duplicate sends are rejected. 9 Record A metadata-only receipt and audit event describe the real result. A key architectural choice is that the browser never submits replacement outbound text. It submits only constrained review choices. The backend rebuilds the authoritative payload from the current source and owner policy before sending. Challenges we ran into • Preventing preview-time approval from becoming permanent permission. We bound approval to current versions and added a final check immediately before dispatch. • Making redaction useful without allowing bypasses. Analysts can hide more content, but cannot restore policy-required identifiers or add excluded fields. • Handling overlapping findings. The transformation pipeline applies explicit precedence and unions overlapping protected spans so a lower-priority match cannot expose part of a higher-priority value. • Preserving context while hiding names. Request-scoped pseudonyms retain repeated-name relationships without persisting a global name mapping. • Reporting evidence honestly. The dashboard distinguishes current results from stale, missing, interrupted, or failed runs and keeps sensitive fixture content out of reports. • Coordinating parallel feature branches. We maintained a shared API contract and module boundaries while extending the baseline with governance, review, detection, and evidence features. Accomplishments that we are proud of • Built a complete working decision path from account selection to minimized preview, human review, send-time recheck, dispatch outcome, and receipt. • Demonstrated that authorized access to a dataset does not automatically authorize every purpose or destination. • Implemented zero-call blocking for forbidden requests and revocation after preview. • Prevented duplicate or concurrent Send actions from invoking the receiver more than once through an atomic state transition. • Added manual review without trusting browser-supplied sanitized text. • Added explainable structured-identifier detection and a separately evaluated person-name detector/pseudonymization approach. • Created creator-only history and metadata receipts that remain useful without exposing complete customer messages. DataGate - USC TrojanHacks 2026 4 • Expanded the repository checks substantially beyond the original baseline and surfaced the evidence in the product itself. What we learned We learned that data governance is not a single redaction step. It is a chain of decisions: identity, dataset permission, purpose, destination, minimization, detection, human review, approval freshness, dispatch, and evidence. A weakness at any one point can undermine the rest. We also learned that privacy controls should fail clearly. A blocked detector, changed policy, stale preview, or uncertain receiver outcome should not silently continue. Honest limitations and visible evidence make the system more trustworthy than a broad claim of compliance. What is next • Integrate one real AI provider behind the existing receiver adapter while retaining the local fallback. • Replace demo account selection with production authentication and an owner administration interface. • Evaluate detectors on broader, independently labeled, multilingual datasets and expand coverage for additional identifiers. • Add deployment hardening, encrypted storage, retention controls, and external audit-log protection. • Test with real organizational workflows and refine policies based on user feedback. Important scope and limitations DataGate is a hackathon prototype, not a compliance certification or production data-loss-prevention system. Demo sign-in is simulated. The current receiver is local. Detection can miss sensitive information or over-redact text. Pseudonymization is not anonymization. Analyst approval is not verified customer consent. Receipts describe actions taken by this gateway but do not control what a future external recipient does after delivery. Prepared from the team-provided baseline, feature, six-governance-feature, and main repository snapshots.
Built With
- and-complete-outbound-messages-are-not-stored-in-receipts.-dispatch:-every-delivery-passes-through-one-receiver-adapter-boundary.-the-hackathon-demo-uses-a-local-capturing-receiver
- and-receipts.-raw-source-data-stays-in-backend-held-fixtures
- and-security-evidence-views.-backend:-fastapi-and-pydantic-expose-a-strict-api.-python-handles-policy-evaluation
- and-the-request-state-machine.-storage:-sqlite-stores-accounts
- and-vite-provide-the-request-form
- api
- approval-flow
- canonical-json-creation
- comparison-review
- csv-validation
- dataset-passport
- events
- field-minimization
- frontend:-react
- grants
- identifier-detection
- key
- policies
- policy-explanation
- receipt-history
- redaction
- request-metadata
- sha-256-hashing
- typescript
Log in or sign up for Devpost to join the conversation.