4nus1smu

Inspiration

We are just university students trying out hackathons because we are interested in learning more things. We know that the tech world right now is very competitive, and joining hackathons allows us to expand more on our knowledge and be aware of this forever changing tech world.

What it does

This middleware we built is meant to prevent Agents from retrieving information they should not have access to. The Agent will try to do it, but the backend will prevent it, because the Agent lacks the access.

How we built it

We split the work equally across three members. Member 1 owned the backend enforcement logic and all merges. Member 2 owned the mock resource service and the test suite, including trying to break the system afterward. Member 3 owned the frontend components, the architecture diagram, README, and demo video.

Since we are beginners, we utilised AI heavily, but approached it with a learning mindset and continuously prompted it to explain the "how" and "why" behind what it generated, rather than just accepting working code.

Our stack: Node.js and Fastify for the backend, React and TypeScript for the frontend, Python and FastAPI for the mock resource service, Docker for running each Agent turn in its own disposable container, and BytePlus ModelArk as the model endpoint. Claude Code was our main AI coding tool throughout.

Challenges we ran into

One challenge that gave us a real scare was an API key leak. Our ARK_API_KEY was leaking in plaintext through our Docker Compose configuration, meaning anyone who ran docker compose config could have seen it in the output. We caught it, moved to Docker secrets instead, and re-verified the output was actually empty before moving on. It was a reminder that "it's not in the source code" isn't the same as "it's not exposed anywhere."

Another was the one-time secret display. Our whole design depends on the token secret being shown to the user exactly once, right when it's issued or reissued, and never being recoverable after that. At one point during live testing, that one-time secret just wasn't appearing on screen when it should have. It's a small UI bug, but it mattered a lot to us, because that one moment is the entire proof that our "hash only, never stored raw" claim is real and not just something we say in the README. We fixed it, but it meant we couldn't fully trust that part of the demo until we'd watched it work with our own eyes, not just watched the build pass.

The last one was more about how we worked together than any single bug. Even though we split the project into separate pieces so we could work in parallel, none of us could fully test our own part in isolation. The frontend needed the real backend endpoints working before it could show real data instead of placeholder fixtures. The backend's enforcement logic needed the mock resource service running before a fetch could actually succeed or fail for real. Testing the full picture, not just each person's own slice, meant waiting on each other at several points.

What we learned

This was our first time using Docker at all, so just getting comfortable with containers, what they isolate, and why the platform runs each Agent turn inside a disposable one, was new ground for us.

We also had to keep learning how to prompt AI tools better as we went. Getting Claude Code to actually explain the how and why behind what it generated, instead of just accepting working code, took deliberate effort and got easier the more we practiced asking for it.

Most of all, we came out of this actually understanding what middleware is and why it exists, not just as a term but as a design decision. We learned that the value isn't in the Agent itself, it's in the layer that sits between the Agent and anything it's allowed to touch, and that this layer is what makes a system trustworthy even when the Agent isn't.

Accomplishments that we're proud of

Even though we heavily relied on AI, we're quite proud of being able to work with friends and achieve knowledge out of this. We all learnt things that probably would not have been taught in school.

What's next

We'd want to further our knowledge on the hows and whys, going deeper into the reasoning behind the middleware patterns we used rather than just the implementation itself.

Built With

• byteplus
• claude
• docker
• fastapi
• fastify
• node.js
• python
• react
• typescript