Hello Everyone,
I have been working on something which I think was very much needed. I have made sandboxes which you can trace. Underneath it is a custom linux sandboxes running containarized docker instances that provide kernel level isolation to your agents. And this way your agents are truly isolated and on top of that my tool tracks everything said/proposed by LLM and what was actually executed on sandboxes. Please do let me know your thoughts.
well actually .ai domain was very expensive, this was economical choice rather than me jumping on hype train. you can take a look at the website once, the npm package is open source but I am providing these sandboxes out of my own pocket for people to try out, so that is closed on gh. here is the npm link tho-https://github.com/Godcreatebugs/raytrace-cli. I initially started with open source but quickly realized the ebpf traces are locked inside the apple chamber. and you need 2 months to get permission from them. So, I thought rather than building a stack for windwos, linux, mac everyone can come on cloud sandboxes and I can design system better to catch the kernel traces.
I'm not even sure what you are offering after reading this, but cloud is an even harder sell because data / traces leave the network, it will be too expensive for a new project/company to get the compliances necessary
context, I assist others with making these kind of tool and vendor decisions
still, why is markdown and a ralph loop like thing insufficient for this, why is a dedicated tool needed? (hint, I do not think it is, and this will be a question you get asked a lot, so have a good answer that shows understanding)
I am still in beta and would like to gather information on what I can do better. But one of the gap I have felt every major so called observability company offers is they just look at the agent tool calls and say here is what your agent said it did. But on sandboxes you can actually see what happened at kernel level. Maybe you have and env file that should not be touched. You can put a protection there so agent cant read it, your agent might say something and do something. And my thesis is if we can track what agent did rather than said what it did, we have better observability, if you want to try I can personally onboard you! its in beta, open for any feedback
sure no worries. On your Otel note, personally used it, and find that open telemetry just traces the tool call not what happened on kernel. I am just gathering beta testers, thanks for chipping in with ur feedback tho!
What do you think the kernel is going to tell us that our existing traces are not?
(I'm assuming nothing has been compromised)
You do understand that these traces are not something the agent hallucinates, yes? They are generated by the harness which operates the llm, tools, etc... In other words, they are accurate
well if that were the cases we would not have seen thousands of dollars costed in llm and many production databases getting over written, I have seen that.
Also on that note, my tool not only checks kernel level execution of tool calls, its one part of it, I do reverse engineer the chain of thought by what agent actually attempted to do by its actions. that is imp a stronger use case than just tracking what llm proposed. also there is a reason why sandboxes are popular because I believe that people may want to run something in containerized environment and we want to show them what your agent did. you might be individual developer that dont need it. But what if you have a team and you are a team leader - you may want to look into what other team member are doing! boom! log into your dashboard and see everything, every command, every execution. Heck you can essentially gather data on how people are using the LLM and what LLM is doing together. I am not categorizing my product as just "here is the execution trace on kernel" but on top of that whatever I mentioned really do add value imo. that is all part of one combined product
Sandboxing is less mature, but we use containers for our agents in CI. I personally (1) run them in k8s (2) replace my harness builtin tools with Dagger based implementation
If an agent can delete a production database, that's PEBKAC imo. Our agents do not have access to such things.
tl;dr - the solution is to shift-left to deterministic prevention, not stochastic detection and prevention
Hello Everyone, I have been working on something which I think was very much needed. I have made sandboxes which you can trace. Underneath it is a custom linux sandboxes running containarized docker instances that provide kernel level isolation to your agents. And this way your agents are truly isolated and on top of that my tool tracks everything said/proposed by LLM and what was actually executed on sandboxes. Please do let me know your thoughts.
Not touching any project with .si domain, I'm unwilling to feed the ego beast
Do you have a github link? This level of the stack is only considered if it is open source
well actually .ai domain was very expensive, this was economical choice rather than me jumping on hype train. you can take a look at the website once, the npm package is open source but I am providing these sandboxes out of my own pocket for people to try out, so that is closed on gh. here is the npm link tho-https://github.com/Godcreatebugs/raytrace-cli. I initially started with open source but quickly realized the ebpf traces are locked inside the apple chamber. and you need 2 months to get permission from them. So, I thought rather than building a stack for windwos, linux, mac everyone can come on cloud sandboxes and I can design system better to catch the kernel traces.
there are tons of TLDs that are cheap
I'm not even sure what you are offering after reading this, but cloud is an even harder sell because data / traces leave the network, it will be too expensive for a new project/company to get the compliances necessary
context, I assist others with making these kind of tool and vendor decisions
still, why is markdown and a ralph loop like thing insufficient for this, why is a dedicated tool needed? (hint, I do not think it is, and this will be a question you get asked a lot, so have a good answer that shows understanding)
I am still in beta and would like to gather information on what I can do better. But one of the gap I have felt every major so called observability company offers is they just look at the agent tool calls and say here is what your agent said it did. But on sandboxes you can actually see what happened at kernel level. Maybe you have and env file that should not be touched. You can put a protection there so agent cant read it, your agent might say something and do something. And my thesis is if we can track what agent did rather than said what it did, we have better observability, if you want to try I can personally onboard you! its in beta, open for any feedback
OTEL is the standard, we know exactly what agents do, or try to do, without ebpf
as I said prior, I'm not looking for an extra tool for this, I have a solid setup already
sure no worries. On your Otel note, personally used it, and find that open telemetry just traces the tool call not what happened on kernel. I am just gathering beta testers, thanks for chipping in with ur feedback tho!
What do you think the kernel is going to tell us that our existing traces are not?
(I'm assuming nothing has been compromised)
You do understand that these traces are not something the agent hallucinates, yes? They are generated by the harness which operates the llm, tools, etc... In other words, they are accurate
well if that were the cases we would not have seen thousands of dollars costed in llm and many production databases getting over written, I have seen that.
Also on that note, my tool not only checks kernel level execution of tool calls, its one part of it, I do reverse engineer the chain of thought by what agent actually attempted to do by its actions. that is imp a stronger use case than just tracking what llm proposed. also there is a reason why sandboxes are popular because I believe that people may want to run something in containerized environment and we want to show them what your agent did. you might be individual developer that dont need it. But what if you have a team and you are a team leader - you may want to look into what other team member are doing! boom! log into your dashboard and see everything, every command, every execution. Heck you can essentially gather data on how people are using the LLM and what LLM is doing together. I am not categorizing my product as just "here is the execution trace on kernel" but on top of that whatever I mentioned really do add value imo. that is all part of one combined product
We use GoModel for the gateway and visibility
Sandboxing is less mature, but we use containers for our agents in CI. I personally (1) run them in k8s (2) replace my harness builtin tools with Dagger based implementation
If an agent can delete a production database, that's PEBKAC imo. Our agents do not have access to such things.
tl;dr - the solution is to shift-left to deterministic prevention, not stochastic detection and prevention