# Securing AI Agent Skills and MCP Supply Chains

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-03-17

## Transcript

We scanned 3,984 skills.
13.4% of all skills, which is 534 in total, all contain at least one critical level security issue.
That's scary.
If you think about it, once people find out how easy it is to create a skill, potentially what the impact...
can be people will use it in a malicious way why don't we go ahead and talk a little bit about how an attacker would try and create something nasty something malicious how would they go about that i think that but the most important one is most of these skills run on your local machine they have execution power but they probably run on your machine as root or at least it has a lot of privileges if you give claude the power to execute i don't know bash scripts or something like that and if i can infect a skill in that way that it will create a bash script for me to do something.
I'm basically vibe coding my prompts now or vibe coding my exploits now in that way.
We can give instructions to create code in a normal way, but you can also now give instructions to do malicious things because it's all natural language processing.
How would a user use Snyk to identify where these malicious skills and MCPs are?
Yeah.
So back in November, we hosted the first ever in-person AI native DevCon in New York.
This June 1st and 2nd, we're bringing it to London.
It's two days built for AI-nated developers and engineering teams.
One day full of hands-on workshops and one day full of practical talks on agent skills, context engineering, agent orchestration and enablement platforms, and how teams are actually shipping AI in production.
Join us at the brewery in London near the Barbican for all of that.
Plus, networking, parties, giveaways, and a room full of people building the future of AI native development.
You can also join us from anywhere in the world via the live stream.
As you're listening to this podcast, you get 30% off your ticket with code POD30.
Just head to ainativedevcon.io and we'll see you in London.
On today's episode, we discover that 13.4% of all published skills contain at least one.
critical security issue.
That is frightening.
Also, we asked the big question, what can we as users of these skills do to protect ourselves and block potentially malicious skills from our development environments?
Today, I'm here in Atlanta with my good friend, Brian Vermeer.
Brian, how are you?
I'm great, thank you.
And we're here for a conference actually, DevNexus, and it kind of made sense actually that while we were here, we chatted about an awesome new launch that happened today, which is all about adding sneak security scans into the TESOL registry.
Brian, tell us a little bit about yourself first of all.
Thanks, Moons.
I'm Brian.
I work for Snyk, obviously.
What we do for since forever, we build developer tooling to make security more easy for developers and to not put it on the security engineers, but make developers self-sufficient and make sure that they can integrate security easier in their workflow.
And I think these steps as in creating skills to actually check skills or check MCPs or whatsoever is something that...
definitely adds up with what we have been doing over the last decade or so.
And it's interesting.
We'll focus on that today, actually, during the session.
But it's interesting if we look back at where Snyk kind of came from.
Snyk obviously actually started more in the SCA space.
So looking at third-party dependencies and then kind of moved more from there into the container space and then into the SAS scanning of your first-party code and so forth.
But of course, more recently with the AI boom, there is a greater...
expansive code that could exist now because assuming people using AI tools create more code faster, how does that, how does sneak deal with that?
Well, I think it's complementary to each other.
First of all, you still need with all the AI agents or the, let's say the coding assistants, they come up with a lot of stuff and most of it is quite good nowadays, but sometimes they come up with things that do not really add up or there is a problem in it that you don't see at first hand.
So a security tool or scanning tool makes sense to still do that in your pipelines or in your IDE or something like that.
Same with SAS analysis or make sure that your dependencies that you have are valid now and are valid in the future.
But you can imagine now that if you have an agentic flow and you want your agentic flow to autonomously create code, that that code is also checked upon.
Yeah.
So that that code is not vulnerable or slightly vulnerable, but if you give that feedback to your agent and that agent sees that, that can and can help you in an iterative process to make that code better.
So I think it's a very logical step for us to be in that space as well.
And can, even if you ask really, really nicely to an agent, can you get an agent to give you secure code every time?
We try that.
If you want to look at some experience, my other colleague.
Brian, by the way, he did a bunch of these experiments on our YouTube channel.
He's like, hey, make sure that I want this application to create a note-taking app.
Make sure it's super secure because my life depends on it.
And every now and then it comes back with insecure code.
So, yes, these models are getting better and better.
But we also have to know, like, these models are, well.
older than now.
They've been trained in the past.
And they're not specifically created for security.
Most of these models are general purpose models.
So it makes sense to have a specific tool checking them and basically an add-on to whatever you want to do.
And how about like, obviously with things like agents MD, rules, files, skills, and things like that, how much...
How much value does adding secure coding principles and best practices into those to kind of like guide an agent to generate more secure code?
How much does that help?
How much does that still leave to chance if you only trust a skill to do that?
I think if you only trust the skills, you still leave it to chance.
I mean, most of these processes are processes that can be deterministic.
the security scan, and we've been doing that for years.
So I think it's safe to say we're kind of good at it.
But if you know, like if you, it's just like with children, right?
If you ask it the same question twice, they will come up with different answers.
So that, that is.
Both wrong normally as well in my experience.
Well, I think.
Maybe that's my case.
I don't want to go into that.
But yeah, so I think the models are getting better and better and they will produce better code.
But still, like if you look at what, what the training data for that is, if you look at what's on Stack Overflow or what kind of open source projects are there, there are still a lot of vulnerabilities in there.
May not be massive vulnerabilities, but even smaller vulnerabilities, if you chain them together, can end up in a chain or an attack chain and therefore be massively destructive into a specific system.
Yeah, I agree.
As I mentioned at the start of the episode, we announced the fact that we now have an integration between Snyk and TESL.
TESOL through the registry is exposing some of the security scan results from the SNEAK scans about every single skill on the registry.
So tell us a little bit about the SNEAK agent scan that scans MCPs and skills.
All right.
Yeah, it's one of the newer open source products from the SNEAK team.
And basically what it...
does is MCPs, you can see MCPs as the next supply chain problem, right?
You are adding features and functions to your LLM or to your agent in this case, so it can execute that.
But what kind of stuff is there?
What kind of, I mean, you see the functions it has, but what kind of input and what kind of output does it have?
What kind of flow comes through it?
And...
For instance, if you trust it now, it's good, but what will the follow-up, what will the new version do?
So these are the things we can monitor and we can scan for you.
But we also scan scales, and scales effectively are MD files.
And because it's just plain text, they can be vulnerable to all sorts of things like prompt injections with, I don't know, the limiter confusion to confuse the model that...
It wants to give an instruction, yes or no, or it can be obfuscated in, I don't know, even in Chinese or something like that, or in B64 encoding.
You can think of it, these kind of things.
And there are all sorts of things that you don't want to blindly have in a skill, but since a skill file can be quite big, you don't want to do that manually.
So that's where we can help with sneak agents again.
So some of those issues that you mentioned, the security issues that you mentioned, Sneak released a toxic skills threat taxonomy table in their blog.
So talk us through a few of those different types of threats.
And one of the things that I love, actually, is you highlight whether they're almost like the severity, right?
It's like critical severity, high severity, and so forth.
So they're not all made equal.
Some are more dangerous than others.
Yeah, obviously.
I mean, I think for everybody quite well-known are prompt injection detections.
And that one is top of the list.
critical risk level.
And you can think of hidden instructions within the skill that don't necessarily add something to the skill.
And these can be encoded, like Base64 encoded, or give it a weird language like, I don't know, Hawaiian or something like that that we cannot read.
So they can be obfuscated.
And you can think of other things like Unicode smuggling, where we use parts of the Unicode spectrum that is not visible, but can be readable for an LLM.
And you can put instructions in there like, hey, when you want to use this skill, make sure that you download this binary first.
Or it can cascade to other skills that are maybe not on your local machine but somewhere else that you do not intend to use.
It's really interesting because it's kind of like, from a user point of view, the user assumes they've got a good skill.
They download their skill and then they assume it's Claude deciding on these actions.
And so basically, essentially by using that skill, prompt injection or something I didn't even think about yeah downloading something of course Claude can do what it wants and it will probably prompt and say oh can I do this and you just assume yeah I'm sure this is fine or certainly I guess it can be described in a way which is convincing to the user and it could I suppose like you're creating code so it could it could expose that code to the internet, it could share secrets, it could download malware onto your local development environment.
Think of it, most of these skills run on your local machine and they have execution power, but they probably run on your machine as root or at least it has a lot of privileges.
And if you give Claude the power to execute, I don't know, bash scripts or something like that, I create bash scripts and if I...
can infect a skill in that way that it will create a best script for me to do something.
I'm basically vibe coding my prompts now or vibe coding my exploits now in this way.
So you should think of it like that.
We can give instructions to create code in a normal way, but you can also now give instructions to do malicious things because it's all natural language processing.
Yeah, and a lot of the, I'm looking through the table now, a lot of the toxic skill threats.
They're actually quite similar.
There's nothing here which is like so new.
Even prompt injection.
I mean, we talk about AI being only a few years old, really.
But I mean, you know, prompt injections, old school now, isn't it?
But yeah, a lot of here, like the malicious code, I guess credentials of secret detection.
Yes.
Unverifiable dependencies, direct.
Oh, direct money access, or should that be direct memory access?
Yeah, for instance, if it has access to, I don't know, crypto operations or anything money-related.
Because, yeah, that's now quite an interesting thing.
If you connect everything to everything with your personal assistants or with your skills and your agents, if you have a crypto wallet there, maybe you want to directly access that.
So these kind of things.
And, of course, I guess one of those joys of...
From an attacker's point of view is with people using so many MCPs, when you have access to that agent, when a malicious person has access to that agent, they all of a sudden can start grabbing things from MCP.
That's connection.
So maybe that's linear.
Maybe that's GitHub.
Maybe that's your, maybe that's what?
Anything that can be your email.
It can be your Google Calendar.
But it can also be that you have an MCP that now is just reading your emails.
And you did something, you installed it with MPX, MPX something, something slash latest.
And you trust all of these functions.
And then they change the function.
Or even the input and output might be the same.
But in the meantime, in the middle, they have a side effect of, I don't know, downloading a binary.
And these are things that, for instance, for MCPs, you absolutely do not want.
Yeah.
So you want to trust them.
But just like we had in the pre-AI era, let's call it like that, with...
dependencies and frameworks that you don't want to just blindly trust them.
It's the same here with skills.
But on a different level.
And of course, skills are so prevalent right now.
A lot of the time, whether it's MTPs or skills, it's like the speed of how fast the technology gets distributed and people want to jump on it in the world of AI.
People tend to leave security as a thing that, oh, I'll get around to that.
I want to try this out first.
Yeah.
It is so, it's actually mind-blowing, even for seasoned engineers that know all their best practices, and they're now like, oh, but I can do all of this cool stuff with my agents, and I can be 10 times more productive because I can spin up 12 agents or something like that.
You still need to do your due diligence.
You still need to be aware that these things that come from a random GitHub repository might not be safe or can be safe now.
to win your trust, but can be vulnerable later.
So the necessity of scanning these skills and MCPs is there, is definitely there.
And it's also one of the reasons why we love versions so much.
Like, you know, we allow, like within TESOL, we allow people to pin to a particular version so we can say, I want this skill at this version.
If you don't do that, you're open to any skill owner.
effectively making horrible changes to their skill that you don't agree with.
Maybe you agreed with it at the time.
Maybe it actually doesn't even have to be malicious.
It could just be a skill that changes into a way that you don't wish to work.
But worst case, it could be a security issue or malicious.
And you're pulling that in straight away.
It was safe yesterday.
Today it's not.
And you're pulling that in and you're none the wiser.
Yep, exactly.
And I think that is also the case with...
using these versions, or not pinned versions, but fluid versions.
We've seen that in dependency trees for years now.
You don't know what you're getting into, and this might break your application, and in this case, this might break your skill or does things that you do not want.
Yeah.
So let's look at the results, actually, from one of the recent reports that Snyk came out with.
So you scanned 3,984 skills in total.
And really, really interesting, 13.4% of all skills, which is 534 in total, all contain at least one critical level security issue.
That's scary.
Was that expected?
I don't know if that was expected, but if you think about it, once people find out how easy it is to create a skill and...
potentially what the impact can be, people will use it in a malicious way.
So I think it, yeah, you could have expected this.
It's so easy to create something.
You can literally put just text in a skill file.
And if nobody actually reads the skill file themselves and just implement them or use them, yeah, obviously we're going to try to steal your money or execute code or make your computer part of a botnet or name it.
So, yep, I'm personally not surprised, but I'm not sure if it was expected to be this high, but it's a lot.
And it's interesting, because if we think about false positives, when we think about code, when we think about third-party dependencies, I'd say it's almost easier to define what a false positive is, because they have syntax that is very, very important to follow, otherwise code won't compile, code won't run, etc.
With written language, though, That must be much harder to find a false positive.
Yes, it's definitely less obvious.
And a false positive, the question is, is it a false positive, yes or no?
Because it might not be invoked, if you can call it invoking, like right now, but it might be in the future, depending on which model you're using, or if the model is sensitive to a certain type of attack.
If we go back to the top one, the prompt injection kind of thing, there are so many techniques how you can do prompt injection.
from the limiter confusing to splitting payloads to doing it in multi-steps.
And some of these models that you might use are more vulnerable than others.
And over time, models will be stronger towards that.
But if you combine all these attacks and you just obfuscate them in some way, well, the chances are that if enough people download and use that skill, you will get something out of it.
Yeah, yeah, very true.
So why don't we go ahead and talk a little bit about how an attacker would try and create something nasty, something malicious.
How would they go about that?
Well, I think the most important one is trust, because you want to trust either a skill or an MCP server.
And we spoke about it a little already.
If the trust is there and you trust, let's use the MCP server first.
You have an MCP server with the reasoning of, okay, I'm able to access your calendar and see what your appointments are for today.
Great.
It works.
You implement it.
Does nothing weird.
It's fine.
But then we update the skill.
And then we put something extra.
We put a side effect in.
Or we return, instead of just your calendar items, we return it an instruction.
But you already trust it.
You trusted that skill.
You trusted that specific function in it.
But from now on, even maybe silently, it can operate in a different way or it will operate in a different way.
And that side effect might be able to, I don't know, offload credentials or install a binary or name it.
So that is one thing, a trust.
Trust is super important.
Then most of these things, and especially specifically in skills, will be obfuscated.
And obfuscation can be done in Unicode and coding some parts of...
the Unicode spectrum are not visible even for the human eye or for if you read it in a text editor, but are readable instructions for an NLM.
It can also be something that is named in a different way, is base 64 encoded, or even maybe simply encrypted.
So that obfuscation pattern that you won't obviously see it, yeah, that is something as well.
And...
Obviously, if we can do that, we can make these attacks in steps.
If we're able to, you trust me, I add something in that skill or that MCP server, I may be able to disable some of your security guards or guardrails or maybe even rewrite your guardrails.
And in the next step, I will do the attack.
So it's not a one-shot thing in most cases.
Trust is an interesting thing as well because essentially when we talk about trust, very often these skills, hosted just in a GitHub repo.
And it goes back to that very same problem of open source code.
You're now trusting someone, potentially you don't know where they live, you don't know what their background is, you don't know what security processes they follow, what software hygiene they have in and around their project.
But because it does something that a developer of a company wants to use, they download it and they pull that directly into their environment, potentially.
you know, using that, maybe checking it in or maybe adding it in so that others will also use that, you know, sharing across the company.
And it's so dangerous.
We don't have those similar checks up until now.
How would a user use Snyk, I guess, directly?
And then we'll talk about within the Tesla registry to identify where these malicious skills and MCPs are.
Yeah.
So say you have skills installed in...
Claude or any of the other well-known agents that you can use for skills or for MCPs.
Basically, it's on GitHub.
Funny enough.
I definitely trust it then.
Yes, yes.
There's a company behind it and we definitely want to retain our...
our good profile of we're helping people.
But if you go to, what is it, github.com slash sneak slash, what is it, agent dash scan, that is the sneak agent scan, and you can basically use it.
It's a Python project, which you can launch with UV, and then it will scan the most well-known positions on your local machine, for instance, to...
where skills are stored, like the .claw library where your skills can be stored.
And same for the MCPs.
And if you have a specific location where your skills are stored, you can give that in as well.
And it will look for, are there anomalies there?
So the scan that is happening is not just one simple scan.
It's not a deterministic one thing to do.
So there are some static scans around that, but there are also some LLMs involved that, basically LLMs as a judge.
different LLMs that look into, hey, is this vulnerable?
Yes or no.
And the combination of all these checks, because there are multiple checks, will be handed to you in this case, your terminal to see like, okay, this is what you have.
These functions in your MCP or these things in your skill are potentially dangerous.
And it will give you how dangerous they are.
It will give a score to you like, hey, this is, I will give this a 0.5 because yes, potentially this can be used.
However, so it's nuanced in such a way that it's actually actionable for you.
So then you know what you're having, what kind of functions and what kind of skills you deploy towards your agents.
And you can make at least an educated decision.
Do you want this, yes or no?
Do you want to uninstall this skill?
Yeah, it's one of those things that, you know, it's a starting point.
You want to look at it.
You want to flag something that it believes is bad.
Maybe actually some of those activities or those actions that the skill will do is actually intentional.
But it's about flagging the fact that that's what it's trying to do.
And it's a case of, okay, is this right?
And then I can make the decision of, yeah, actually, yes, I trust this.
Or maybe it's the author.
And I look at the author and I say, yeah, actually, this is an author I absolutely trust.
And I want to use it.
Yeah, for instance, even if you create your own MCPs.
I create my own MCPs to discover what kind of Java conferences are still open.
I don't want to miss a call for papers, for instance.
Yeah.
I have that as a very small MCP.
And then it flagged it as, hey, you are pulling in data from an external source.
But since this is static data, the chance that this is really vulnerable is quite low.
But at least you know that this is happening.
And then you can see if you want to trust it, yes or no.
AIR Native DevCon.
CFP still open by the way just just in case people haven't haven't submitted.
The other way of course is you can use it directly and that's really cool to actually be able to actually see what's on your local machine and identify my environment as is please can you please can you scan that to tell me to tell me what's what's there as well as that you can actually look on the TESOL registry and on every skill that's in the TESOL registry.
a sneak scan has occurred and the results of those sneak scanners right there by the skill.
And you can click on that and you can find more information about exactly, first of all, what the criticality of the outcome if there are issues.
And also, click in for more information, actually identify what does this actually mean and what can I do about it.
Yeah, the why and the how is so important.
So not everything that is flagged as vulnerable.
is vulnerable.
Sometimes it's intentional, but if it's vulnerable, you want to know why, what is happening.
And I think this is a great tool to have, but also it's great that you have it in your registry in that case, so you can make an educated decision.
Do I want to have that skill?
Yes or no.
Hey everyone, hope you're enjoying the episode so far.
Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about agentic development.
whether that's talking about the latest tools, the most efficient workflows, or defining best practices.
But for whatever reason, many of you have yet to subscribe to the channel.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favor and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
Yeah, absolutely.
And when you look at it, of course, we have...
a bunch of evals, we have the review, we have the task evals and those types of things.
And now with the security scan, you're starting to get a picture of what the skill is and you can make an informed decision about, yeah, this is actually the right skill or actually I'm going to search around and try and identify other skills that I might want to use.
Okay, so if you're a skill creator on the TESOL registry, you should definitely go ahead and look at the skills that you've got, see from the scans.
if there are various things that are being flagged.
And of course, what does a user do?
Let's talk about a user from the point of view of a creator first, a content, sorry, a skill creator first.
And then we'll talk about a user, someone who's downloading skills, what they can actually do and look out for.
So as a creator of a skill, I own a skill.
It's not malicious.
I don't mean it to be malicious, but there are things that I'm writing in that skill.
That sneak is flagging up.
So what advice would you give to someone who owns a skill, who hasn't actually got anything malicious in there, but it is being flagged up because what I'm trying to do with that skill is actually doing things that require significant permission or to do potentially dangerous things?
Yep, that is an interesting one because it's a non-deterministic process, obviously.
But I would want to make sure that you are very clear at what your intentions are.
Yes.
And we humans are...
not always really good at explaining what we want and why we do it.
So that is definitely one thing.
And then obviously before submitting it, why not test it yourself?
Because these tools are available and it's a little bit of trial and error to see if it's getting flagged yes or no.
If your intentions are good, it probably will already get a very low score if it's getting flagged.
There's possibly a way to avoid that by instructing it in a better way.
And as a user, of course, one of the things that we do on the TESOL CLI is based on the scan result, we can potentially even block various skills from being installed based on the results of the scan.
So as a user, what should I do in terms of defending against these types of potentially bad skills?
Well, I would say if you use the TESOL registry, then are you already informed that what kind of problems are there?
So not just blindly install them, look at what is the intention of the skill, how are you going to use them, what kind of privileges do you give to that project, if I can say it like that, that the skill has access to, and then make your informed decision.
If it has a bunch of critical skills, I would definitely pass up on that skill, but you can see that right away in your registry.
If you have other skills, or maybe self-created skills, or manually downloaded skills, you can use the sneak agent scan yourself on your machine, to find out if these skills have these issues, and then you can inspect them.
I mean, it's a readable format.
So you basically can read what is there, but the scan already gives you information on why it thinks it has this vulnerability score.
So it will give you information, not just the score, it will give you information why the score is either high or low, and if this is critical or non-critical, with an explanation.
Amazing.
Now, one of the things that Snyk has always done very, very well is offering scans at various points.
And I love the fact that Snyk is probably one of those security companies that probably very much focuses on the developer and shifts left right to the IDE.
And now it's even further left into the agents, essentially.
So Evo Agent Guard for Cursor, this was one thing which, I guess, secures the agent lifecycle.
Talk to us a little bit about that, because I think...
It's interesting how the landscape has changed in terms of all these extra places that actually need securing.
Cursor, of course, being a place where it's like an IDE with an LLM inside.
Talk to us about how Agent Guard works in that kind of instance.
Well, let's first go to Evo a little bit because Evo, Sneak is known for being developer first.
Evo is more on the security team part of this whole game because guess what?
If you are a security team, you want to know what kind of models are there.
Are these models up to date?
Maybe you want to put guardrails in this.
Some of these models might not even be used.
Maybe you say like, hey, it's fun, but no deep seek models for you.
Or it's fine that you use GPT models, but maybe not GPT 4 or lower because they are well known to have certain vulnerabilities or are more vulnerable to certain types of attacks.
With EVO, we want to give the security team an overview like, hey, this is there in your landscape.
And this is how people are using it.
Now, if you're using Cursor or any other A, but Cursor is now the first one that we do, you want to know at the point that people are using it, what is actually happening?
Because if you go back to the principles of what LLMs are, they just do REST calls.
So things are going in and out.
And you can monitor that.
So you can also, at runtime, you can put guardrails in it.
Do you want to go to that, what I said, to that model?
It's not only are you specifying that model, but if that model is actually...
Target it.
You want to block that call, even though your employee that is using an agent tries to do it.
You don't want, in the end, that there's some sort of shadow AI available and that people are using non-approved models or non-approved MCPs.
So basically what we're trying to do there, it's more or less, you can describe it as a hook.
that we can live monitor at runtime what we're doing, and we can put guardrails towards the use of that agent and say, okay, yes, you can do this, no, you cannot do this, or you should be warned in what kind of situation you could use it.
But we can actively block, therefore, company-wide, for instance, certain calls to certain models or certain functions.
Wow, wow.
So it's really interesting that it kind of gives that more granular kind of ability to control or at least...
have some kind of harness on what people are using when.
And presumably it's actually very interesting just from the point of view of seeing what usage is happening and seeing what people are doing.
So who's the person that, who's the persona, I guess, the employee that would look at this would be what, the platform team, the security engineer?
I think it's more of a security team thing because you want to have a good view of your security posture.
And we already have these kind of things with the regular things like the SAST and the SCA scanning.
And now you can add with Evo, you can have a more high over holistic view of what your AI landscape is and what things are used in your company or in your environment.
And presumably there are policies that you can add as well that you can say, hey, these different teams, I want these different policies and filter NCP calls or certain NCP servers that are being used.
So all that control could be done centrally.
Yeah, you can definitely put these controls in.
Evo is still in an early stage.
It's available, but it's new.
So we are actively developing that and making it better and better.
So yeah, if you want to know more, you can go to evo.ai.sneak.io and try to get access to that because we're still in, what I said, we're still on early stage of that.
But I think this is a nice or a great step for security teams to have a broader...
a holistic view of their security landscape, including whatever AI stuff you're using.
Amazing.
Brian, this has been great catching up here at DevNexus.
It's good we bumped into each other.
And yeah, why don't you go to tassel.io forward slash registry, check out the skills that exist on the registry, and take a look at the sneak scans that show potential vulnerable issues that exist within those skills today.
Thanks very much, Brian, and thanks for tuning in.