SentinelOS

What inspired me

I am taking a computer systems course this semester, so I have been thinking a lot about processes, files, and system calls under the surface. At the same time, I saw more projects connecting LLMs directly to folders, browsers, and desktop actions. The core risk is not only a bad chat response. The bigger risk is that once a model is connected to the OS, it may run commands, open files, or change data in ways that are harder to control.

That inspired me to treat agent operations as OS level actions that should be classified, logged, and sometimes blocked or reversed. Instead of assuming the model is the safety layer, I wanted a control layer around it.

What I learned

I learned that I did not need heavy infrastructure to build a meaningful systems project in one weekend. FastAPI and Pydantic were enough to keep mediation requests structured and testable, and SQLite was a great fit for storing audit records, authority timeline events, preference memory, and rollback data without running a separate database server.

I also learned that Python plus native C is powerful but not frictionless. ctypes integration worked, but debugging dynamic loading, path handling, and fallbacks took real time. On the frontend side, I learned that a dashboard only feels credible when it matches backend truth. The heatmap, timeline, and audit views needed several iterations before they aligned with real API records.

How I built the project

I built the backend with FastAPI. File paths, browser URLs, and process launches go through mediation layers that estimate sensitivity and risk, then return policy decisions such as allow, limited, confirm, or deny. I stored audit entries, decaying preference weights, authority timeline events, and rollback records in SQLite so the system can explain what happened and why.

For the native layer, I wrote a small C shared library for path normalization, filesystem checks, hashing, capability guards, and sandboxed process primitives. The Python backend loads the native library with ctypes when available and falls back when it is not.

For the frontend, I used React, Vite, and Tailwind CSS to build the mediation console, hooks view, heatmap, authority timeline, audit log, rollback interface, and profile pages. I also included a Postman collection so judges can test APIs directly.

For preference learning, I used a simple decay model so old feedback gradually matters less. In plain terms, each updated preference is a decayed prior score plus the newest feedback update.

Challenges I faced

One major challenge was making native loading reliable across environments. .dylib and .so path issues were easy to hit, so I had to ensure fallback behavior was correct and visible instead of silently hiding failures.

Another challenge was keeping the UI honest. Early dashboard versions looked good but did not match backend data structure, so I reworked heatmap and timeline views to reflect the same audit and authority records returned by the API.

The hardest challenge was scope. I had more ideas than one weekend could support, especially for deeper policy controls and advanced rollback semantics. I narrowed the project to a clear demo workspace, a strong mediation flow, and a reliable rollback path that is understandable during judging.

Built With

• c
• css
• fastapi
• pydantic
• python
• react
• sqlite
• vite