# AI Agent Security Strategy for Agentic Coding

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

## Transcript

One developer wrote this skill that actually gave access to production credentials to the agents.
And this was not kind of paved path, you know, these credentials were not kind of just in time, nicely injected, they were overly permissive.
And when our security team saw the developers are using a skill like that, they freaked out.
We found, I think, 76, I don't remember the exact number, skills that had purely malicious code, so malware.
The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts, Guy Pagiani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
Hello and welcome to this special live stream with Tessal and Sneak In.
partnership.
So really, really happy for everyone to be here.
We have Christoph Houshta, who is a product leader in AI, security and sneak.
Hopefully I got that right, Christoph.
Yeah, pretty good, man.
Pretty good.
Yeah.
Hey, guys.
Good to see you.
Good to hear you.
And thank you for having me.
And of course, we actually worked together for a good number of years at Snyk, right?
Unfortunately, yes.
Unfortunately, it was a happy time.
A day doesn't go by when I don't think about how amazing that team was.
I forgot you as soon as...
Oh, well, that's good to know.
I'm joking.
Well, welcome, Chris.
Thanks for having me.
So today, tell us a little bit about what you do, product leader in AI and security.
What does that mean?
So I lead AI security incubations at Snyk.
Snyk is kind of traditionally an application security company.
But one of the things we want to get into, we believe that one of the biggest opportunities in security going forward is agent security and AI security.
And for that, we created a group on the side, kind of a little bit isolated from the core application security product.
And so we are there kind of running it more as an incubator.
And I'm incubating a few things in that group, a few products in kind of agent security slash AI security space for Snyk.
Amazing.
Amazing.
So let's go back a little bit down to the good old days when life was a lot simpler, pre-AI, mainstream AI.
Yeah, yeah, yeah.
Snyk was, of course, obviously always a developer security company, very much pushing the, you know, getting developers engaged and using security from an early stage.
Tell us about the, I guess, more traditionally, the code security platform that Snyk has.
Right.
So traditionally what Snyk tried to do was kind of this kind of shift left developer security motion where we said, okay, like, you know, security doesn't scale anymore without developer involvement.
So how do we get developers to kind of jointly own security program together with the AppSec team?
And the whole platform was all about collaboration, really, you know, like how do we get the security team to kind of...
govern application security program, run application security program at scale.
So do all the code scanning, open source scanning, container scanning, et cetera, et cetera, but also kind of close the loop with developers.
So get developers to fix, remediate, you know, run that and also get developers to basically prevent vulnerabilities from going to production, right?
So, you know, there's a lot of friction there between devs and security to this day, right?
Remediation is a friction, threat modeling is a friction.
blocking developers from pushing code to production because it has a security issue, it's a friction.
So really the company was all about kind of removing that friction and kind of empowering these two to collaborate.
Yeah, yeah.
And let's bring that into current day then.
And it's actually quite funny that we're talking about the recent past because Alan has noticed there's a Sinclair Spectrum on the shelf behind us.
See what else you can see on the live stream.
But let's bring that into the today now.
Obviously AI, people using AI either agentically or...
as an assistant and so forth.
It's very mainstream now.
What additional challenges does that bring from a coding point of view?
So, well, challenges and I think opportunities.
I think the biggest challenge for these developers is, okay, now...
Now we are using agents to code, right?
We have additional artifacts that we are producing.
Some of them are in natural language, right?
So how do we secure those?
We will talk about skills in a sec, right?
That's kind of different, right?
The traditional scanners don't really work with this.
I think the other one, very interesting one, that is not yet a challenge, but soon will be a challenge is, instead of kind of coding, I'm already prompting, right?
LLM is generating a...
code, that code might be insecure, pulling insecure dependencies or generating just vulnerabilities, right?
So that's happening today.
Maybe you have, you know, like your PR check code scanning, or maybe you have code scanning after the agent generates code, you run a code scan.
So that's solved.
But very soon what will happen is like you kind of move.
I believe that.
I mean, I don't know when this will happen, but I kind of firmly believe that the developer workflows are fundamentally changing.
So very soon you will need to, you know, keep up with your agent, right?
So now you shift the problem from reviewing code to I'm managing a team of agents.
And how do I really stay on top of what these agents are doing?
When I'm kind of vibe coding using my agents, I'm already struggling.
So what changes are they making to my application?
So these are the kind of new challenges from the developer point of view is, you know, like how does the security fit in with this new kind of developer workflow where developer is managing a team of agents instead of just, you know, reviewing every single line of code?
What does the security tool even look like in this new era?
And it's super interesting because when you look at just the sheer volume of code that's generated and created, of course, there are going to be similar coding.
issues because agents and LLMs have learned from our previous code and their training data.
And as a result, they'll essentially replicate a lot of what they have seen.
And the next thing is when you talk about a developer looking after a team of agents, that team of agents, we need to provide them guidance.
We need to provide them almost like an onboarding to allow them to build that code the way we want them to build that.
It's become well accepted now that the best form of that guidance, providing that guidance, is through context.
And let's talk a little bit about context, because obviously, probably I would say the two main ways of providing context is either you're writing into the agent's MD or into the court MD, for example.
Another way is to be able to say, look, I want to...
I want to create a skill, a piece of markdown that I can progressively disclose to my agent.
So I provide that skill that my agent knows, the name and description, for example.
When the agent has a task that it feels it needs that skill, it will load that skill in.
Now, these skills are designed to be reused.
So if I use a skill, I could share it to you or the rest of my organization, or I can put that on GitHub and other people can kind of like download that.
I've said a bunch whereby there's a million security threats already.
So let's talk a little bit about how the context that we're talking can, and let's start with skills, can actually contain further issues.
And perhaps we talk a little bit about your toxic skills report and research that you did earlier this year.
Yeah, yeah.
We did research this topic, I think, in March, so a while ago.
And I think it was about, at the same time, you know, OpenClaw was basically...
exploding, right?
So OpenClaw got released and then there was a huge kind of community motion to kind of contribute to that repository, including huge community motion to push skills to OpenClaw.
And that's where we kind of went and we analyzed, you know, like the skills that people pushed.
And of course, because this was such a big moment for the entire community and, you know, like one of the probably foundational moments of...
agentic development, right, like OpenClaw, we found a lot of problems there.
So this is mainly kind of for third-party skills that other developers are pushing and you want to go and reuse.
Which makes sense.
The use case is very clear.
I don't want to reinvent.
Same as open source, I don't want to reinvent the wheel.
If there is a skill that helps me to, or helps my agent to do front-end applications, or connect to Slack and get customer data, whatever that is, you publish, you want to reuse that.
But when we analyzed these skills on the OpenClaw repository, we found a lot of problems.
We found, I think, 76, I don't remember the exact number, skills that had purely malicious code, so malware.
So skills, as you probably know, folks, is partially the file, the MD file that gives instruction to the agent.
Skills can also contain code, right?
So kind of the first attack vector, if you're using third-party skills, is somebody just puts malware there.
And then basically your agents or your coding agents takes that and executes that malware, right?
So we found 70-odd instances of people putting malware there.
That's extremely hard to detect from a normal, like a regular tool, a traditional tool, because...
this code may not even run.
But it's influencing an agent to be able to build code that can run and actually do bad things.
Yeah, exactly, exactly.
So that's one.
The other one that kind of traditional tools don't detect is the kind of natural language part, right, of the skill.
So, you know, you can put prompt injection there, and then, you know, that gets into the agent context.
Agents are not very good at distinguishing between your instructor and context that is passed through third parties.
So this prompt injection attacks.
are very kind of common, like doable to kind of trick the agent, overtake the agent, and then basically do whatever you want, right?
Like it's pretty much like if you manage to overtake the agent, it's, you know, like you can exfiltrate credentials from the environment where the agent is running.
And then, you know, that's a very serious attack vector, right?
So we found a bunch of skills there as well that contain prompt injections.
And again, this is not something that a traditional security scanner would find, right?
Like you need to...
basically create a new scanner, a new tool to analyze natural language and have this kind of classifier that classifies whether natural language is a potential prompt injection, contains prompt injection, basically contains instructions to overtake the agent.
So we did that and we found a bunch of those as well.
And so obviously there's a ton of big organizations out there that want to adopt agentic flows and the usage of agents and they want to make sure that this guidance is provided to their skills, sorry, provided to their agents through skills and other context.
It's actually very similar.
You kind of like mentioned a connection there between how we think about skills and context and also libraries.
And yes, there is malicious...
content context and there's malicious libraries that can be shared in a very very similar way um what can a developer actually do to make sure that any skills that they download um you know is is first of all safe right um and how can an organization better adopt such technology right uh with with with that in with that governance in mind right so um One of the common things that people do is kind of host these skill registries, right?
And TESL is one of them.
I've heard of a skills registry.
Tell us about that.
What is a skills registry?
I saw two in the wild.
You probably know more, actually, so you can tell the folks as well.
But I've seen kind of two in the wild, right?
So one is just like more of a free-for-all open source community kind of skill registry where like everybody can just put skills and, you know, you make them searchable.
And then you can basically download these skills to your laptop.
I don't know.
I'm using a lot of skills.
Every time I'm doing something related to front-end, there is an entrepreneur.
pick front-end design skill, right?
I'm using that.
So people publish these skills.
An important thing there is, because they're third party, so they're untrusted, is to make sure that you have some sort of security scan running as the skill is already published and as part of the registry.
Because if you download the skill and you scan it after downloading, it might actually be game over, maybe not, but if this skill contains malware, I mean, you don't want to be downloading malware to your laptop.
So a very important kind of feature that we are helping Tesla with for your registry is kind of this skill scanning capability.
So as you're downloading, you can check.
Basically, the skill is verified by a security vendor, and it doesn't contain anything dangerous.
So that's kind of one type of registries.
is more of an internal enterprise.
So as I'm talking to enterprise customers, more and more of them are actually, as they are going through this agenting transformation, they are hosting their own kind of skill registries.
So I know a platform team would have like a paved path for developers to push stuff to production, right?
They want to kind of expose that paved path to the agent through some context.
So they create a skill, they push that skill and they ask developers to use that skill whenever agent is.
is pushing stuff to production, right?
So then that becomes like a common pattern for a lot of companies to operate and share skills across employees.
And there actually, I think security scanning is still useful before skills are being deployed.
But actually the attack vectors are slightly different, right?
Because it's no longer third party.
So somebody who you don't trust is your own developers pushing these skills.
So I think what you want to kind of ensure there is more around are developers doing something that they shouldn't be doing, right?
So an example that happened internally at SNCC, one developer wrote this skill that actually gave access to production credentials to the agents.
And this was not kind of paved path.
You know, these credentials were not kind of just in time, nicely injected, read-only, right?
They were overly permissive.
And when our security team saw the developers are using a skill like that, they freaked out, right, immediately, right?
So there you basically want to ensure some standards and make sure that the skills that you're publishing are, you know, like developers know what...
these skills are exposing their agents to, but also they are sane, right?
I think that's what I would say.
Yeah, so there's a lot to write down there.
And I think, why don't we start with kind of like, why don't we go through a little bit around the Tesla and Sneak partnership and kind of like break down some of the things that...
developers will want to do with such a registry and how that can help folks from a security point of view and a governance point of view.
So one of the things that was announced a number of months ago was the integration of sneak scans for context into the TESOL registry.
And what that means is people who add their context, their skills into the TESOL registry will automatically get a sneak scan on that skill.
And what that allows people, developers and folks to do to see is where potential security issues like the things you mentioned with with the with the prompt injection and so forth.
It provides people with.
and understanding that actually there could be a prompt injection here, even if there wasn't one that was meant.
For example, maybe it's pointing to some third-party site or doing a web search.
There could be the potential for a direct or indirect prompt injection there to exist through that.
So it's about giving people that insight into what exists.
One of the other key things that I think is potentially a security issue is a developer downloading a skill.
that is maybe absolutely fine, a new version becoming available or at least an update occurring to that skill.
And actually where there are no versions, you're actually pulling down an updated skill or the wrong version of the skill without even realizing there's a potential malicious issue there.
So I think associating scans with versions is super important as well.
So that's some of the things that we...
that we've added into TESL with skill versioning and then the ability to have those skills scanned by Snyk.
Let's talk a little bit about a secure by default agent stack and what that looks like.
What would you say from a developer's point of view, let's start with the developer and maybe we kind of like lean into other groups there.
From a developer's point of view, They have whatever agentic coding platform of their choice on their machine.
They want to use some skills.
What are some of the best practices that a developer should do today?
And how close are we to that secure by default?
It's an emerging field.
I don't think anybody yet has the answer to that.
So for skills specifically and kind of devs, I think it's extremely useful to, well, third-party skills, of course, like scan, right, before you use them.
But also when you're authoring your own skills, like running it through a security scanner just to tell you potentially what this skill is doing could be a useful feedback.
So just to give you an example, right, I was writing this skill to download data from Slack, right?
And then I run it through a security scanner before I pushed.
So I have kind of this pre-commit hook where I integrated our own security scanner.
And before I pushed to GitHub, I ran the security scanner and it tells me, hey, this Slack data that you're downloading might have prompt injection.
I'm like, okay, it's my Slack, right?
Maybe it's not a big attack vector, so I shouldn't worry.
But I did tell my agent, okay, hey, just put some basic kind of protections against prompt injection in the skill.
So that's kind of like you have...
this kind of feedback from a security scanner and then the agent, you kind of ask your agent to basically improve the skill based on that feedback.
I think that is super useful.
I think it's super useful also on the quality perspective.
I think this is something that you folks are working on, right?
Like I think the biggest problem I have as a developer when I write my own skills, like these skills initially are very personal, right?
So I have, it is actually like to write a personal skill for me to do a workflow, super easy, right?
I just talk to the agent, I do the workflow once, and then after the session, like I'm ending the session, I say, okay, hey, write a skill for me so we can repeat the same workflow, and I save the skill.
But then when I want to share that with other people, that is much more tricky because now I want this skill to generalize, right?
So now I'm kind of getting into the, how do I make a high quality skill that is shareable across my...
company, right?
And that's where I need help personally, right?
From folks like you to kind of help me basically get the skill in shape and make sure that the skill is in the right shape to share with my peers.
It generalizes.
So it's not specific to my workflow.
So I think these kind of workflows are still emerging, but that's what I'm doing personally with skills.
Love it.
And I'd love to, we've got about maybe five minutes or so left and then we'll jump into some questions.
So I'd love to hear if folks have questions online, let us know about any questions that you have either kind of like, you know, the sneak security scanning, the TESOL registry or a combination of the two.
And we'll cover that in just a few minutes.
But I think there's a couple of really interesting things that you kind of like mentioned.
One is the almost like the how good is my skill, which is all about evals.
And I think those evals will.
change depending on if I'm using something personally or we add other scenarios in for the wider usage.
And it's absolutely key that we do nail down those security issues before sharing.
One other thing is, as we do share that out, and we'll kind of talk one step higher now instead of the developer, maybe thinking a little bit about more governance.
It's about almost identifying if I was to share this to my team, how do I protect my entire team for downloading less secure context and I think this is where you can potentially use TESOL with Sneak here to run or at least on an installation of context you can use the Sneak score as a threshold to give developers guidance on whether they should or shouldn't install this skill right 100 um i think we have to do more work on this next side here because like initially when we when we did skills we assumed you know these third party skills and the scanner was kind of more concerned about around malicious third parties are publishing stuff online how do we protect people from not downloading malware or prompt injection etc etc i think Again, I think I said that before, but it is slightly different kind of set of things that you want to check if you want to give developer feedback.
on security of their own skills or give the team feedback on security of the skill that they are downloading so they know what they are exposing their agents to, right?
So they're, for example, not adding some lethal trifecta, you know, like style kind of exposure to the agent where the agent can potentially get prompt injected and exfiltrate data.
So I think that's kind of like a good, you know, like stuff that we'll focus on in the future very soon.
And hopefully also as a continuation of this partnership is how do we make it useful for developers when they write skills to understand that they are doing the right things from the security perspective, right?
So the kind of feedback loop to developers.
And again, like as an example, you know, like the security incident that we had ourselves, you know, like if you're a developer and you are...
Hard coding secrets, of course, that's bad, but also like mishandling secrets.
And, you know, like basically the agent is told to pass secrets in plain text.
That's an example, right?
If your skill can perform a destructive action on some production environment, right?
So kind of this feedback where you basically understand.
potential consequences of the skill that you are developing yourself is kind of next focus for us for sure and a very exciting kind of opportunity to also collaborate with you folks.
Yeah, absolutely.
So we're going to go to...
Questions in just a second.
I want to ask, though, there's a new product that Snyk is going to be GA-ing in a few days, right?
In a few days, yeah.
Can you tell us a little bit about that?
Can you give us a Snyk preview?
Right.
So our next focus in the kind of AI agent security incubation lab, kind of under the umbrella of Evo.
So Evo is our kind of product umbrella for the next generation of Snyk products.
is what we call a coding agent security product that is aimed to secure coding agents.
So the problem that we are trying to solve is enterprises are rolling out these coding agents.
And sometimes, you know, the...
security team is blocking the rollout, right?
So the platform team is coming to us and saying like, hey, I cannot roll out these coding agents because the CISO said that there's no way without any security guarantees, right?
On the other hand, sometimes, you know, the rollout happened and they're trying to play catch up and calling us over the weekend and saying like, hey, you know, like the agents got rolled out, you know, and security was not in the loop, right?
So what we're trying to really enable is kind of empower these security teams to secure these coding agents at scale.
without impacting agent productivity.
So that's also an important aspect for us, because you can just block all network traffic, right, and call it a day.
But then, like, basically the agent becomes useless, right?
So the three things very quickly that we are releasing here is supply chain security for the agent.
So ability for you to govern, see what skills and MCP servers your developers are using at scales across all of your endpoints and machines, et cetera, and kind of perform risk assessment of these skills in MCP servers, and then create policies around.
MCP server shouldn't be using personal access tokens, et cetera, et cetera.
So that's kind of on the supply chain, govern agentic supply chain, govern the output of the agent.
So the kind of our core business, you know, code security, but now kind of integrated within the agentic loop where agent is generating code or downloading an open source library, just make sure that it's secure, right?
The code that is generating is secure and fix it.
And then the third one that we're going to release in open preview, but hopefully kind of GA in Q3, is...
And guardrailing the agent behavior.
So that one is probably the most kind of right now urgent for a lot of security teams.
How do I actually make sure that the agent is not leaking credentials?
How do I make sure that the agent is not misbehaving, not having prompt injections, not, you know, leaking credentials, et cetera, right?
So those three are kind of the things that we are working on and releasing.
Very excited about that.
Awesome.
Awesome.
Let's look through some of the questions.
We have one question in from YouTube.
With regards to TESOL registry, if you use it as a private workspace, you don't get the same UI experience as the main pages with score, tile, sneak score, etc.
So with the TESOL registry, you will get the quality score, the impact score, and the sneak score for both public or public.
or private plugins.
If it's a local plugin, I believe you won't get the Sneaks call, so you need it published to the Tesco registry.
But if it's private or public, you should still get that.
The difference for those who haven't heard of our workspaces, a workspace is essentially a space in which you can upload your plugins and skills to, and you can mark that as private or public.
If it's public, anyone.
can access that on the internet.
If it's private, you will need a Tesla account that has access to that workspace in order to see that plugin.
But you should see all sneak score and tile scores and things like that.
Additionally, regards to utilizing Tesla plugins within different agents, how does your plugin format fit into Codex, for example?
So if we was to think about agents, and this is an interesting question because agents, of course, all have their different formats and things like that.
The way you would install a plugin, if you were comfortable with its security posture and the sneak scan and things like that, you would install that plugin.
And that plugin will be installed into the .TESOL folder of your project.
You will also have a whole ton of different .folders.
That will be a .clawed, a .codex, a .gemini, etc., etc.
Those will have indirect links to the .TESOL folder.
And as a result, any agent that you load from that or that you run from that.
from that project will automatically have all of those skills accessible.
Do you find much difference between the different agents from a security point of view or is it pretty much more in the skills itself, I suppose?
It's going to be the wording I suspect.
I think...
not really.
The only difference is that some of them support hooks, some of them don't support hooks, right?
But kind of Codex and Cloud Code and Cursor are like the three that we focus on and kind of have the widest adoption.
And between these three, like it's very similar.
But it's important to have tools that work across all of them, like yours, right?
So you don't need to kind of go to the path of installing for like the same thing for each agent, right?
So project level skills, a really good idea, yeah.
Yeah, awesome.
Awesome, awesome.
We only have 30 seconds, minute left.
Why don't we wrap up by asking one final question.
Let's ask, what one piece of advice would you give today to an agentic developer to improve their security posture, particularly when it comes to a context point of view, I suspect?
One piece of advice I would give.
Don't go YOLO.
I think, I don't know, that's the one that comes to my mind.
I think a lot of devs are, you know, like just, they are...
kind of playing with this technology, right?
It's a new technology and you want to kind of understand how it works and it's very kind of, it's very simple to just, you know, auto-approve all actions, just download skills, just like, don't do it, right?
Like, don't go YOLO, like, just think through like what you're actually doing, like the same, like attackers are...
very interested in this field, right?
These attacks on coding agent and deaf environments are not theoretical.
They are happening in the wild, right?
So use sandboxing.
Don't auto-approve and check your skills and use kind of trusted registries like TESL.
Like don't go yellow is probably my simple.
It's all about building that trust and automating when you have that trust versus...
Right.
So the tools are emerging, right?
So the tools will help you out.
We'll have...
you kind of covered, right?
Like Tesla, SNCC and other tools in this space.
But very often, like, the tools are not there yet, right?
Like, it's not easy, for example, to run as, like, a fully sandboxed agent today, right?
So just make sure that you don't go fully YOLO on everything you do and you don't fully kind of just think, like, don't outsource thinking to your agent.
Just think for yourself what you're doing, right?
And use the tools as much as possible.
Amazing.
Krish, thank you very much.
It's been a pleasure to chat.
And thank you all for listening.
Thank you for the questions.
If you wanted to learn more about the integration between TESL and Snyk, do go to tesl.io forward slash registry.
And from there, you'll be able to see a whole ton of skills that automatically have Snyk running on.
And you'll be able to see the security guidelines and instructions as to what is it about each skill, which is potentially causing complications.
Do also go to Snyk.io and check out their scanners there as well.
And also, stay tuned in the next few days to see that GA product release.
Thank you.
Thank you very much.
And bye for now.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community.
And we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more and I hope to see you there.