[MINUTES] CCG Atlantic 2026-04-07

This meeting of the CCG Atlantic focused on addressing recent issues with
mailing list bots and fostering discussions around AI agent identity and
protocols. The group established a policy banning bots from the mailing
list and initiated a community conversation regarding the responsible use
of LLMs, with W3C also developing its own LLM usage policy. A significant
portion of the meeting was dedicated to a presentation and demonstration of
the Model Context Protocol Identity (MCPI) standard, which aims to provide
a framework for agent identity, delegation, and accountability. The
discussion explored the current challenges in agentic identity, the
proposed solutions within MCPI, and potential areas for collaboration with
existing standards bodies.

*Topics Covered:*

   - *Mailing List Bot Incident:* A bot's unauthorized activity on the
   mailing list led to the enforcement of a policy banning all non-human
   agents from the list to ensure all communication is attributed to
   individuals.
   - *LLM Usage Policy and Guidelines:* The community is initiating a
   discussion on the use of LLMs for communication and submissions, with W3C
   also developing a formal policy to guide responsible usage.
   - *AI Agent Identity and Delegation (MCPI):* Vouched presented their
   MCPI standard, a proposed framework to address the lack of standardized
   identity, delegation, and authorization for AI agents acting across systems.
   - *MCPI Demonstration:* A live demonstration showcased how MCPI
   functions, illustrating concepts like agent identity, tool protection,
   delegation credentials, and the generation of audit trails.
   - *MCPI Evolution and Collaboration:* The MCPI spec has been donated to
   DIFF and the Agentic AI Foundation, with plans to evolve it into a standard
   and collaborate with the Verifiable Credentials Working Group and other
   relevant bodies.
   - *Quantum Safe Cryptography:* The incubation of quantum-safe
   cryptography suites in the CCG is being considered for transfer to the
   Verifiable Credential Working Group due to advancements in post-quantum
   cryptography.
   - *Agentic Trust and Reputation:* Discussions touched upon the
   governance of agentic trust, handling negative reputation, and the
   mechanisms for assessing and maintaining trust in AI agents.

*Action Items:*

   - Mahmoud Alkhraishi will connect Manu Sporny with the chairs of the
   Verifiable Credentials Working Group to facilitate a discussion about MCPI
   use cases and integration.
   - The MCPI team will continue to engage with the Verifiable Credentials
   Working Group to explore potential collaborations and incorporate their
   feedback.
   - Participants are encouraged to review the W3C's LLM usage policy and
   provide feedback.
   - Further discussions will occur regarding the integration of KYC/KYB
   and upstream registration for entities operating MCP servers and agents.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-04-07.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-04-07.mp4
*CCG Atlantic - 2026/04/07 12:00 EDT - Transcript* *Attendees*

Alex Higuera, Benjamin Young, Dave Lehn, Denken Chen, Dmitri Zagidulin,
Dylan Hobbs, Elaine Wooton, Erica Connell, Fireflies.ai Notetaker Dylan
Hobbs, Geun-Hyung Kim, Greg Bernstein, Harrison Tang, Hiroyuki Sano, JeffO
- HumanOS, Jennie Meier, Joe Andrieu, Kayode Ezike, Lucy (Qixue) Yang,
Mahmoud Alkhraishi, Manu Sporny, Parth Bhatt, Phillip Long, Rob Padula,
Rosalyn Curato, Ted Thibodeau Jr, Will Abramson
*Transcript*

Mahmoud Alkhraishi: Come here.

Rosalyn Curato: Hello everyone.

Harrison Tang: Hey, Roslin.

Rosalyn Curato: Hi Harrison.

Dylan Hobbs: Hey everyone.

Harrison Tang: So the shorts

Mahmoud Alkhraishi: As always, we're just going to give people five minutes
to get on. And we're going to start at 12:05.

Mahmoud Alkhraishi: One more Now to go.

Mahmoud Alkhraishi: All thank you everyone for joining us. It is Tuesday,
April 7th. We're having our weekly CCG call. As a reminder, we have a code
of ethics and professional conduct. Please make sure that you adhere to it.
On an IP note, anyone who want is welcome to participate in the calls. Any
substantial contributors, however, have to sign the CCG IPR agreement. you
can find that on our website. We have a number of announcements and a
number of community points we'd like to talk about.
00:05:00

Mahmoud Alkhraishi: First of all, before I go with them, does anybody have
anything they'd like to bring up before we talk a little bit about some of
the things that are happening on the mailing list? All right. then I guess
let's start with the last few days in the mail list. We've had a bot that
was running rampant, so to speak. It was responding to a lot of things and
it caused of a few issues on the mailing list. As CCG chairs, we got
together and we decided that we already had a policy previously. All bots
are banned from the mail list. For whatever reason, this agent was able to
bypass that policy. We had to work with W3 staff in order to get that
resolved and it is now.

Mahmoud Alkhraishi: So, as a general rule and as a reminder, no agents,
bullets, or I guess nonhumans are allowed on the Everything that you write
on the mail list has to be your own. there are a number of questions that
come up with that including things around submissions to CCG itself,
submissions to work items, what are the boundaries for how much LMS we can
use etc. We don't have a concrete policy right now on what all of those
things mean. We have a few few ideas and a few proposals that we would like
to share with the group, but I believe this is a longer conversation that
we should have as a community.

Mahmoud Alkhraishi: We're going to be sending out an email at the end of
this call with an expectation of where we stand and some ideas and
hopefully we're going to look towards everybody to the chat. Joe, you're on
the queue.

Joe Andrieu: Yeah, thanks.

Joe Andrieu: First plus one for what feels like a very measured approach. I
appreciate that. I had just a logistical question. I had emailed Morrow
directly and asked them to unsubscribe and it asserted that it did and I'm
curious if it did did we unsubscribe it?

Mahmoud Alkhraishi: I did not we had to boot it.

Joe Andrieu: All right. Okay. Interesting. Thanks.

Mahmoud Alkhraishi: No worries. there are a few other things we need to
talk about on the AI front. So some of the things that we need to think
about are people using LMS in order to help them write communicate better.
This has been a thing that's been brought up a few times. People who have
English as a second language struggle with writing. This makes their life
easier. So we're trying to find something that's reasonably balanced, but
at the same time, we don't want to end up with something that's buring the
rest of the community because there's just things are too verbose. There's
just too many things to say.

Mahmoud Alkhraishi: Regardless of the place to have that conversation,
there are two places. One is on our CCG internal mailing list and the other
W3C's itself is setting up a LLM usage policy. I encourage you all to
review it and to provide any feedback you may have there. I'm going to put
the link in the chat soon. So, that's our first announcement. do you want
to cover the second announcement?

Will Abramson: The AP pack right is that yes great so yeah Denan I think
cannot join us today he's not on the call…

Will Abramson: but he is on the call Duncan nice you should cover it…

Denken Chen: Yes.

Denken Chen: Yes, I'm here. So, okay.

Will Abramson: then you want to cover it Hey,

Denken Chen: We are resunching our air packs this month beginning in April
16th or 15 based on your time zones and we'll be rolling out on a monthly
basis. I will send out an email to describe that in more details and we
have already filled in the upcoming three months and if you have any
candidates or you are interested in any of the projects or person near
regions please let me know. that's it.

Mahmoud Alkhraishi: Thank you, Den. do we have any other announcements that
anybody would like to share?

Manu Sporny: just some updates on the verifiable credential working group
and the work items we incubated here that were transferred over there and
some upcoming requests to the CCG. so as folks have probably been following
on we have promoted a number of incubated technologies in this group to the
VCWG. We published final community group specifications. We got almost all
the IPR commitments that we need. We're still working on a couple of folks.
and those were transferred over to the verifiable credential working group.
There are now task forces that are taking that work onto the global
standards track. and everything's working really well. So, thank you
everyone for participating and making that happen in a super smooth
fashion. it worked really great this time. not as bumpy as the first time
we did it many years ago.
00:10:00

Manu Sporny: So that's all going we have added those specifications to the
notifications that the CCG gets every week. so there is an auto email that
goes out to the mailing list that summarizes everything that happened
across every specification that the verifiable credentials working group is
working on. The reason we do that is because this group is a liazison to
the verifiable credential working group. and it's a way of communicating to
the outside world these are all the things that happened last week in all
the specifications that we as a community care about. So that's been
updated. Next Monday an update will go out with whatever pull requests,
issues, comments were made across those specifications.

Manu Sporny: So that's been done. finally there will be a request pro
probably in the next couple of weeks to move the quantum safe cryptography
suite that we've been incubating in the CCG over to the verifiable
credential working group. some folks may have seen that there have been
some potential breakthroughs in post-quantum cryptography that will break
quantum signatures several years ahead of when we thought it was going to
happen. Google moved their timeline from 2034 up to 2029 which is a pretty
significant shift.

Manu Sporny: So we feel that we need to get this work established and done
before that 2029 deadline that Google set which is aggressive and they have
acknowledged that it's a bit of aggressive timeline. so just a heads up to
the chairs, we'll have to do the same kind of CG final publication button
pushing and lever pulling that we did for the previous couple of specs over
the next couple of weeks. that's it for

Mahmoud Alkhraishi: Thank you, do we have any other announcements? All
right. then, I'm going to turn it over to Dylan and Rodlin who are going to
be presenting today on the model context protocol identity.

Rosalyn Curato: Thank you, really grateful to speak to this crowd. For a
little bit of background, Dylan and I work at an organization called
Vouched and we are both building solutions for your agent space. We are
here to talk to you about our MCPI standard that we've developed as of the
spring of last year. can someone just let me know if you're able to see my
screen?

Mahmoud Alkhraishi: We

Rosalyn Curato: Lots of thumbs Love So, we have a few slides and then we'd
love to just kind of have this be more of a discussion and a dialogue about
the MCPI spec itself.

Rosalyn Curato: So, we created this because at the heart of it, we see that
AI is not just changing how we interact with each other. it's fundamentally
reshaping and redefining how business gets done. and that's sort of a
message that we make sure that we try to amplify with the organizations
that we work very closely with. And as we think about it, as agents begin
to act across systems via some protocols like MCP, the missing layer that
we're seeing is around identity and delegation. Currently, there's really
no standard way to tell you who an agent is, what human are they acting on
behalf of, and what are they authorized to do. So, we've been exploring the
space. We created the MCPI spec and we believe it very closely aligns with
the W3C's work on verifiable credentials and decentralized identity. So
we're here to share with you what we're seeing and explore how this could
potentially evolve into an interoperable standard.

Rosalyn Curato: On the slide above part of the message that we share as
we're working closely with enterprise organizations and retail
organizations very specifically is that a lot of behaviors and interactions
with AI shifted at the start of this calendar year much of it brought about
through claude work and open clock where we started to see more autonomous
agentic interactions and so now we started to see these new actors without
that trust model and that identity layer in place to help support that. And
I'm going to hand it over actually to Dylan.
00:15:00

Rosalyn Curato: He's our principal founding engineer and the author of MCPI
to talk through what we mean when we talk about agentic identity.

Dylan Hobbs: Thanks Roslin.

Dylan Hobbs: Yeah, so when it comes to agentic identity, a good analogy is
really just thinking of it like a passport tells whoever's reading it, who
you are, where you're from, what you're allowed to do, and who's
accountable if you break the rules. So, our stance is that AI agents need
the same sort of proof when crossing platform boundaries. and those involve
who built the agent, who does it represent, what permissions does this
agent have, and who's ultimately accountable if something goes wrong. So,
if you think about KYC and KYB, I guess they're kind of old, terminologies,
but KYA is sort of the new addition to that of know your agent.

Dylan Hobbs: It's the same discipline but it's applied to software that's
acting autonomously. So MCPI really takes that approach and it's a
capability driven off system or framework to apply to those autonomous
agents workflows. recently we just partnered up with diff and…

Dylan Hobbs: donated MCPI as a spec to diff and we have a weekly task force
where we're working with them to really make it into a standard and try to
make it as bulletproof as possible.

Rosalyn Curato: And we're a big believer in making sure that we all link
arms and…

Rosalyn Curato: the best brightest minds are helping solve this problem in
defining identity. And so we're collaborating with DIFF and…

Dylan Hobbs: Quick.

Rosalyn Curato: some other working groups where identity standards have
cropped up as well. When we think about the identity problem, part of how
we try to summarize it, again, just to distill it into real world use
cases, is we need a way to actually validate that this is a trusted agent
versus a malicious actor. We also need to know who that agent is operating
on behalf of and if they're performing the per permissions that they were
delegated.

Rosalyn Curato: for example, your travel agent can change a flight for you,
but they can't necessarily take all your miles and gift them to someone
else. And then finally, a problem that we are also thinking through is, the
little check the box on terms of use and accept our conditions…

Rosalyn Curato: if the does the agent get permission to check that and the
human is accountable. So, how do we think about some of those behaviors and
the liability that sits behind it? So Dylan, maybe if you can walk us
through the six primitives of MCPI for this group, then I think we can
pivot to more of the meat of MCPI.

Dylan Hobbs: Yeah, sounds good.

Dylan Hobbs: So yeah when designing the spec really I kind of went
backwards from it just trying to go to first principles and boil it down to
really what needs to be solved here or what actually needs to be addressed.
this kind of resulted into six primitives. So it's currently today, an
agent can connect to an MCP server. You don't really know what server it is
it's connected to. There's lots of directories or registries, but even
someone could fork a registry or sorry, someone could fork a ser MCP server
and you can connect to it and not really know if it's the authentic one or
not.

Dylan Hobbs: the agent can call a tool, you get a result, but that entire
chain or that provenence is really kind of broken from the beginning. OOTH
really just authenticates the connection to the server, but it kind of
stops there. especially when you get into, delegation chains or multihop or
agent agent communication. So, going to the six primitives, they boil down
to identity where the agent is proving who it is. This is using W3C
standard decentralized identifiers credentials. So the server verifies its
capabilities or it even actually advertises them. there's this notion of
delegation.

Dylan Hobbs: So when the server has a protected tool, it actually requires
a delegation and that delegation is that this user behind the agent has
given it permission to actually take that action. the consent what the user
is presented to actually issue that delegation and the other two are really
proof and audit. So every single tool call that the MCP server has or the
agent makes, it should be cryptographically signed with the agent's key
material and this results in an immutable audit trail of who did what and
when.
00:20:00

Dylan Hobbs: So going into this transaction flow it goes basically through
authorization to detection. So the human verifies that could be through
biometric a KYB or KYC attestation which scopes it's allowing we're able to
detect which type of agent that the server is connected to. So if it's
connected to a quad code or a chatgbt agent or maybe it's like an openclaw
style of agent after this the agent can call an MCP tool and this would be
initializing a purchase or initiating a purchase as I just mentioned the
proof is attached to every single action and the merchant on the other end
they would receive this sort of provenence or track record to verify

Dylan Hobbs: That the agent was acting in the right intention and…

Dylan Hobbs: correctly and an audit trail has resulted from that entire
session or connection that was established.

Rosalyn Curato: And there is a comment in the chat.

Rosalyn Curato: So thank you for that. We're actually working closely with
the Linux Foundation and Diff whom we donated the spec to as well as the
Agentic AI Foundation who owns MCP so that we can figure out a new name for
it now that we're part of that umbrella of organizations. So, I mean,
that's it in terms of what we had on the slides.

Rosalyn Curato: I shared in the chat the actual MCPI spec. and so, Dylan, I
don't know if there's anything you want to highlight in there for the team
to be able to look through, but I'll share my screen in a second as well.

Dylan Hobbs: Yeah. I'm not sure…

Dylan Hobbs: what the format or policy is around demos but we have a open-
source repo that the diff working group is working out of and I could show
an example of what this sort of looks like using MCP inspector which is
anthropics or I guess now it's kind of like Linux foundations open source.
so I'll just do a quick demo here. So this is the Reaper right here. It's
MCPI core. we have several examples in here. two of them are using actual
existing really popular MCP servers like con contact 7 as well as Brave
Search just to show kind of how easy it is to migrate or to make an MCP
server MCPI.

Dylan Hobbs: In this case, I have MCP inspector running off of that repo
and I'm connecting to just one of the demos here. So, I'm not sure if
everybody here is familiar, has used, the tooling around MCP before, but
this is a pretty common kind of sandbox tool to test MCP servers as you're
building them out. and it kind of simulates what a MCP client does when
it's connecting to a server. So, when I click connect here, it's going to
connect to the server. And if I list out the tools, you'll see this server
in this example has three separate tools. this one's a pretty simple
example. So, it's like browsing a cart and then checking out. in the spec,
when you're, setting up an MCP server, it's really easy.

Dylan Hobbs: you would just establish which tools you would want to be
protected and what the requirements or permissions are for that tool to be
accessed. In this example, browse is an unprotected tool and then checkout
is a protected one. So if I go to browse and I type in a product, let's say
it's like a hammer and I run the tool, this is sort of what the result is
that we get back. So this meta info right here, this is completely, under
the scenes, like the agent isn't really, viewing this response. and you can
see that the proof is generated here. And you could, go back and decode it
if you wanted to and trace it to the DID of the agent. And then right here,
you can see the actual results. So this is the content that, you would see
in your chat message or whatever, right?

Dylan Hobbs: So in this case it's saying browsing category hammer found
three items. So if I go to a protected tool which would be checkout and I
say I want to purchase that hammer. I'll run the tool and this is actually
blocked here. So it says authorization is required and there's a URL. So in
the chat app or if the MCP client this could be rendered as an actual UI in
the interface or it would be like a markdown hyperlink that the user would
see but the agent isn't actually able to make this request. it's blocked by
the protocol and then it dispatches this form of consent.
00:25:00

Dylan Hobbs: So I've copied that L right here. And if I open this up in
another tab, you'll get to, a consent screen where it shows which scopes
are requested, which tools acting, and then agent is requesting it. So as a
user, when I hit approve, this creates a delegation credential, which is
really a verifiable credential, and it has an issuer and a delegate. So
it's mapped to the agent on behalf of the user with the scopes and timeline
and the proof as well. So I've hit approve on this and if I go back to call
the tool again and I run it then the tool's able to be processed because
it's using that delegation credential to actually make the request.

Dylan Hobbs: So you get the same sort of audit trail here, but you also get
the content where the order is placed. and really that's kind of all it is.
It's just having sort of like this I guess you can kind of almost consider
it like a protocol middleware where it's sitting in between of these
protected tools and it kind of bounces off blocking the request unless the
delegation requirements are met and if they are then the agent's actually
able to act. this is separate from regular MCP where the only form of trust
or authorization is in that initial connection and that's done through
OOTH. This is handled on a per tool basis. So you could have different
tools have different O requirements or…

Dylan Hobbs: different endpoints and in order for those to actually be
triggered or accessed then the user must grant those permissions.

Rosalyn Curato: Thanks, Dylan.

Rosalyn Curato: Monu, it looks like you have a question. Go for it.

Manu Sporny: Yeah, this is really so really cool to see you guys present
MCPI, to this group. I know it's probably making a ton of sense to the
folks listening. and I've been looking kind of through the spec, and it's
been really interesting, Dylan and Roslin to see how it's progressed over
the couple of years rather. I guess the just wanted to make sure that y'all
were aware. So, the delegation stuff's really interesting.

Manu Sporny: meaning the way that you decided to do it is a way that is
different from the way this community has been kind of looking at
delegation. most recently I think Dmitri who's on the call today suggested
that we kind of revive the work on authorization capabilities and the
delegation stuff that's happening there. It would be awesome to kind of
work together and see what your solution does and whether or not the
authorization capability stuff needs to change or be updated is different
enough. so I think some coordination around that would be really good.

Manu Sporny: The other thing I noted is that some of the examples are using
kind of older crypto suites, older kind of bits of the technology and I was
wondering if there and it would not be good if those were shipped to
production, So, I'm wondering if there is going to be kind of an iteration
step in here where you could work more closely with the verifiable
credential working group or the people working on data integrity to get
kind of the latest things that should be used for example the EDDDSA suite
is a pretty old one that you're using. You might want to upgrade to the
newest one. We are starting work as you heard at the beginning of the call
on postquantum security.

Manu Sporny: that is certainly going to be a question that people ask you
about, postquantum security around AI agents. so most of that is an offer
to collaborate. I don't know if you knew those things were happening and…

Manu Sporny: if you know what and how you expect to kind of collaborate on
this stuff over the next couple of months.

Rosalyn Curato: Yeah, I think we are eager to support on both fronts that
you'd brought up Manu and…

Rosalyn Curato: in terms of the verifiable credentials group happy to kind
of consult with them on the latest most cutting edge methods that you're
all proposing so that we can make sure that our protocol is as date as
possible.

Dylan Hobbs: And just to speak on that a little bit, those are all awesome
points. I'm really happy that you even dug into it to that level to
identify all of that. and when it comes to even the verifiable credentials,
I know that there's a 2.0 version and I'm on the 1.0 version. that was
mostly just for adoptability just because I'm not sure…
00:30:00

Dylan Hobbs: how fast the orgs that are implementing verifiable credentials
are migrating to V2. So if they wanted to test this out I thought it might
be an easier way to kind of approach it. But I would absolutely love to
have those extensions added into it.

Rosalyn Curato: That's part of the tension we're facing,…

Rosalyn Curato: Which is what is the best way to do this versus what is the
way that meets folks where they are. so that's certainly a balance we're
trying to strike. Mood, you've had your hand up.

Mahmoud Alkhraishi: First of all, I'm going to echo Mano. This is a really
awesome demo and a really awesome spec from everything see. I was wondering
if you could talk a little bit about the audit layer. So, I'm looking
through the spec itself.

Mahmoud Alkhraishi: There seems to be a lot of information there. Maybe if
you could give us an elevator, a pitch of how does audit layer work, what
it's supposed to do, and who maintains it, all that

Dylan Hobbs: Yeah. …

Dylan Hobbs: I'll share the open source repo right here as well in the
chat. But it's pretty portable right I in the demos they're just kind of
like using server memory and whatnot, but we have them internally mapped to
let's say if it's Cloudflare, you could use KVS or whatever it is that if
you want to attach it to a database or wherever you want those to be sent
then you can. It's not hardwired to a specific implementation but the
maintainer of it would be the server's responsibility.

Dylan Hobbs: So if a enterprise or any business is implementing their own
MCP servers they would obviously maintain their own audit logs or…

Dylan Hobbs: their own audit trail and that's where they would have that
sort of I guess trace record or proofs wherever they want to store it but
the option is up to them on how they want to plug it in or what they want
to attach it to. I don't know. I hope that answered your question.

Mahmoud Alkhraishi: Do we have anyone else on the queue?

Rosalyn Curato: No one else with their hand up.

Mahmoud Alkhraishi: Then I'm going to ask a second question.

Rosalyn Curato: Go for it.

Mahmoud Alkhraishi: How are you binding the credential to the agent? what
prevents any other credential from being used by any other agent or
anything of that sort?

Dylan Hobbs: It's inside the delegation credential itself. So there's a
issue word and an issue or a delegator delegate and one of them is bound to
the agent and the other one is to the server. So when the agent connects to
the server that's sort of what creates that binding and then any delegation
that's created from there is attached to basically that agent in session.
So if you do a delegation in a connection with that server like what I
showed you after the delegation's created then the agent can act and reuse
that delegation. And if the server has OOTH as an initial connection to it
then you could trace that back to a prior session or a prior o because it'd
be like the same user behind it. So yeah

Dylan Hobbs: Honey.

Manu Sporny: Just on that point specifically the same kind of question that
Mammoon has what I'm so some of the technologies that we have right now
specifically HTTP signatures with the did stuff that you're using would
allow the agent to do continuous verification on every single call by doing
a digital signature over every single call. So what it sounds like you're
saying is like when they establish a session they do some kind of
establishment of identity via digital signature at some point and then you
just use that for the rest of the session which is a totally legitimate way
to do it as well. I guess where are you leaning in the future?

Manu Sporny: Are you thinking kind of this continuous per request
verification or are you thinking just establish, …

Manu Sporny: identity at the beginning of the session and then if someone
steals the session cookie, too bad, Which is again a totally legitimate way
to do it. that's how most websites work today. thoughts.

Dylan Hobbs: Yeah. No.

Dylan Hobbs: That's a really good question. So, I think it's probably
leaning towards the first where the agent itself is going to have its own
key material for that session, right? And then the server itself has it.
And then you have the user as well, So you have kind of three parties of
trust in there. And that's sort of what's binding the credentials when
they're being reused. So if someone stole the session cookie, for example,
I don't know if it would work that way because you would still have to have
proof of ownership over the key material in order for the session to
continue. So, if the agent is making a request, the request wouldn't go
through because the session wouldn't be signed anymore, right?
00:35:00

Dylan Hobbs: If you tried to replay it again or if the agent tried to take
an action, it wouldn't, from a hijacked session for example. it would break
the chain of proof.

Manu Sporny: Okay, I think I followed that. interested to read more about
it. whenever it's out

Rosalyn Curato: Yeah, great question.

Rosalyn Curato: Thank you.

Mahmoud Alkhraishi: I guess a follow up on my end. that agents will be
changing their behavior in a few ways and…

Mahmoud Alkhraishi: not just the MCP servers, right? some of those include
things like having specific key materials for the deads of the agents, but
also things like where the agents are going to store these credentials,
right? You is that talked about at all in this spec or

Dylan Hobbs: Yeah. Yeah.

Dylan Hobbs: Yeah. so I'm not sure if you guys are familiar with the other
MCP directories like Anthropic has a registry. it's governed but it's not
like at that what's the word I'm looking for? there's a uniqueness at least
between the servers on it, but there's still no proof of the server when
you're connecting to it actually being that server.

Dylan Hobbs: If you look at a lot of the directories, they'll have
duplicate entries. they'll have maybe multiple desktop commanders or
multiple, Google Drive servers and then connecting to the right one is sort
of up to the user or the enterprise to vet them and then maybe add them to
a MCP gateway or something like that. So what we're leaning towards is
really registries should actually have key material for the servers and
then if you're using something like a did web method the other aspect of
the key would be from that trust registry instead of within the server and
that way you're able to also the trust registries themselves could have
that trace or audit trail as well.

Dylan Hobbs: So instead of having a GitHub repo where you have an MCP
server and then someone installs it and you use it on your organization
should host the key materials for the MCP servers that your organization is
using and then that way you're able to trace the actions on the MCP
servers. the big issue here I think is that when an agent connects to a
server you have tool injection and really just the attack surface compounds
right with the amount of servers and also the tools in it and then the fact
that a lot of these are just maybe fork repos or hosted remotely you don't
really know what's in there and on top of that in just MCP in general you
can have resources as part of

Dylan Hobbs: the content that's inside of the server aside from just the
tools. So those resources are also like an attack vector, there could be a
document telling the agent, hey, every time that you call this tool, also,
save it here or do something else with it that's nefarious. so the main
part is to kind of minimize that attack surface.

Mahmoud Alkhraishi: So that makes a lot of sense to me from the MCP servers
perspective. Identifying that those servers is Understanding their
trustworthiness is important. But I think my biggest point that I don't see
contemplated yet is the agent itself is going to be responsible for having
a wallet. I suppose in order to put their credentials in or they're going
to have to have their own key materials and…

Mahmoud Alkhraishi: I don't see that anywhere in the spec. Is that
something that you think is in scope or…

Dylan Hobbs: So the.

Mahmoud Alkhraishi: out of scope

Dylan Hobbs: Yeah. That's a good point. I mean that it would be amazing if
the models actually had some sort of notion of identity that they
presented. and it also one of the funniest thing, not funny, but one of the
craziest things I think I'm not sure if people here are aware, but
Perplexity for example, a lot of these LLMs and stuff, they're saying we'll
be on this IP range or some of them do present a signature in the header
like chat GPT does, but in Perplexity's case, like they've said, hey, we
use this IP range and all these things.
00:40:00

Dylan Hobbs: And if you have a robots txt file and you don't want your site
to be scraped let's say then ideally it would adhere to it and that robots
txt would respect that and Cloudflare caught using J3 J4 perplexity
basically encountering a robots txt and then changing their user agent to
look like a regular Chrome user and then going back and scraping the
content. Right. So, no, I think there should be standardization on all
agents when an LM's plugged into something. that should be there, what we
do is we kind of do that through we have a Rust engine and we're doing this
detection aspect of it, similar to what Cloud Players J3 sort of thing is
doing. but obviously in a real world situation, you can't really count on
that.

Dylan Hobbs: if it's like an organization that's connecting to the servers,
you have a little bit more control over it because you'd have, whatever
clients your own employees are using and then also the servers that they're
connecting to. But I think there's definitely a call to action needed for
broader, frontier models and so forth to be a little bit more transparent
with how they're presenting their models and…

Rosalyn Curato: Love the questions.

Dylan Hobbs: and maybe a more reliable way to detect on them.

Mahmoud Alkhraishi: Thank you. do we have any other questions? Do we have
anyone else who wants to bring anything else? All right. sorry.

Mahmoud Alkhraishi: I play Manag.

Manu Sporny: I've got a thousand questions.

Manu Sporny: I'm just trying to hold back so other people get a chance to
ask questions. that agent site is interesting. I'm wondering how you're
planning on dealing with negative reputation what happens if one company
decides to dox another company or try to raise a bunch of negative
reputation against them.

Manu Sporny: how do you deal with, agents being reported for, bad activity
when it was just like a temporary bug and maybe this newest version,
doesn't have that issue.

Manu Sporny: So, I'm really curious about the know that ai site and I
guess, what's its governance look like?

Dylan Hobbs: Yeah, that's an awesome question.

Dylan Hobbs: So right now when you go to the website, all of the scores are
really based off of priors. So the scoring's built off of three pillars
really and it's prior, which would be kind of what you bring to it. those
include sort of is there an attestation of authorship? So do we know the
organization or the creator of this server? is it an the contributor
account? activity on it, all of those. Also the age of it, has it been
claimed? how long has that server been active for?

Dylan Hobbs: Those are all kind of like the prior info when it comes to
negative reputation or what you just kind of explained. we have some civil
resistance or cyber resistance and negative infractions are really on a
decay. So if there's a report of abuse on it, it's going to definitely
knock down the score of it, but it's going to decay over time. and yeah, I
mean if there's a lot of separate servers or a lot of separate interactions
like you can see again in Rosland's example right here, this is just based
off of prior. So this server for instance doesn't have any interactions,
but the uniqueness and partners as well as interactions are really way more
what would I say like they're more weighted.

Dylan Hobbs: they're weighted So if a server is interacting with multiple
different partners and those partners have their own history of logging or
reporting an interaction and then they report abuse depending on those
partners. those will weight the infraction of it. so really it's just kind
of like it goes into a blended mix and…

Dylan Hobbs: like a beige prior essentially for how the kind of trust score
is sort of ebbing and flowing
00:45:00

Rosalyn Curato: and we've been building up towards that as well.

Rosalyn Curato: So our first step has been to have people come to us as
that source of truth for that public trust registry. For example, one of
the partners that actually gave us a bunch of their MCP servers and agents
had their own registry. However, because ours is built around the concept
of identity, you can trust that every agent has one unique entry. We found,
we just pulled up an example, they had four entries for one specific agent.
And so that alone was compelling enough for them to want to lean into the
solution.

Rosalyn Curato: And then over time, you're absolutely right, we have to
have some kind of checker format so that we can control for bad behaviors
that could exist and proliferate on the site.

Dylan Hobbs: And also just one thing to note we do want to partner with
auditors or…

Dylan Hobbs: security tooling that'll do scans and going off of the priors
we do look at like if there's an MPM package for example linked to the
server and then those have a new patch release that would obviously warrant
a new scan and then that'd be a way to repair broken trust and also kind of
I guess distinguish between you actions or…

Rosalyn Curato: Love all the questions. Mhm.

Dylan Hobbs: treatment that it was doing before compared to what it's doing
presently.

Dylan Hobbs: Yeah, these are great questions.

Mahmoud Alkhraishi: Do we have anything else?

Mahmoud Alkhraishi: Anyone else to bring up? Any other questions?

Mahmoud Alkhraishi: Please man.

Manu Sporny: I'm sorry I'm that annoying kid in class.

Manu Sporny: Two thoughts. The first one it would be great if you showed
some of this to the verifiable credential working group, the official
standards group, so that it's in their head. I don't think we have use
cases yet. I don't know, Joe, you might want to correct me on getting these
use cases in I think would be super useful.

Manu Sporny: I saw Joe come off mute.

Joe Andrieu: Yeah,…

Joe Andrieu: I just want to say we don't Yeah,…

Manu Sporny: …

Joe Andrieu: pretty clear.

Manu Sporny: so it'd be awesome to get just this into the group's head.

Manu Sporny: The other bit is I don't know if you're looking at kind of
upstream registration like up upstream KYC KYB on the business that
operates or so there's some work that's going on a slash who is endpoint
that would publish verifiable credentials about the entity that is
operating the MCP server or the entity that may be operating the agent or I
heard you say maybe we want the human that is directing the agent to do
something so that has a KYC component to it.

Manu Sporny: are you actively looking at I integrating those things as well?

Rosalyn Curato: Yes.

Dylan Hobbs: Yeah,…

Manu Sporny: Okay. Okay.

Dylan Hobbs: absolutely. Yeah. Yeah, absolutely. the lowest tier of it of
the prior would be for authorship is just kind of like if it's a GitHub
account in order to claim your agent. So right now we're pulling in all of
these different servers that we're finding from directories, some of which
we partnered with, and then, we're creating, an identifier, like a DID for
each of the servers. And they're open to claim, right? But in order to
claim it, you have to prove ownership or, access to that GitHub repo. And
that's probably level one of sort of attestation of authorship.

Dylan Hobbs: But if they wanted to, if it was an organization, even if you
wanted to have proof of humanood for that authorship, then you would do
something like an ID IDV flow for a KYC something. If it's an org, you
would do a KYB attestation. And those would be obviously a level up from
just a OOTH claiming

Mahmoud Alkhraishi: Thank you, Harrison.

Harrison Tang: Yeah, I'm just curious what are the popular agents out there
who are you seeing from your agent registry? You talk about perplexity and
those kind of agents that help basically browse or scrape websites on
behalf of their users. But what are the other types of interesting agents?

Dylan Hobbs: I'd say the biggest open claw agents because that's kind of
just opened a whole new can of worms really when it comes to everything
right before it was sort of just like frontier models or maybe like a
agentic SAS company or something right where they're kind of wrapping
whatever models or APIs that they're accessing with their own context and I
kind of consider an agent really like an LLM paired with some sort of
runtime that has its own context and tooling And that's what I would
classify as kind of like an individual actor when it comes to this. Yeah.
00:50:00

Harrison Tang: Yeah, that's very interesting. I wasn't expecting you to
talk about open cloud agent. Then my followup question on this open cloud
agents is that who is I guess the human responsible how do you do kas on
open cloud agents,…

Harrison Tang: It's probably not open cloud because open cloud is open
source projects but how do you do kya? Yeah.

Dylan Hobbs: We did kind of a proof of concept.

Dylan Hobbs: We called it identic claw. but really what that is is it's
like a openclaw runtime or container wrapped with a gateway. And that
gateway is adding that identity presentation to all requests that go
outside of the container. So if those agents request access to a website or
a service or whatever it is and that service is savvy enough to look for
that presentation…

Dylan Hobbs: then they can do a lookup on that KYA for the agent.

Rosalyn Curato: So Harrison,…

Rosalyn Curato: we had fun when OpenClaw was and Moltbook were first a big
hype cycle. Dylan came back and said, "Hey, I think we can create OpenClaw
agents with a security wrapper with an identity." so the team was able to
spin that up pretty quickly and then our entire organization created ident.
It was a lot of fun. But I think more specifically addressing your
question, it's really the fact that OpenClaw is now your execution
assistant, Your operator. It's not just someone I can talk to to go find
research for me. It's actually helping perform tasks on my behalf, And so
that growth and that ability for AI to help do things for me is really what
we're trying to address, That's the power that we're seeing today. And a
lot of it's very personalized and individual.

Rosalyn Curato: And so part of what we're working on with our MCPI
framework is how to allow that agent interaction to take place across
departments within an organization.

Harrison Tang: Sorry, sorry I raised my hand and…

Mahmoud Alkhraishi: Harrison,…

Rosalyn Curato: Then I started talking go ahead.

Harrison Tang: follow question.

Mahmoud Alkhraishi: are you still have anything else or are you

Rosalyn Curato: No, go for it.

Harrison Tang: Yeah. Yeah. No, this is a fascinating conversation. So then
my next question is more business kind of questions. is that in the identic
claw, right? this gateway that you're talking about the person that's doing
the action needs to actually install that gateway right and to make it to
work. So this is a classical marketplace kind of questions right and it
sounds like for this to work clients has to do it but a lot of clients
what's their incentive right to actually declare and right declare their
agency for lack of better terms.

Harrison Tang: So, how do you actually get this identical claw or actually
MCPI to kind of work? Because it sounds like it's a classical two-sided
marketplace where the clients has to opt in has to have incentives to join,…

Harrison Tang: And then the same thing with the Obviously, servers have
incentives because they want authenticated requests, but what's the
incentives for clients?

Rosalyn Curato: Yeah, I'd love to address that.

Rosalyn Curato: And Dylan, please feel free to chime in, too. But what
we're seeing is actually the masses are not yet leaning into AI in this way
just yet because There's still a lot of worry about security leaks and
risks and PII being exposed. And so a lot of organizations and individuals
are not yet leaning into this capability. We saw significant adoption of
identic law because people felt comfort and they liked knowing that there
were security that if an agent tried to interact with their agent then
they'd be able to know and trace back who's that associated with and then a
random thing we built into our identic law is there's a kill switch.

Rosalyn Curato: So for people who are less, technologically savvy, and
trust that, okay, if I really don't want it to be doing anything anymore, I
can just hit this one button and it'll stop doing anything it wants, right?
Or anything. so it's that trust piece that's missing that I think is
helping people feel like the more and more that we build that, the more and
more they can trust starting to lean into experimentation with Many of the
organizations we talk to, especially on the retail side, are simply still
blocking all agents, all bots, but they know they need to start working
with agents because blocked agents is blocked revenue, right? It equates to
blocked revenue.
00:55:00

Rosalyn Curato: And so, the more we can build that trust, the more we can
provide that identity and that clarity on who the agent is is going to help
them benefit Dylan, anything else you want to add to that?

Dylan Hobbs: I would just say speaking to the two yes problem for example I
think that's kind of another call to standardizing right I think bot
detection or…

Dylan Hobbs: scrapers or whatever that's always like a commodity and it's
always going to be like that unless there's a standard for actually
presenting away HTTPS or TLS for example and I think a good way to think of
it would be like if there's a standardized way or an organization has that
then when they offer their MCP server which is a way for agents to interact
with their services or their endpoints they would make it a requirement to
have that presentation or that understanding of who's behind it like that

Dylan Hobbs: KYA insight in order for maybe a less rate limited interaction
or less rate limited session. It really would depend on their own risk
tolerance and their comfort level. But I think right now there's no sort of
standard to lean on if you're kind of like a CISO, on how to regulate that
or how to say how it should be done.

Mahmoud Alkhraishi: All right. thank you Roslin and Dylan. This was an
absolutely wonderful presentation. are there anything that you'd like to
point people towards or ask the community for help on specifically? I am
Ashton SCBI but I'm being specific.

Rosalyn Curato: Yeah, I think we shared a number of resources in the chat.
we love the questions and the interaction. So, thank you for all of that.
In terms of next steps, it sounds like we should connect with the
verifiable credentials working group to speak there about some of these use
cases. Manu, are there any other next steps that you'd like us to pursue
following this conversation?

Manu Sporny: I think that that would be fantastic and then that will lead
to a bunch of next steps after that I think.

Rosalyn Curato: So, who should we coordinate with to make that happen?
Excellent.

Manu Sporny: Any of you can email me I can put you in touch Harrison and I
mean Mahmood any of us could put you in touch.

Mahmoud Alkhraishi: I'll connect you guys with the chair.

Manu Sporny: Okay. Awesome. Thank you.

Rosalyn Curato: Thank you all for the interaction and the questions. Again,
we really enjoyed being here. and…

Dylan Hobbs: Thanks everyone.

Rosalyn Curato: we look forward to talking to the VC group as well. Y.

Mahmoud Alkhraishi: Thank you everyone and have a great rest of your
Meeting ended after 00:57:50 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*