Hey everyone, I've been lurking for a bit while we evaluate new dev tools. I'm pretty new to this whole B2B software procurement thing, but I kept hitting a wall with one requirement: compliance logging for AI tools.
My team was excited to try Amazon Q Developer, but our infosec team immediately asked, "How do we audit the prompts and responses?" There didn't seem to be a built-in way to log everything locally, which was a dealbreaker for us.
Instead of giving up, I spent the weekend building a simple local proxy server. It sits between my IDE (using the Q plugin) and Q itself, and it logs every single prompt I send and every response I get back to a timestamped JSON file on my machine. It's not fancy, but it means we have a complete record for compliance.
It's basically a Node.js script that uses `http-proxy`. The key part is intercepting the request body to log the prompt, and the response body to log Q's answer. I run it locally on a specific port and just point my Q plugin settings to ` http://localhost: [port]` instead of directly to Amazon Q.
This has made our compliance officer much happier while we're in the trial phase. Has anyone else tried something similar? I'm wondering if I'm overcomplicating it or if there are better approaches. I'd be happy to share the basic code if anyone's interested, though fair warning—I'm not a senior dev, so it might be a bit rough around the edges 😅
Interesting approach, but you're creating a pretty significant compliance gap. That local JSON file is not a secure, centralized audit log. It's sitting on one dev's machine.
If you're serious about compliance, you need immutable logs shipped to a central system like a SIEM or a secured S3 bucket with object locking. A local proxy is a good first step, but the logging endpoint needs to be something that infosec actually controls, not a file on your laptop. Have you considered having your proxy write to a Fluent Bit sidecar or push directly to CloudWatch Logs with a strict retention policy?
What happens when the dev machine gets re-imaged?
Automate everything. Twice.
You're absolutely right about the centralization and immutability problem. A local JSON file fails the basic "trust but verify" principle for audit trails. The performance overhead of pushing to a secured S3 bucket with object lock is negligible, maybe 10-20ms per request, which is trivial compared to the LLM round-trip.
But the real gap is in the threat model. A local file is vulnerable to both accidental loss and intentional modification by the very user whose activity you're supposed to be auditing. That defeats the purpose. The proxy architecture is sound, but its output needs to be a write-only pipe to a system the developer cannot alter.
numbers don't lie