The ideal amount of fraud is 0. But you need to operate in a high trust society.
My neighbors run a farm. They sell potatos, eggs, flowers, pumpkins. All unattended. You drop the cash and pick whatever you paid for. No one is watching. I don’t know how much theft they suffer, but not enough to stop doing it.
> I don’t know how much theft they suffer, but not enough to stop doing it.
That's the point, though. In a high-trust society a lot of things are easier, and that can make up for some amount of abuse of that trust (the challenge is, can it be made up for both locally and globally, because if individuals start having reasons to trust less then it can erode the whole thing).
It takes money to monitor and maintain those systems which in turn translate to higher shipping costs that may very well cost more than the theft you want to stop.
They will probably re-evaluate after this. Another thing is to send additional security with a trailing car. Hopefully assigned at random so it can't be someone connected with the driver. I know someone was shipping shelled walnuts and they did that as a semi full of those things can be in the many hundreds of thousands of dollars/euros in value.
Many people don't wanna depend on US products. If US switches them off, you are gone. Not even talking about privacy of US companies. Nor talking about guardrails that let you not do things you need to do.
1) What kind of guardrails are you using? Do you do models like prompt injection checkers? Or what guardrails are useful that do not know the environment the agent lives in?
2) I heard Bifrost also works for this. Did you try that as well, pros/cons?
I'm not the person you asked but yes pretty much. I've found the prompt injection protection models pretty limited, but get good results from gpt-oss-safeguard with a policy describing various prompt injection techniques. More expensive but more flexible and reliable and I only run it on web fetch and web search results. Costs me like 5-20 cents a day depending on what I'm working on.
Still working on deploying it and setting it up with cloudflare sandboxes so I don't have deep expertise and need to experiment first before I can give advice
It also means security is not held as high and vulnerabilities not as much found. A simple 0-day may survive for years. Not much effort needed to have permanent access.
Its easier for an LLM to find vulnerabilities in a project with less usage, and those vulnerabilities will stay open longer, making them much cheaper to attack to keep the door open.
What's the point of attacking projects that almost nobody uses?
Do you think Netanyahu, Trump or Xi-Jinping are somehow secretly using Cosmic DE at home, to be worthy targets?
Bad actors have limited time, lives of their own and mouths to feed as well, so they concentrate their efforts where "the fish are" if they want to PWN someone for profit.
That's why Windows was the biggest target in the past for so long and why MacOS and Linux were ignored. Because most of the fish were on Windows.
Offensive security employees, tokens, and peoples' time are still a finite resource that get allocated based on target priorities and operational end-goals, even by state actors.
If you assume Mossad and NSA are Token-maxxing every single niche FOSS project out there to cast as large as possible fishnet on hacking all Average Joes on the planet just in case, then maybe using Mozilla and MacOS gets you hacked too, maybe even visiting HN and commenting here gets you hacked by some zero days you don't yet know.
No. Prefix caching is just an optimisation on the server side. What Kimi CLI does is insert tags that include a checkpoint marker with an id.
The model is then given a tool that allows the model to decide to roll back to a checkpoint + a message containing any additional useful information.
It's specifically instructed to use that tool[1] in cases like when it has inadvertendly read a large file where most of the content is not relevant to the task, or after a web search where it's found what it's looking for but most of the content isn't needed, or when it's written code that didn't work as expected, or similar.
It basically lets the model backtrack and "forget" irrelevant details at the end of the context but give itself hints on how it should continue from the checkpoint.
Though, interestingly they seem to be abandoning it in their new CLI (kimi-code), unless it's been folded into other functionality. Not sure if they just feel it's not needed any more with their newer models or if it just didn't work as well as they expected.
Prefix caching automatically detects priorly read tokens -> more fained grained checkpoints then. With prefix caching you don't have to ask for a checkpoint, its automatic.
One way or the other, a prefix is saved. Only the additional info how to continue is new.
Are you able to just re-run the data for the timeframe, or is "fixing it" a more manual process? And what observability are you working with into the process?
reply