# Voice memo 01: guidance notes for SHarness (24 October 2026)

*Dinis Cruz, voice memo, 24 October 2026. Transcribed by Otter (otter.ai); the transcript is
published as received, including its transcription errors. Known ones: "Sharna's AI" is
SHarness AI; "Skit" and "skit" are sgit; "sk.ai" elsewhere in the same message is sgit.ai.
Written up as the article [A secure harness for agents](../../articles/secure-harness-for-agents.md).
Content CC BY 4.0.*

---

Dinis Cruz 0:00
Okay, so I want to provide some more guidance notes for Sharna's AI, which is the new project we just created, and the project that I think it's a natural progression from the work we've done with the agent behaviour policies, and this is about executing the the what we call the process behaviour policies, and this is basically the the natural progression where we are actually putting the behaviour policies on top of we try to control what the agent is doing in a kind of stronger harness, but that also will allow the execution of this from outside the agent environment, which is fundamentally creating a secure harness, right? So that's the name of the product, right? Basically, secure harness, which is for the agents, right? Is the agents layer to run securely, right? So, so basically, this is an open source project, and I think what's also very important is to start with like very simple examples, and to start with each of the components actually done in isolation. And we might actually need to create separate CLI projects for that. But for now, we can all put into one, which is the fact that what we have here is we have a network component, we have KMS component, we have a file component, and we have an LLM component, and each of these fundamentally are very simple services that we can run that will basically allow us to provide a layer of isolation for the the models and a layer of security in terms of, for example, where the private keys exist, where the LLM works, where the execution flow, where the business logic is actually controlled, all that jazz, right? And this started historically. Well, this morning, historically, it started by trying to protect and trying to add support to skit, which is our you know secure version, encrypted version of git, to add to secure git the what's it called the the protection of the ability to not use keys in in clear text, right? So there's a whole evolution that we've written there, and actually should add to this repo that evolution. And what we have here fundamentally is now the the flow where. the we have this flow, where we need to now implement the S harness, where the first customer, in a way, the first user or the first real use case is going to be a my normal Claude sessions, but B is going to be Skit. So if we can basically use Skit and the agents that now are using Skit all the time, and we already have a whole bunch of agents running now, you know, kind of 24/7, which are the agents on the newsroom, especially the PHP newsroom. So, so those agents now need to be controlled. In fact, those agents are quite interesting because they are exposed to quite a lot of dangerous data that we need to protect. Right, so ultimately that's the the thing. But what we need to do is also, I think this is also a project that will be quite useful to a lot of people. So we need to basically make this as generic as possible, and it should be even a skill or something as simple that we can really lock down. And for example, like the one of the key principles here is to really lock down the the capabilities and the permissions that Claude can have, right? And I think this actually can the way we design this, this can actually make a big difference because this actually, especially when you look at the the process behaviour policies, right? In fact, we should probably expand this to have file behaviour policies, network behaviour policies, right? Which is kind of the extension of it. Is is fundamentally this idea of defining the behaviour policies for the for what we want to happen, and in this particular case, is what we want to happen to the file system. What we want to happen to the network. So, for example, VCS will become an inline process, but the idea is to make it as simple as possible, as fast as possible, as kind of slim as possible, and then figure out how we back the harden, and then test it out, right, and then see how the flow goes. But so somebody, for example, that is just doing a Hello World Claude, should be able to run this, and then know that at the moment it's not possible for the agent to connect to the internet, right? It's not possible for the agent to build a file system. It's not possible for the agent to make all sorts of other requests, because we are now in line, in there, right? And I think the real power is when you then run a service on this, like let's say for example Cloudflare or somebody else that fundamentally then or AWS right would have another cloud provider that can then offload some of these actions to it so we can then make it even more secure right from this point of view because we're able to apply a lot of our controls and our limitations directly there, and this will actually be quite an interesting workflow to see how you can actually work in practice. But the fundamental point here is to allow people to protect Claude, especially I would say Claude running locally on your laptop, because at the moment, what I think we're doing here, which is super powerful, is we're actually creating disposable users per session, and we're really ramping up the security of running a process controlled by an agent.

Transcribed by https://otter.ai