The Boundary Held. The Role I Needed Doesn't Exist. | Kamiwaza Workrooms
Transcript
All right, the fine folks over at Kamiwaza sponsor this lab. Inherit the boundary but own the gate. This is a essential computer science cyber security control. So let's talk about the initial business case for the lab because what's the point of AI if it's not providing a business outcome and this outcome specifically was to expand the CTO advisor capability for assessing vendors against our 4 plus1 AI infrastructure framework. Right now I have a super powerful agentic workflow in which I have a agent that goes out searches for vendor documentation imports that documentation into a data lake compares that against my 4 plus one AI infrastructure layer very complex prompt that then deterministically goes through each individual layer assesses that I and disposition each layer.
We score it, publish it. It is something that accelerates my business in a way that I've never imagined possible. To date, I'm covering 26 individual AI companies in addition to nine uh first cloud solutions and a deep in and I think CTO advisor style method of research. We've published all this re research in basically a two two and a half month period. But the question is how do I maintain this go going forward and how do I grow it past the bottleneck that is me the human in the loop.
The obvious thing is to hire more CTO advisors give them this agentic process and then win AI research. Well, we know scale breaks everything. And one of the things that we've learned in enterprise I AI is that a single workflow or a single users workflow does not necessarily scale. You have to give a platform type approach to the workflow. And this is where Kami Waza comes in and their Kazin feature uh is something that we put to test. Basically what I wanted to do was one test can I take my agentic prompt my LLMs everything that I've built provide this in a application format which is the Kaizen platform and then create security boundaries this is where we inherit the boundaries but own everything else about the platform let's talk about the boundaries what is it that Kami Waza allows me to do from a security perspective.
They allow me to create this concept which is called a workroom. And a workroom is a collaboration space where you can associate a document data set with it. Uh a specific set of LLMs, prompts, etc. This is the working detail. This is where you build your your your app application compartment in it. You can have multiple workrooms, you can have global workrooms. very configurable. So this is where I started out and built the initial application capability for focused on a single vendor in this case Dell.
So I can have a team of analysts focused to just a Dell account. I can curate what documents go into that data lakeink the semantic search behind it etc at a workg groupoup layer. The boundary is that in order for this to be used the analysts have to have added rights to the data set which is you know that that creates the security or the boundary problem. I'm inheriting this boundary and how did Kamiwaza allow me to mitigate the risk of the data set being contaminated?
Well, they give me uh several controls. The best one that I thought was the ability to basically run the what I would call applet uh this deterministic code that allows me to audit the uh workflow to see if the hash has changed from when the researcher first started the their research to when they ended the research. If the hash has changed, there's contamination. I run a some type of uh recovery or batch process to recover to the original state and data uh does uh contaminated data doesn't get into my end result my output.
What about other workrooms or other analysts? I may want a what we've referred to in the uh past as a firewall between the different analyst groups. Uh for whatever reason, I may not want the super micro team to see the data set or use the data set that the Dale team has access to. So again, this is the natural boundary that Kamiwaza provides. It allows me to create a access control list in which one work group has access to one part of the data set and another work group has another has access to the data set.
How did we test this? Well, it's one thing to provide the controls at the application interface which is which would be reasonable. This is turtles all the way down at the semantic search the actual API level. If I try to access using user credentials from one work group, another work group's data set, it's denied. I think we ran something like uh 271 search results and the only reference from one vendor to another one was within that vendor's documentation. So if super micro mentioned Dell in a competitive doc that would come up but not necessarily the Dell originated documentation.
What does this mean for you in your enterprise in your use case? That means that you have the basic building blocks to create platforms and applications for workg groupoups and have the controls around the data set that you need to make sure that there's not crosscontamination from one group workg groupoup to another work group but you can scale your actual business process. This is what we've learned in this lab. You want to learn more? You want to learn more about AI economics?
Uh the power of one LLM over another one. Uh whether or not loop control, the deterministic AI makes sense. com as well as the Kamiwaza sponsored lab. com. Talk to you next CTO Advisor Lab.
