vedhant
vedhant on Hacker News
Posted by
vedhant on Tuesday June 09, 2026 @11:58AM
from the ask-hn dept.
I primarily use claude code and sometimes cursor. I keep prompting and the agent keeps coding. But git commits are done after meaningful changes, worst case 1 for a small feature. I check critical code myself and whenever the agent messes the code, i need it to revert the changes to a previous change it made (most of the times to the previous prompt). These micro changes is not generally...
The sandboxing pain is real. Sadly, a new VM seems like the most simple and viable solution. I don't think the masses are doing any sandboxing at all. We really need a sandbox solution that is sort of dynamic and doesn't pester the user with allow/deny requests. It has to be intelligent and keep up with the llm agents.
Ofcourse it is not meant as a primary database. What baffles me is that people use it as log storage. As an application scales, storage and querying logs become the bottleneck if elasticsearch is used. I was dealing with a system that could afford only 1 week of log retention!
This actually makes a lot of sense. I have one question though. Why is having 2 microservices depend on a single service a problem?
Even with periodoc rotation of credentials, attacker gets enough time to do sufficient damage. Imo, the best way to solve would be to not handle any sort of credentials at all at the application layer! If at all the application must only handle only very short lived tokens. Let there be a sidecar (for example) that does the actual credential injection.
This is fun! I just posted about my startup and I loved the responses. They were criticizing a lot though, it was fun haha!
This is true. Today its npm, tomorrow it could be some other language. Shouldnt we focus on solving it at the root?
Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.
Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.
This looks amazing!
I have a question. When we create a branch, are we cloning the entire production data? From what I understood was that neon runs a separate compute layer but the storage is the same.
I am working on a platform that simplifies access control in an enterprise.
A lot of cybersecurity attacks happen because of stolen credentials. One big example is the supply chain attack, Shai Hulud. In a lot of enterprises, credential sprawl is a huge issue and figuring out who (people, services, ai agents) has access to to what systems is a paramount task.
At https://gearsec.io, we are building a platform where accesses are created via policies. The result is that, the enterprise doesnt deal with credentials anymore. They only need to define policies and nothing more.
I would love to know if you faced this problem and how are you solving them at your workplace!