ToIP: AI and Human Trust WG - 2026/09/10

Morning folks. Just uh sharing that I got to get some breakfast. So I'm going to be on my iPad, but I am here and listening in. >> Morning. >> Morning, Lyn. Uh I know he's just uh you're just up north and it looks like it's blowing pretty good there, Lynn. >> Uh absolutely. Uh every year it gets windier, so today's a great example. >> Yeah, that's pretty strong. That's uh maybe that the wind's blowing down this way. Uh Lind lives just north of me up in Are you in Victoria or Vancouver? >> Uh Vancouver. Uh Drummond. Oh, okay. There we go. >> Do north >> on the on the edge of the water. So, that >> makes a little more wind perhaps, but uh >> yeah, definitely >> distracting to say the least. >> Yeah. >> Wait, you actually live somewhere, Drummond? >> I'm here for a whole week, Steve, and then uh off to DC next week. So, which actually yeah, I'll be flying back next Thursday, so I won't be on the meeting next week. But anyway, I've got, as I was saying, I'm got to eat breakfast, so I'm going to be on my iPad. So, uh, but I'm here. >> Hey, did you meet with um, uh, Singaporean? Did you go to Singapore on your trip? Right. >> I did not, not on this trip. I did talk to some folks, >> you know, uh, Glenn Gore and and there were some other folks at GDC who are, you know, from Singapore that, but I I No, I was not in Singapore on this trip. Glenn is from Singapore. Okay. Anyway, I talked to a guy in um earlier uh that I'm going to be in contact with who's in their uh Singapore AI safety hub. So, >> yes, >> I know there's some people I know who are that, but anyway. So, I'm going to be feeding him trust over IP stuff because he is looking for it and and hardcore. >> Yes. and and and just so you know, Glenn uh and his his team because they are um based in Singapore, they've got off, you know, they've got a development team in Berlin and a couple other places, but >> because they're in Singapore, they have talked directly with that team and so good. Okay. Yeah. Keep feeding them stuff, >> right? >> Yeah. >> Yeah. So, I got to contact Glenn anyway because I need to uh work about work out some issues with regards to, you know, the VAC and the VDC that he brought up in yesterday's meeting, which is sticking in my crawl now that I've read the material. So, >> good. >> I'll cover. >> All right. >> All righty. We ready to get started? >> Let me see. Got it. I think I got attendance. Um, so just a quick notice on the antitrust policy notice and the the trust server IP's IPR policy on the top. Nothing changed. Um, so for today's we we've been going iterating between the two main topics of this working group. one is on specification of the uh trust enabled agents and this portion is about fiduciary duties and topics like that. So uh uh Steve uh has volunteered to lead uh this section and we do have one particular topic that I think we were discussing uh last week we can continue. So that's the the thread right there number 32 on discussion um in GitHub. Um so that's the proposal. Uh Steve, would that be good topic for today? >> Yeah. Yeah, it would. Sure. >> All right. Okay. So um yeah. Um so if everyone's good with that, then um let's see. I think we may have uh somebody new today. Actually, you guys, if this is the first time or uh you don't know everybody here, uh would you like to uh introduce yourself and say a few words? >> Hi. Hi, my name is >> Can I May I? Yeah. >> Yes, please go ahead. >> Yes, my name is Sally from the South Korea. So, this is first time to joining. I'm really interesting about the topic what you guys discuss about. It's nice to meeting meeting you. Currently I'm working as a lecture professor of hi university in Korea as well as I'm working as I iso TC 307 which are belong to blockchain areas. So no, thank you. But now how can I say it's really nice to meeting you guys? Thank you. >> Thank you and welcome. Um anyone else? >> Good. Also um I guess the traditionalist or what we do is this warming up kind of at the first 10 15 minutes and so uh the next topic usually is that any news anything to share and I have put down some uh items here. Um the one I think I want to advertise is the completion of uh the trust spanning protocol TSP's revision three. So the idea is this is fully complete um we have running code uh some early interoperability testing already started um and the documents fully published uh since yesterday. So that's the link and I would um definitely suggest uh if you haven't been you know um either um known about the protocol or haven't recently look at the spec again this will be good chance and a very nice uh oh yeah John go ahead >> just a quick question wedging that was a great uh great meeting yesterday um and and you know it was it was clear you and Sam were getting synced up that that I had to leave at the end and And there was still that one um issue you'd been discussing. Did you close that with Sam or is he still looking into that? >> You mean the 128 bits he's afraid is being deleted? Correct. That's an issue. >> Yes. So, um I would uh give So, basically, we agreed that he's going to go follow up with the um the literature uh again because it's been a while and uh hopefully he will come back and we would be on the same page. that would be the one likely um scenario. Uh if not, I think um uh if you know folks are really um interested in the technical details, we can you know we can discuss it too. But I would probably give Sam some time to follow up and then so that question uh to answer your question directly uh is still open and we're waiting for that to but the rest of the document it's um it's not an issue. It's mainly a warning of whether some feature is mandatory or optional. >> Right. No, I just I was just curious because I know the two of you were discussing it. Um, but uh, >> go ahead. >> Based on my studies, um, the so said something about no free lunch and that is true. Um, but this free lunch the cost of this lunch is very low. Uh, the worst case cost, I don't know. So we've been talking about like 128 bits of um security or or strength um that's maintained everywhere. Um this one it's like a less than a bit. There's a number that if you believe in the formula it comes down less than a bit. So >> yeah. Oh good. And I was just asking about the one thing that was still open but the >> the rest of it Yeah. you know, it really looked good and um massive thanks to you WJing for >> pushing it forward. I'm really really jazzed to get it to uh to 1.0 and and get that out to the world. >> Absolutely. Absolutely. I feel very very um good that this is in good shape. Um Glenn is able to independently verify the results and we are bitto bit compatible at least that of the test cases. So uh so looks like we finally have a you know kind of a solid version. Um you know there might still be small changes here and there but shouldn't be anything major. I I hope so. So I I I think this will be put us in the right path to get a 1.0 done. Um and um very likely we should be able to see some kind of a improbability testing and that will be mostly on sort of like application layer you know how long you say timers and you know do you constrain certain you know there's a there's a bunch of those things that is um not in the protocol level but in implementation level that those may be >> yeah possible. Yeah, >> exactly. Well, it's uh just for perspective for every everyone else on this call, you know, we're in the seventh year of trust over IP now and this is our keystone protocol for the whole stack. So, um for folks that, you know, had thought, oh, you know, you guys are really tilting at mountains to, you know, build a whole uh you know, stack for for trust uh at internet scale. Yeah, it takes a long time but when you get there it's really powerful. So anyway, thanks >> thanks for everything you're doing on that wedging. >> Sure. Sure. Yeah. So anyway the this is how the the the this the pro the stack or the protocol will spec look like and then um I think we were just going by you know if you really want to study the details you are welcome to go through the test vectors which give you give you all these like basically you know all the beauty is hidden there. So feel free. Um some of the uh documents uh the the reference documents are also very useful that give you you know the whole sense of it. Um I'll probably get some kind of a introductory um slides or something uh prepared um for in November this year right? Um anyhow so um >> yes >> the there is a uh reference implementation tool now my understanding is that um so um if uh yeah so you're welcome to uh test them uh this uh easy um you know demos and test you can do that will show you all the um bites everything um and uh the for applications I think there's say fundamentally very interesting. This is like a top sentence I think we should repeat it. Uh it gave you authenticity, confidentiality and metadata privacy. Those are the three f you know terms we we use to summarize what TSP does. But very importantly for AI I think authenticity is the one authenticity um in TSP's terminology not only say it's a um we we have like in the in traditional security you trying to prevent a third party a bad third party right here we're trying to make sure the primary party you know Alice and Bob they are not lying or trying to fool you. And that is the fundamental new way of looking at things because we that's what we need for if if a entity is an agent. >> Yeah, that's what that's what I mean. I call it a relationship. This is a relationship architecture. >> So this is a relationship between two parties. Yes, a third party may be hiding behind trying to you know do bad things but these two people are not fully trusting each other either and they need to be aware what the other part is doing what you trust the other party etc and so uh we build a lot of I think strength into tsp to handle that for you and that's what why um I think all those trust stacks and application should be built on TSP and I will have to say that I I don't believe DOM achieved that. So, um the Okay, so that's one. And then, uh on the AI news, looks like every day, every week, there's always something um in the news. And I quoted the two of them, the Astro of release or just about to. And the uh meta muse I thought is also very important because it's the first one which uh put the so-called personal in front of it. It's it's built as a agent and some kind of social media combined. So it's um very close to you know these personal thing um that uh and a lot of people in within trust IP have been talking about. So both I think are very interesting. Um and this um this essay I don't fully agree. So but if you follow it there's a lot of criticisms on the essay itself which will um you know if you read the the two combined >> talk about the metamuse thing first. >> Uh yes go ahead. >> I mean I I don't know you tell tell me about it. I don't really know about either of these things. Oh, so uh so Meta Muse is a product announcement coming out of um Meta Facebook. Um uh so that will be their first product uh as um the word I think the phrase is personal something about personal is okay so if you look at the product right it's designed to be easy to use rather than a chatbot it will be um a um um I don't know what they you officially use the term but I will see it as a personal agent and so it is tied to how social networks. So there are other people seeing it as a sort of a new you know generation of social network in the AI age. Um and if you see all the legal case too, right? Um Meta just settled on the lawsuits all that by filed by the states in US uh for some I don't know 10 billion or something like that. So they basically uh settled on those and now they are announcing literally right behind they announcing these new things and I don't know fully enough exactly how it works. haven't tried yet, but I think it's a very u you know it is really important we watch how this new thing is positioned. Yeah. Okay. I've been working in uh OpenAI's codeex app and I'm I'll be interested to see how it's different than that. Yeah, code is mostly for coding and and and so doing work. Um uh that's um so that that's um still you know I I think one of the best um the Astro the new release uh since um what about a months ago now this time it's actually it's not that much time ago um but we do see the best frontier models not being released now so Astro will do the same I essentially they're withholding features um for general public and both uh um OpenAI and um Anthropic are doing that and the new releases would be divided by some line something is not fully released and which makes it even harder because if you want to do testing anything you really don't know what are you testing These lines are very unclear and it's uh yeah it it's very problematic. It will make a lot of work a lot harder. So for for testing purposes for example I run into immediately issues of uh um you you don't know whether um you are testing the proper um property of a particular piece of agent or model. Um >> yeah no architecture it all comes down to architecture clear architecture and frankly open source which is why I think you know safety and capitalism are not compatible >> and that's um that's a a big issue. So both of them I think is very relevant to our work and uh um and uh the the assumptions we we can make or cannot make about these models um are just moving every week and that's before any kind of a large scale deployment you know all those things come in right like we see in in um Meta's is um if that is fully entwined with social media, it gets extremely difficult to do. We I think we all remember not long ago about um claw, the open claw and all those things. Um maybe this meta muse is basically a professional scaled up version of that. Um but you know um I I suggest we take a week to look at it, see what is actually is maybe try it if it's released now and then we can um dedicate um a session to talk about it next week. >> Yeah. I don't even know what kind of models they're offering the public over there yet. So Okay. >> Yeah. Yeah. Yeah. Models are crap. >> Oh yeah. Sorry, we we're entwined the two topics, but in OpenAI and both entropic and OPI basically say, well, I'm going to release one version somehow somehow tempered to the general public and there's another version either internally or being selected customers or something like that that you will have to go talk to them, you know. Um >> and uh I don't know the the the other news uh it was um the last week was the um the Federal Reserve um annual conference in Jackson Hall is about monetary policy and apparently during that conference there is a uh professor or a economist give a uh presentation about uh AI and the impact it's going to have on um the financial system and the um the analysis or the conclusion coming out of it um is that uh we don't have a way to defend it. So his proposal and I you know if there's a lot of news uh reporter on this too uh his proposal uh in a summary it's like um one don't disclose everything. So if you think you know disclosed information will be learned by AI then don't they say keep a secret among humans. That's um one proposal. The second one is that um all these AI companies must give the best AI models first to them. So they have to own the best model and others cannot have this these are not jokes that they're literally that's what he proposed in in in that forum but anyway you know there's a lot of um analysis why he reached this conclusion uh you know it might be wrong but I think reading these um apparently very capable experts on these issues how they see it um I I I find very useful. >> See, I have a I'm taking a fundamentally different approach. I've been working on a book about how personally sovereign fiduciary agents will use the trust network to replace the existing financial system and make something that's much much more stable than it. So, let it burn. That's generally my that's generally my idea toward most things is like I really want the stock market to crash so we can start to get you know hardware on the cheap and really frankly they could stop you know building these dangerous models and let us build personally sovereign ones that are safe. >> We have a revolutionaries here. >> Absolutely. Yeah. >> Yeah. Yeah. All right. Um any other news or comments people want to share? All right. Uh so the main topic uh Steve you want to give it like a um are we still updating the fiduciary uh document or we should jump into this topic? >> I actually that document I did make a whole new image for it. Um Sankeran said it was a lot better. So if we open up that old document, do you have that old document you can open up? >> I >> from last week. >> Uh from last week. >> If not, I can just share. I can just share. >> Let me click the last week has a link. No. Oh no. I don't have it. You want to share it? >> Yeah, I got it. I got it right here. Uh >> you got it. Okay. >> Let me just Hold on. I'm gonna share. >> I will let you share it. >> All right. Why my Where's my share buttons? I have too many things covering my Hold on. I've got Zoom windows popping up making me so I can't see anything. Share. See if this works. Can you guys see that? >> Yeah. >> Okay, good. So, this is the this is the better version of the uh >> the previous one >> of the previous one. Yeah. I I turned it into a a vector graphic. So now I can move things around, you know. So, >> okay, >> it's all groovy. Um, so what we wanted to talk about today in particular though is how to apply this uh to the idea of a a dual path um authorization or whatever I was calling it. So yeah, and uh so my question is is can we essentially use the uh the VTA system to not only authorize external things but also internal processes. And so I thought that would be an interesting approach to go with. In other words, you would have use your once again, you could converge your your your capability path with your authority path however you want, but I figured why not use the VTA for both things if you can, you know, it's it's hanging around in the tea, why not use it? >> Uh what kind of internal thing uh you you are thinking about? Do you have a good example? In other words, in other words doing like in other if you have if you have tokens that you're processing for capabilities which come you know which are issued directly by the user or by the component that's being utilized or by whatever process sort of the scope is is predefined with those capability tokens then then the uh VTA would handle that. In other words, it would have to do instead of just having a policy gate that checks the authority pathway, it have another secondary policy gate that could that checks the capability pathway. And only if those two converge, then do you proceed to uh actuation? >> I I think you're describing the gate itself. Is that what she was thinking? >> But I'm saying yes. So, but the but we agree the gate is happening inside the the ver the VTA number three, right? So, that's that's where you're going to be having like there'll be inputs that go into it, but then the actual process of of >> of verifying that the policy gate has been followed is has to be a a VTA process. Um, so I haven't sure what number three series is uh meant to represent here, but >> yeah, go ahead. >> Yeah, it's the it's the VTA. It's the cryptographic, you know, agent core. It's the thing that's talking in trust tasks through the trust spanning protocol. So So three is what's doing seven and you know through eight. >> Oh. Oh. So the middle is sort of a illustration of the stack. Oh yeah. One, two, three, four. Okay. >> Yeah. Correct. >> And then so uh the the agent on the left is the actor. >> Correct. >> Then there's another agent on the right represented his counterparty without the detail. Ah >> I see. Okay. Yeah. This definitely uh makes it clear. Okay. M. >> And when you say uh I think you use the word parallel. Um Oh, you mean parallel as in >> the >> So, so but what I'm saying is that you want to enforce the scope two different ways. That's all. >> Okay. So in the um TA's design the TA is a actor right it's a agent is a >> yeah exactly right >> yeah and the actor in order for the actor to do anything useful and that can be anything this I don't think there is a but the thing need to be identifiable so you have to kind of name it what exactly you're talking about um that can be constrained by some kind of policy and the policy is the message we send back and forth So some other authority or person can send a policy say ah you can use you know this credit card for that amount that's the policy but then you offer that as a message the message get sent and the agent receive that message and then agent can use that information for actually going doing purchase. Um the verification of that is already built in. So those are hard limit uh or that you can actually enforce um uh deterministically. So this won't be able to get out of it. The the so if it's a parallel means that both party or the two parties are all checking. Yeah. The always we always >> Yeah. Right. Right. Exactly. That that that's what I'm saying. So it's automatically parallel when you have two parties. But I'm saying we also should make it parallel when there's one party because for example the user is essentially an absent party and you want to double check that that party is is doing its job and sort of this sort of you basically have a second >> redundant pathway. >> You see what I'm saying? So that there is >> effectively another a counterparty in a single agent system >> right? If you have a not two party just only one party then basically the other is the unidentified system the it's not a >> right >> speaking system and that require a um >> um so uh so so that so that's always there it's we just don't name them but uh like for example when you go to use um NCP right uh The MCP has a remote pass which you talk to somebody but there's also a local pass. We just never highlight them. It's always there. And that of course can be part of the constraint as well. You can say you know um do this kind of thing only uh during this hour. Uh you can say do this kind of thing only uh if you know your CPU is not busy for example. Right? All those conditions are also equally um gated or enforced. It's just that there's no counterparty to to talk to. >> Right. >> Right. If you so if your original workflow gets corrupted there and your your original policies gates that that do things in a more granular way somehow gets hacked or something like that then you have this second pathway that protects you from you know really bad stuff happening essentially. >> Yeah. Yeah. So we assume those those tools are all built in and the the tool we use don't necessarily need to separate them but the examples we use always have a count that's easier to talk about. Uh >> yeah right. So maybe we should just put some examples in there of how this system can be used internally uh to to create uh security as well within the agent. >> Yeah. Um I think that's a good example to add to um so now I understand the parallel u now in this case though you will have to trust the um the sorry the the underlying system the whatever system that we didn't name. >> Yeah. >> Right. But you don't have you should have to trust it more than the than the other system. They both have to agree. None neither one is above the other. >> Yeah. Yeah. Yeah, sorry Nikki was uh having hands up for a while. >> I think the moment's probably passed, but uh you you finished your discussion and then I I've got a question for Steve. Okay. >> Okay. Sure. Sure. Yeah. Um so uh Steve my thinking is that uh we could add some language describing like what if a subsystem just generally speaking right um like for example I'm checking timer the timer is probably provided by the operating system let's say right and do I trust the operating system well in some cases we don't but suppose you trust the operating system it's not going to cheat, you know, and tell you wrong time, for example. Yeah. Then you could. And so in that case, it's a in the in the design we have is essentially say, well, in that case, you should have built some kind of um using the uh a gateway of some kind like in MCP. If the other side has no um notion of MCP or there's no notion of TSP, what do you do? You build a gateway, a bridge between the two and the bridge takes responsibility. Essentially, you are representing those that we cannot account for. Um, so similarly you would do that we could add a uh section which describes what's the best way of doing this. So that way we can bring in these unidentified systems without you know sort of like just break down the entire system. So you could have say here a limited exposure and and this is where it ends. This is the gateway and beyond that it's you know it's it's barbarians out there. >> Yeah. Yeah. We could probably do a couple different >> uh you know ways examples that are kind of tied together showing different varieties of doing it. Yeah. >> Yeah. Yeah. So those are definitely good scenarios to discuss. I think that's that's a good example. Um >> Nikki question. >> Yeah, I think you started by saying there are these two kind of qualifications that you have. One being to do with capabilities and the other being to do with the governance side of things, the permissioning side of things. Yeah. Right. Yeah. >> And it just reminded me of the reference model for trust tasks which you and I have discussed um Steve where we had these two precondition violation kind of records. One was structural your capabilities and one was governance related. And at the beginning before you even kind of engage in any trust task, you start with presence and clearing down these two records to see if the transaction or interaction can go ahead. So I I agree with your thinking. There are these two checkpoints before you start anything. it is is my understanding of that. >> Uh yeah, I think in my fiduciary preferences paper I think I have the exact >> sort of the presence check. I don't think I call it that but I do have the sort of can we interact at all step that goes on that will yeah you know for example just checks the scope of both agents which is what we're talking about when we talk about capability. >> Exactly. And there's one that's on the kind of nuts and bolts of what goes on, >> you know, can they do this thing? Have they got a web browser access for example, you know, and and there's another one of kind of should they do this thing according to the governance framework, the policy that's enacted in that context or in place in force in that context. So, it's kind of difficult. It's there's a kind of circularity in it, it seems to me, because before you can do either of those things, you've got to kind of identify the entity to so that you know the governance framework that applies. I'd thought, you know, kind of still thinking it through, but >> well, that that's things you could put in agent cards though. You know, the agent cards >> are when you're swapping to find out if you can do a deal. You swap agent cards first and that's going to tell each >> other party sufficient to know if you can go to the next step. >> Yeah. And am I good for this? Yeah. >> Yeah. So, think of this. I I would much like to like dive deeper on the examples here. Think of what the uh uh this working group is doing is kind of a produce a language that the governance stack then can use this language to express policies. >> Yeah. >> And that's the way you can think about it. Yeah. >> It in the this I I kind of did a like go down a rabbit hole piece of work. um on a relational reference model and uh the I identified very clear intersection points with the governance stack using things like ODRL and and so forth so that we get this coherence between at the different layers between what's going on in governance and what's going on in on the tech side and obviously you know more machine readability and machine enforcability and we've discussed in this group a number of times the policy goes with the data. Yeah, it's it's all mixed up together. I still think there's more work in the community to be done on those interconnection points but um and how they work in practice and standards for how to implement. Yeah. Um I think it's a big gap particularly on the operations side, governance operations um side of things. >> Right. Sorry. Okay. Well, I was going to say that yes, totally agree and maybe as a good exercise like we are doing here which is a sort of how the VTA type of u you know application or trust task would be built rely on um the uh trust enabled agent. And the second thread of topic we can really go into is now we have a much richer I think the language uh tea would provide is dramatically uh richer and better than uh the old you know IDL or any kind of a policy language those are very constrained because uh it was designed long long time ago for a much simpler environment. uh so the new language what it look like and then what kind of thing we can express how would you express it I think that would be a fascinating thread for for our meetings that we can dive into it um so um I I think we could take examples of policy languages we can take examples of u you know how do you describe fiduciary but also other type of policies um examples of those policies I think would be really useful. So if we have realistic looking um policies in natural language and then we can look at how that will be you know be mapping to uh tea I think that will be extremely valuable because that's where we link the requirement and a tool see if they match right So sorry on that. >> I think it could be very interesting to have a well ststructured set of policies as a kind of sand pit test environment >> because there are different policy layers and there's quite a lot of work in the research on like policy flow down to outcomes. you you set an SDG that goes through a national government, a local government, uh an organization, you know, and so there so there's there's layers in policy in governance. >> I mean, but that and that's still from a more centralized to a >> Yeah. All policies are >> there's other types of layers. Yeah. Even within a personal policy, you're going to have all sorts of layers and various levels of granularity. >> Yeah. Absolutely. And you know, they're just the rules of the game at the end of the day. And uh >> but what what I'm just you've made me think of is is there a way of kind of creating because there are lots of these policies that are publicly available terms of use and you know uh regulation and legislation and so forth. But is there a way of of creating a kind of test samp play domain with a like non-consequential policies or fake policies that we could sort of test this stuff against? Um >> absolutely that's that's my proposal too because there's two sets of them here. Um the middle ground I think is the most interesting one. So there's a one set of quote unquote policies that coming out of from like data centers and those policies are well understood and it's how you know fairly commonly implemented already uh and those are one set of policy and that's there language their own tools all that and that is fully compatible with tea so we can those we can I can automate them and they will be tested you know fully automatically the other Other set of example we we have readily available those are like laws and regulations but those are written in a way for human to read and usually it's not obvious how you are going to enforce this um and uh uh so uh we could take example of that and then say well what portion of it can be mapped into tea they all human related things we cannot you won't happen. But the rest of it, yes, we could. >> And the whole idea of fiduciary duties is generative policy. So the idea is that a fiduciary duty with a lot of legal precedent is is there to be able to provide agents a way to decide in situations that are ambiguous. And so that is, I think, the most important policy to implement. That's the Yeah, that's the between these two extend the middle is where all the things I think become very interesting. >> Right. >> Yeah. And so there are some policies that couldn't be expressed at all in the past. Now all of a sudden we can. Right. That's what I'm saying. The language is much more powerful, richer than it used to be. >> Yeah. But the in like the human written laws usually they have very vague terms sometimes it's meant for human to interpret whatever way they want. >> Yeah. So I've been >> those are hard. >> I I've been doing work with um human laws and regulation around electricity in the UK. >> Yeah. And I've been able to extract from the human readable documents. >> Mhm. >> Into things like graph databases and others. >> Okay. um and using other tools the kind of human readable law and by treating it as software code I'm able to implement all sorts of efficiencies and tools to keep things on track and and ultimately make that policy function more effectively. simply by applying the tools that we use all the time in software. So, I think there's a a really, you know, I'm mildly obsessed by this. Um, there's a lot that can be done um with respect to governance and creating these in decentralized ecosystems, these flows of policy along with data, along with code. Um, so I I love this group to, you know, spend some time working on that side of things because that's where the rubber hits the road that we found that when we wrote the harms paper and and so often in discussions about specifications, we say, "Oh, well, that that goes in governance." But I think we what we're learning is with AI particularly, we need to be bolder and say no, it goes in the spec. It's not it's not down to local implementation because it's a kind of uh structural fault line um that will embed harms if we don't address it as a guard rail as opposed to a a kind of you know assurance test or configuration choice. Um, >> so Nikki, would you would you be uh willing to help us identify uh such a you know use case or example um that uh we could test um or or exercise or walk through how that integration could work? >> Yes. What I'd love Steve if you're up for some time together to work on it because I I will go I've got a lot of background work in my private files on this kind of decentralized governance operations I call it. You know >> design is one thing but actually it's in the heat of battle that it matters. um in operations and there's kind of a gap in standards around that kind of thing. So um but I I I'd like someone to work through with it together before coming back to the group because otherwise I I'll go too big. If you see someone control >> so let's just think about use cases that we've already considered for example and just think about >> the policies the governance frameworks the terms and conditions that apply in that situation you know people often say we need to write a governance framework and >> you know going back 20 years I can point at projects where I say, "You've already got one." You know, what's that sitting in your terms and conditions or your supplier agreement or your code of practice or or whatever you might call it. Yeah, >> I I would very much want to see how uh those uh terms and conditions can be translated or I don't know what's the right word, but you know. Yeah. Um um >> yeah can help us and I I will definitely do I can >> yeah yeah I can I I can do that. I mean I we definitely want to avoid uh duplicate work. So >> so yeah I think bringing in uh more deterministic policy details is good. I've you know I've created the space for it and now it's kind of time to fill that in. So >> yeah, in in the end that will tied all the theory and software and protocols together because that's what eventually we're going to need. But I mean I mean ultimately I do think the agents are going to be designing all of their own deterministic constraints as well. So the deterministic constraints will be then generated by agents and then they'll agree what they should be and then they'll rewrite themselves. so as to enforce it. If that makes sense. That's what I think the eventual goal of what we're trying to do is is that you know you can always allow an agent to autonomously constrain itself. You're never going to have big problems with uh you know them taking over the world if the only thing they're allowed to do autonomous autonomously is attenuate their own powers. So, um, but yeah, I think that's what we're ultimately looking at is sort of, you know, humans giving agents, uh, wide scope in them over time in their particular roles, narrowing that scope and specializing very well and making sure once they've specialized that they don't operate outside of their area of specialization, if that makes sense. But that will be a um orthogonal task. The two are not in contradiction that we need to figure out how >> yeah agreed >> this policy get actually translated. >> I'm just saying why they're so important >> at the same time >> same time where those regulation come from or how it's divided how is you know those are orthogonal problems that we but they're also very interesting. Yeah. >> Yeah. And no I I was just talking about why it is important. Yeah. Exactly. >> Yeah. Exactly. Yeah. Okay. I think we identified a um very useful um threat and we should uh so I look forward to that Nikki and uh just you know give us um some lead and then we'll follow you. We'll get this going. >> Thank you. >> Brilliant. I think Sally has her hand up. >> Yeah. Yeah. Yeah. Hi Sally. >> Well, this is first time I'm starting to learning what you guys talking about. But I have a wondering about uh agent the background. So you guys checking whether agent between agent and sending some data to other agents whether the agent is right or not. Is that from beginning time? Is that from that's that that idea? Is that right? >> Uh I think you were talking about like the basic assumptions. We assume the the agent was built like the TA document has a little diagram in the top of it which says how you you know um conceptually how the agents built and usually you have a sometime people call harness or guardrail. there are some software environment where the the model uh or the agent runs and so that is the the assumption here and then they uh interact with the outside world or with other agents through some kind of interface so whether it's you know NCP protocol or other things but there's a interface related to that um and and so that that's the uh definition of an agent so agent usually has a uh verifiable identifier. There's ID with it. Uh it implements the TSP um the stack itself and um and then it interacts with others and the environment. Uh >> in that case uh number 11 looks like a reputation system which is embedded in AI agent. So if it's right then 11 should to in my idea my personal idea 11 should to move to governance sections. So my idea is governance is trying to give a regulation. It it's one way the other way is evaluate whether other partner uh agent is a correct one right one or not. That sort of aspect can be concerned about as a governance because that I trying to connect other agents but I that agent is a data whatever they have is right when to connect with me first time they have to be have authentification or relationship I has you know we have to be connect each other somehow and this is the right one or not I think it can be judged by reputation system. And the third thing is uh you know regulations policies how regulate how often we are connected or what kind of things we should be connected some condition we needed to be. So that's my idea is 11 to be in the cases to governance sections. You guys mentioned about only governance sections as a policy how to run the agent in that if it's right then that right expression about governance sections but the other things governance can be controlled or other counterpart of agent so should be included assurance verifications and audit as well if it's right Okay. So this is the beginning time what I learned uh when you're talking about I'm just learning. So maybe something different ideas. I might just see different aspect. >> I I mean I think you get it for the most part. >> Seem to be following along pretty good. >> Yeah. Um the So the I think 11 Yeah, it's good topic. 11 is uh um there are some portion of it is sort of a part of the agent itself and then the other portion like in the uh I think in the TA spec we separate private states and um accountability records like logs uh in in two different places because the logs are clearly in governance structure you can do auditing and other things and it's meant to be um kept somewhere the agent cannot temporarily right and so logs are sort of in that nature. >> Yeah, exactly. The logs go in a verifiable relationship record if you've agreed to she if you've agreed to share the logs to prove your performance. If you haven't then they don't go in there. It's whatever you agree to have go in there as goes in there and it's built up. The verifiable relationship record gets built up after you exchange your agent cards. This actually should be nine should be agent cards. And then you once you've exchanged your agent cards, then you form a relationship of through a verifiable relationship credential. And then that verifiable relationship credential is sort of the the cryptographic base that you can then build the verifiable relationship record from and put in whatever else you want. >> Yeah. Yeah. Um so anyhow this this kind of data um basically is separate in in two ways. Some are quote unquote private others are um a a record that you can go back and audit >> and that private stuff that you're talking about that lives in number four. >> Oh I see. Okay good. So the 11 is meant to be public or while our shared meant to be shared in some way, >> right? >> Yeah. Yeah. >> I mean though I can commit I can commit a you know a secret document to 11 that the other party can't understand but they'll see that it's there. Of course, >> I can encrypt something and put it in 11 and they have to say, "Okay, I acknowledge that you delivered this into the into the verifit." So there's a other party will be a be able to come to read 11, >> right? >> Yeah. Okay. Um I think we are making good progress. So thank you for updating this diagram. I think it does look a lot better than the previous version. >> Yeah. >> Yeah. Yeah. Thank you. Um, and I hope uh Nikki will help us with some uh use case over there as well on the type of rules. Um, we look forward to those uh meetings. >> Yeah. I mean, basically, we're just going to detail out the policy gate as much as we can and >> Yeah. Well, pick examples, pick one piece of real policy and then we >> Yeah. Yeah. No, no, yeah. Yeah. Yeah. Exactly. Examples. >> Yeah. Yeah. Very good. >> All right. >> All right. Thank you very much. Thank you, Sally. Hope to see you more often. And thank you, Lynn. >> Thank you. >> All right. See you next week. We'll go back to TEA next week. Thank you. >> And yeah, I I think I might have to go to the other thing, but I'll read the the latest version. So, >> so absolutely. Bye. >> Okay. Later. >> Bye-bye. >> Have a great day. Yeah. >> Thank you. Bye-bye. There's no way I can't even get out of this share. Never mind do anything else. I got to get out. Got to get away. There we go. Finally.