MidSolvency

Personal Identifiable Information (PII) protection in action
Architecture of MidSolvency

Inspiration

Initially, we set out to build a simple middleware layer that could provide a baseline level of file security and integrity for users. We introduced policies around file creation, deletion, and personally identifiable information, as well as a simulated environment we called the “shadow” workspace, where Agent actions could be executed before affecting the live workspace.

As development progressed, however, we noticed another major issue: token consumption was extremely high. This shifted part of our focus towards improving resource efficiency through token prediction, budgeting, context management, and other algorithmic controls. Over time, token usage analysis and optimisation became one of the most important layers in our middleware, which eventually inspired the “Solvency” in MidSolvency. What began as a file-safety project therefore evolved into a more well-rounded middleware solution focused on both policy enforcement and efficient resource usage.

What it does

MidSolvency evaluates the actual effects of Agent execution and assigns risk levels using predetermined criteria. Low-risk file creations or modifications can be automatically committed, while higher-risk actions can require human-in-the-loop approval or be denied entirely.

It also detects personally identifiable information (PII) and sensitive credentials, redacting sensitive values where necessary to protect user privacy. Alongside these safety features, MidSolvency provides trace logs for auditability and a Resource Governor that monitors and manages token usage through prediction, budgeting, context strategies, and circuit-breaking controls. The resulting metrics were then used during development to identify usage patterns and refine the middleware's resource-efficiency mechanisms.

How we built it

We extended the starter code by inserting middleware around the existing Codex execution path. MidSolvency runs Agent actions in a shadow workspace, compares the resulting changes against the live workspace, then applies deterministic impact and sensitive-data policies to auto-commit, request human review, or deny the action.

We also added a Resource Governor for token prediction, budgets, context control, and circuit breaking, plus Run Trace observability and rollback support.

Challenges we ran into

One of our biggest challenges was unexpectedly high token consumption during Agent runs, which even caused us to hit provider rate limits several times during development. This pushed us to investigate more efficient context strategies, prediction methods, and budgeting controls.

We also had to evaluate MidSolvency across many different scenarios—including low-risk actions, PII handling, human review, denial, rollback, and resource-limit cases—which made debugging and maintaining consistent behaviour challenging.

Finally, we spent significant time researching different middleware and resource-management approaches to determine which methods were actually effective before refining our final design.

Accomplishments that we're proud of

We are especially proud that MidSolvency successfully passed the range of safety and resource-management test cases we set for ourselves.

We also improved resource efficiency through better context handling, state compaction, and more accurate tracking of cached and uncached token usage.

Beyond the individual features, we are proud that the project evolved from a simple file-safety idea into a more complete middleware layer that combines policy enforcement, observability, recovery, and resource governance without sacrificing the Agent’s normal functionality.

What we learned

One of our biggest takeaways was that some of the best ideas can emerge from unexpected problems. Our high token usage initially seemed like just another development issue, but it eventually pushed us to design the Resource Governor and made resource efficiency a major part of MidSolvency.

We also learned a lot about middleware architecture—especially how to place controls around an existing Agent runtime without rebuilding the platform itself, and how features such as policy enforcement and resource management can work together as separate but connected layers.

What's next for MidSolvency

Next, we would like to further optimise MidSolvency’s token usage and improve the accuracy of its resource predictions across a wider range of Agent tasks.

We also hope to explore cloud deployment so the middleware can operate beyond a local proof of concept.

On the security side, future work could include stronger protections against prompt injection, tighter tool and permission controls, and better handling of external side effects that cannot be rolled back as easily as file changes.