RaccZero

Executive summary

Employees can send credentials, customer information, or internal documents to AI services in seconds. I built RaccZero to intervene at that browser decision point. Its extension, policy backend, admin portal, and employee portal turn AI use rules into a visible workflow for supported interactions.

The alpha discovers AI sites and checks supported prompts, pastes, files, and images with deterministic rules. It offers warnings, redacted alternatives, blocks, justifications, and exceptions. Relevant events can feed incident, reporting, vendor-risk, and compliance views.

A source review found meaningful depth alongside gaps in telemetry privacy, identity, migrations, builds, policy consistency, and recovery. RaccZero remains an alpha. It has not demonstrated production coverage, reduced data loss, or readiness for enterprise deployment.

Project at a glance

The problem

Users can paste secrets or upload documents to AI sites in seconds. Training sets expectations, but the browser is where timely feedback can change the action.

A useful control has to distinguish a harmless example from a likely secret, explain its response, and offer a path for legitimate work. It also has to avoid becoming another store of the material it is meant to protect. RaccZero addresses this browser workflow for supported sites and inputs. It is one layer alongside organizational policy, classification, endpoint controls, and provider agreements.

Design goals

• Intervene before a supported submission reaches an outside AI service, while the user can still edit it.
• Use clear actions: allow, warn, offer a redacted alternative, block, or record an allowed justification.
• Give administrators policy, catalog, incident, and reporting views, with a separate employee route for activity and exceptions.
• Connect qualifying events to incidents and governance evidence without assuming every detection creates an incident.
• Keep decisions explainable and measure false positives, missed detections, and bypasses before pilot claims.

Architecture and request path

Four surfaces divide the work. The extension sees supported browser actions and presents decisions. The backend evaluates policy, stores events, and coordinates incidents. The admin portal exposes rules and review queues. The employee portal provides activity, justification, and exception views. PostgreSQL and Redis appear in the intended deployment design; the reviewed local state uses SQLite.

A governed interaction

1. A user opens a supported AI site in a Chromium browser with the extension installed.
2. The extension recognizes the site, syncs catalog and rules, and intercepts a supported prompt or file action.
3. Local checks and, where required, the backend evaluate content against deterministic patterns and configured policy.
4. The user sees an allow, warning, redacted option, or block, with justification or exception steps where supported.
5. The backend records the relevant event. A block can create an incident and feed governance evidence.
6. Security staff review incidents and rules in the admin portal; employees can review their own activity and requests.

This is the intended path for supported interactions. Browser site changes, unsupported input methods, offline decisions, and inconsistent policy scopes mean the current alpha cannot claim universal coverage or reliable blocking in every condition.

Key engineering decisions

Put the control before the submit action

RaccZero intervenes before browser submission to an outside AI provider. The extension can cancel a send action, ask the backend for a decision, or use limited local rules in an outage. Users can then edit, redact, or request an exception.

The extension depends on recognized sites and page behavior. It does not govern unmanaged browsers, desktop apps, mobile apps, direct APIs, or every input path. Errors can allow activity to continue, so coverage and outage behavior need pilot tests.

Separate detection from policy action

Regex and heuristics make findings explainable and partly usable offline. The sanitizer adds data type, source, confidence, and example context. Rules can warn, block, or offer redaction, leaving room to tune false positives.

The review found group and department scopes, exemptions, and categories that do not always match enforcement. A saved rule is not proof of protection. A pilot needs a tested matrix for each scope, category, and action.

Preserve the human decision trail

Justifications, exceptions, incidents, vendor risk, and compliance mappings make detections reviewable. A block can trigger evidence and alerts. Other high-severity results do not always create incidents as documented, and Rapid7 live forwarding remains stubbed. The event contract and delivery need tests.

Build the operator surface alongside enforcement

The admin portal covers catalog, policy, incidents, reports, risk, and compliance. Employees have activity and exception views. Admin TypeScript passed; employee TypeScript failed. Both portals need distinct token roles and consistent authorization.

What was built

Four application surfaces and a deployment design exist, pending contract and clean build validation.

The source review counted about 16,735 lines and 100 API endpoints, which measure implementation scale. On the existing database, 31 backend tests passed; an isolated run passed 30 and failed one. Admin TypeScript passed, while employee and extension checks failed. These are engineering observations, not prevention results.

The hard parts

Browser coverage and client trust need proof

The extension has broad browser permissions but only attaches its guard to recognized AI sites. Its page selectors can drift as providers change their interfaces. The backend also accepts several public scanning and workflow requests without strong device identity or consistent quotas. A production pilot needs managed enrollment, bounded compute and write routes, health reporting, and tested site coverage.

Several error paths let a user continue when the backend or extension is unavailable. That favors continuity, but it weakens any unconditional prevention claim. Administrators need an approved outage policy by severity, visible degraded status, and tests that prove what the user sees during failure.

Privacy must hold on every event path

The review identified a telemetry privacy defect: sensitive excerpts were not consistently redacted before ingestion. Before any real-data pilot, browser serialization and backend ingestion must enforce minimization. Canary tests should prove that sensitive values do not appear in stored events, logs, or outgoing notifications.

A working local database is not a recoverable release

The local SQLite database contains the active development state. The intended production stack uses PostgreSQL and Redis, but a clean rebuild is blocked by migration gaps and startup logic that assumes SQLite. The employee portal build also fails, and the current tests depend partly on existing developer data. RaccZero needs one reviewed migration path, isolated tests, clean builds, backups, and a practiced restore before it can be operated reliably.

Validation and current state

The current documentation calls the product v0.4.0-alpha, while API, extension, and package identifiers disagree. This case study therefore describes the reviewed alpha rather than presenting a single version as authoritative. The strongest evidence is a coherent implementation across browser, backend, and two portals. The review did not verify production protection, clean rebuildability, or reduced data loss.

• Observed: AI catalog and activity views, deterministic detection, sanitization, OCR paths, warning and block interfaces, employee requests, incidents, reports, and governance mappings.
• Validated with limits: 31 backend tests passed on the existing local database; an isolated run passed 30 and failed one. The admin typecheck passed, while employee and extension typechecks failed.
• Release blockers: telemetry privacy, token role separation, policy scope consistency, clean migrations, employee build, test isolation, authenticated ingress, and verified backup restoration.

Current limitations

Everything the review found open stays open on this page until evidence shows it closed. As of the reviewed working tree:

• Coverage. The guard attaches only to recognized AI sites and supported input paths. Unmanaged browsers, desktop and mobile apps, direct API use, and unsupported input methods are not governed, and page selectors can drift as providers change their interfaces.
• Outage behavior. Several error paths let a user continue when the backend or extension is unavailable. That is a continuity choice, and it means no unconditional prevention claim holds.
• Telemetry privacy. Sensitive excerpts were not consistently redacted before ingestion. This is a defect, not a design choice, and it blocks any real-data pilot.
• Identity. Admin and employee token roles are not separated, and several public compute and write routes accept requests without strong device identity or consistent quotas.
• Policy consistency. Group and department scopes, exemptions, and categories do not always match enforcement. A saved rule is not proof of protection.
• Migrations, builds, and recovery. A clean rebuild on the intended PostgreSQL and Redis stack is blocked by migration gaps and SQLite-assuming startup logic. The employee portal build fails. Tests depend partly on existing developer data. No backup-and-restore has been practiced.
• Alerts. Rapid7 live forwarding is a stub, and alert delivery is not durable.
• Identifiers. Four version strings disagree, so no single one can be cited as authoritative: project documentation says v0.4.0-alpha, the extension manifest says 0.3.3, the backend says 0.3.3-alpha, and both portal packages say 0.1.0. That is why the evidence snapshot above records the version as conflicting alpha identifiers rather than picking one.
• Outcome. No production coverage, reduced data loss, or enterprise readiness has been demonstrated.
• Reproducibility of the review itself. The reviewed state was a working tree that included five uncommitted files, so it cannot be restored from repository history alone. The assessment artifacts behind this write-up are held outside the project repository and have not yet been brought under version control.

What this project demonstrates

RaccZero shows how I translate AI governance into an application workflow: browser interception, explainable decisions, employee choices, administrator review, and evidence for risk and compliance work. The source review also shows my willingness to test the uncomfortable boundaries, especially where a control’s privacy claim, authorization rule, and rebuild procedure must match the code.

The build spans extension engineering, Python APIs, React interfaces, data modeling, policy design, and security operations. The next engineering result to show is a clean, tested release, not another feature count.

AI-assisted development, human-owned decisions

AI assisted parts of the design and development process. The architecture choices, threat boundaries, review priorities, and acceptance gates remain human decisions.

Next phase

• Preserve the current source, uncommitted files, configuration, and local database as a recoverable development baseline.
• Fix telemetry redaction at the browser and backend boundaries; add canary tests across database, logs, and downstream output.
• Separate admin, employee, device, and API identities; then test that tokens cannot cross role boundaries.
• Make Alembic the schema authority, fix clean portal and extension checks, and run isolated tests against empty PostgreSQL.
• Prove every policy scope, exemption, category, and incident trigger through an end to end decision matrix.
• Run a controlled pilot only after release gates pass, then measure coverage, latency, false positives, blocks, exceptions, and review time.

Closing

RaccZero is a credible alpha of browser based AI governance with a distinctive connection between point of use controls and human review. The review turns its next milestone into something testable: safe telemetry, distinct identities, consistent policy outcomes, reproducible builds, and a restored deployment. Once those gates pass, a pilot can measure whether it actually reduces risky AI data sharing.