# Securing Agentic Development: Context Supply Chain Risks

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

## Transcript

Working with agents and LLMs introduces some new dimensions on security that we wouldn't normally think about.
Text becomes something that can be vulnerable, can have some executable intent.
A couple years ago, you would never worry about the security of a markdown document, a combination of some access to privileged information or some private data, some exposure to some untrusted content, maybe from the outside world, and the ability to communicate externally.
Most agents by default are going to have all of these three things, and that is where you're one.
prompt injection away from, let's say, a bad time.
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 Pajani, 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.
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.
Hello, and welcome to another episode of the AI Native Dev.
And on today's show, we're going to be tackling the big questions of how organizations should be thinking about security in agentic development today.
Not just for the security issues that we already know about that software development has taught us over the years, but thinking about some of the new security risks that agentic development brings today.
Joining me on today's show, we have Joe Holcroft, a member of technical staff and team lead at TESOL.
Welcome, Joe.
Thanks for having me back.
Absolutely.
And it is having you back because you joined, gosh, probably a good six months, nine months ago.
We did a session all about how we use different agentics.
tools.
And we actually swapped applications and played with that.
It was good fun.
But Joe, of course, you are a member of technical staff, a team lead here at TESOL, previously worked at Snyk.
Tell us a little bit about that.
True, yeah.
Worked at Snyk for three years, sort of during that hyper growth period, mostly supporting the open source products.
Awesome.
And in between those two, you're also a fractional CTO and did a number of different mentoring gigs.
Really interesting to hear your point of view around security and agent development from all of those experiences.
And very recently, you actually worked directly on the Snyk and Tesla integration, adding security advisories and reports into the Tesla registry for skills and context.
So some super cool stuff there.
Yeah, it was fun to get to work with some old friends.
Some old memories, absolutely.
So why don't we jump in and talk about how the attack surface has changed and what we need to be concerned with from an agenda development point of view.
For sure.
I mean, lots to talk about here, but I think one of the best articulations I've ever heard of this is in Simon Willison's.
Lethal Trifecta, where he talks about the combination of three characteristics that all agents pretty much have, which is some access to privileged information or some private data.
some exposure to some untrusted content, maybe from the outside world, and the ability to communicate externally.
And most agents by default are going to have all of these three things, and that is like a dangerous situation.
So you think about a coding agent that you're working with on your machine in a repository that has access to the code and secrets that you have on your machine, which is your private data.
They're pulling in dependencies, documentation, issues, search results from the outside world.
That's your untrusted content.
And they can run shell commands and hit HTTP endpoints and CLI commands.
And that's your communicating with the outside world.
And really, those combination of three things is sort of where you're one prompt injection away from, let's say, a bad time.
Yeah, yeah.
And it's interesting, actually, until you said prompt injection there, a lot of those things are fairly consistent with, you know, some of the issues we have now, with the exception that, you know, you have an agent doing it this time around.
So perhaps when we think about, you know, what we need to do to make sure we have solid code quality, solid, you know, vulnerability management, those types of things, you know, what is it we need to do to our existing processes to cater for these types of issues?
There's a bunch of things you need to do, but I think maybe the first thing to consider is that a lot of the same considerations that you might have for software that's written by humans is the same kind of thing that you need to care about with agents.
I think if it's like a force multiplier, right, so all of the same hygiene that you'd be doing, making sure you have your SEA scanning and your SAS scanning and your processes in the right place in terms of security, all of that stuff.
becomes more important, not less important, as agents are working on your code, because, you know, you can consider them somebody that you might trust less than you otherwise would.
Like, for example, a contractor that you might get in, someone who's going to be writing a lot of code for you, they'll kind of do whatever they're told.
Maybe they have a certain amount of access to your internal systems, but there's not a huge amount of oversight.
So you can kind of think of your agents in that way.
There are a few ways in which working with agents and LLMs introduces some new kind of dimensions on security that we don't normally think about.
Most interesting one I think is text becomes something that can be vulnerable, it can have some executable intent, right?
A couple of years ago, you would never worry about the security of a markdown document anywhere in your organization.
And today, that's actually very important.
A markdown file that you're giving to an agent could encode some vulnerability to instruct the agent to go and do something malicious or just unsafe.
And that's just a completely novel situation.
And it's interesting that a lot of the time we find ourselves, we get caught, catch ourselves talking about how agents, add security issues into the space.
But how reliable are agents, not just finding issues, but even being able to start coding in a reliable way?
We've heard of things like Mythos coming out.
Can we rely upon, and do you rely upon agents to identify issues and help you, guide you into making sure you develop more securely?
I think you can, for sure.
I mean...
Agents are always kind of backwards looking.
So there's like a little bit of a lag before things are going to catch up with new types of attack vectors and new vulnerabilities.
But absolutely, I mean, and I think it's kind of the only effective defense that we have against the kind of vulnerabilities that you can introduce into text documents and markdown files these days is to have another LLM judge that content and see if it kind of seems risky because static analysis is not going to cut it here.
There's many ways you can phrase something to kind of.
not even trick an agent, but encourage an agent to do something that maybe isn't what the consumer is intending.
So I guess the classic question is, do AI coding tools make developers more or less likely to ship vulnerabilities these days?
Yeah, I think it really depends.
So of course, agents are allowing you to be a lot more productive and ship a lot more features and a lot more code.
The more code you write, the more chances you have of introducing vulnerabilities.
but also they're pretty good at like following patterns as well so um you know if you have good well-established patterns in your code base that make it quite difficult for you to be vulnerable to things like sql injection for example then they're going to tend to follow those patterns um but then on the other hand if you haven't got well-established patterns um or you're you know you're not managing the context with your agent well to sort of encourage them to do things in the way that you need them to be done.
Then they're going to fall back on training data.
And the training data, obviously, is like a wealth of insecure open source software that is out there in the world today.
Yeah.
And going back to what you mentioned previously about text being vulnerable, that's really interesting because there are very few patterns.
It kind of reminds me a little bit like WAF, like when you think about something that whereby the input can change very, very slightly and go round a rule that is a pre-existing rule.
Essentially, you know, what happens when text can become a vulnerability, things can be phrased in a slightly different way or things can be approached from a different angle.
You can't have static tests for every single thing.
So you very often do rely on a kind of LLM as a judge assessing whether certain text is potentially dangerous or not.
So when you think about skills, a skills MD is essentially a bunch of text and that text describes and guides an agent into doing something a particular way.
In order to be able to identify whether that's malicious or not, one of the things that was added to the Tesla registry recently by yourself and the team is that ability to scan the skills with Snyk and get those results via Tesla.
Tell us a little bit about that.
Yeah, so we've introduced Snyk's agent scan tooling into the product.
So everything that's published to the registry now goes through this skill scan.
And also we're indexing a bunch of skills sort of out there on GitHub and running security scans for those as well.
So if you're trying to install these things with TESOL, then we're going to warn you if something has something that we think might be...
malicious or maybe, you know, malintent.
The other interesting angle on this is that a lot of the potential security risks here are kind of contextual.
So, you know, a skill contacting the outside world or using some API may not necessarily be a bad thing.
You know, TESOL has a skill that is using the TESOL API.
That seems fair enough.
It's important that the scanner has that kind of context, but a lot of the time really what you need to do is surface that to the consumer, to the user, right?
Like, of course, many of the skills I'm going to be using are contacting the outside world in some way, but am I okay with this skill using this particular API or this particular CLI command?
And, you know, is that appropriate with what the skill is trying to do?
So we're sort of working on evolving the user experience a little more to not just flag up things that are like obviously malicious packages, because a lot of the cases is a little more subtle than that, that perhaps this skill is doing a little bit more than you might be comfortable with.
If you just skimmed the skill MD, you might not realize that it's also going and hitting GitHub and posting some of your personal information there, for example.
And a lot of the issues that we've talked about already, some of which people will be very familiar with.
Others are completely new and it's just a growth in the attack vector that we have or attack surface rather.
One of the styles is something like a supply chain dependency risk.
Sometimes it can be, you can look at that from the libraries that we actually import.
Other times it's supply chain through the context.
Let's talk about what's already existing.
Let's talk about libraries first and then we'll jump on to the other.
So when we think about libraries and AI agents using libraries to assist with its abstraction coding, what should we be worried about when an AI is trying to, or rather an agent is trying to choose a library when it wants to, to perform a certain task?
There's a number of things to think about here.
And the first one, as with many of these things, is just like velocity.
More code means more packages are getting added, which is harder to review.
And maybe you're going to be less detailed with a review that you're doing.
One of the other things to keep in mind is that, you know, a lot of the time, an agent is just going to hallucinate a package name.
It's just going to guess at something and see if it's there and install it.
And there's a...
a beautiful new phrase that's popped up called slop squatting to sort of describe this attack vector where people can upload malicious packages on package names that they think an LLM is likely to pick for some kind of scenario to then get that into your supply chain, which is an interesting one.
And the other thing to keep in mind is that agents these days at least, are not really looking at packages in the same way that a human might.
I think if I'm choosing an open source package, I'm not just looking for the first search result that matches the kind of tasks that I'm trying to do.
I'm also looking at them for some social proof.
How many stars do they have?
Are they well established?
Have they been around a long time?
Are they sponsored by a company or is it an individual?
All of these kind of things that an agent typically isn't looking at.
It will maybe pick something that's well represented in the training data or just something that kind of matches its search of what it's trying to do well.
So there are a few new things to consider here.
There will be.
A phrase that we use in today's podcast, which is going to sound rude, but weirdly, slop squatting is not it.
We'll move on to that.
We'll move on to that.
Let's go on to thinking about the supply chain of context now.
And this is interesting because, you know, essentially, when we look at the supply chain of dependencies, it's about us being comfortable trusting the third party libraries, content code that we're pulling into our organization, to our application, our project.
When we think about the same thing, but for context, this is more of a development time thought process of we're not shipping this necessarily, but we're using this context to guide our agent to write appropriate code.
First of all, how important is it that we know who these people are, how many skills we're using in our organization?
How important is that given it's a development time thing?
I think it's hugely important.
And it's an interesting topic for me because I think it's almost like we've got so excited with the capabilities that we have now with agents and skills that we've kind of forgotten about, you know, 10, 20 years of software engineering and what we've learned about software supply chain and open source.
And, you know, people are freely pulling in skills from random GitHub repos, pulling in main.
updating that you know frequently without really having any oversight um this is not typically how we deal with um third-party open source software anymore you know we're using um properly version software you know a lot of the time you're looking at only pulling in things of a certain age because you know you want to protect against these kind of supply chain attacks that we're seeing more and more of these days um you're interested in some kind of like provenance where this is actually coming from um a lot of that has kind of gone out the window and this is really something that we care about a lot at TESOL and that we're investing a lot of energy into building a package, a registry for package context in the same way that you have many registries for open source software that kind of just bring a lot of these same things.
It's not like hugely novel new approaches, it's the same kind of approach to the new the new kind of context, the new material, I suppose.
So it's time to drop the C-bomb.
Pause.
First time on the podcast.
First time on the podcast.
We've heard about the S-bomb, the software bill of materials.
Do we need a C-bomb, a context bill of materials, so that we can identify for this project, for this development scope, we know what context we are using, where we're pulling it in from, versioned, et cetera, et cetera.
Is that something you feel your teams could provide value from?
Absolutely.
Yeah.
And another thing we're looking at at Tesla, and I think it's an important aspect that's missing at the moment.
And again, potentially more complicated than it is with things like SBOMs, for example.
You may also need to cover context that is just running on a developer's machine globally.
There's sort of different scopes, right, that you can kind of install and get something into an agent's context.
So, OK, I haven't got anything that looks scary in my projects.
Maybe I'm even checking that in a CI action using TESL CLI.
But what about what developers are installing on their machines?
And how can I restrict that?
Is another layer of complexity here that I think we haven't even started to touch the sides on.
Yeah, I guess the auditing or the gating of context in a similar way that we would think about dependencies.
it starts to raise the questions of, okay, at what stage do we do that in terms of do you want developers to want to be creative, want to build fast and have a gating station a little bit later?
There's a whole bunch of interesting things that could be happening.
Do you have opinions on that now?
Or is this something that you feel we as an organization are evolving through?
I think it depends on your use case and sort of how restrictive or kind of liberal you want to be.
But again, a lot of the just the the fundamental tools are missing right now.
So maybe talk a little bit about Tesla CLI, which is going to put a manifest in your project.
So this is something that you can go and do some checks in your CI if you want.
What are the different pieces of context that we have installed?
What's their security rating?
Do we trust them?
Are they in some allow list that I might have?
Without the manifest, you can't do any of those things.
So you can't even really have the opinion about how much you want to secure your projects.
Yeah, I actually built a little tool that I showed at Demo Time a while back that looks at your Tesla JSON, looks at all of the pieces of context, the skills that you're using.
And based on the results from Snyk via the Tesla API, we kind of like pull together this nice, almost like a security report, a posture, security posture style report of...
you know, for your application, for your project, this is what, you know, this is where the issues exist.
And I think people are going to be asked for that more and more in terms of, you know, don't just freely pick whatever you want.
Let's actually have a look at what we're using now.
What about other things like, you know, whether it's secrets and credentials, for example, some more core security style concerns?
Is this also an issue for agentic development?
Are there new things that we should be wary of when thinking about how to hide those credentials?
Yeah, absolutely.
I think this is a more fiddly part of the equation here.
The agent has amazing access to privileged information on your machine.
So even if you think about your environment variable file, a very common way to be working.
can you and do you and how do you prevent the agent from reading that file?
Because if it can read that file, you can assume that that is going to end up somewhere that you don't want, right?
Like it also has the ability to post information out on the internet.
And even just the fact that that might be read in means that it's in logs at various places of your stack and probably with the model providers as well.
And if it can read files, why couldn't it read that file?
So, you know, maybe you want to start looking at different mechanisms where you have, you know, like a secret broker and you're issuing more like just in time credentials with like short, short lived TTLs so that, you know, some code does get out there.
You don't need to worry about it because it's only valid for 15 minutes so much.
But this is, yeah, again, it's kind of typical security hygiene, but it's at a new level of abstraction that, is much trickier to deal with because it's running on your machine as if it's a developer that you would trust.
Yeah, and I think that's a key phrase there.
It's running the machine like a developer.
And I think there was, I was reading a Reddit thread the other day where there were people who were using an agent and they'd essentially said, I think it was clawed code, and they said, look, you can't, through the settings, you don't have access to the .env file as a file read.
And what Claude Code did was it wrote a bash script that essentially read from the .em file.
And it's not trying to circumvent security per se.
It's got a problem that it's trying to solve and it's trying to work out how, given the tools it has, it can perform that.
And a lot of people were replying saying, look, what you essentially want to do is run it as a particular user that doesn't have actual access to this file through.
the operating system access.
And it's really about trying to find that mechanism, a good mechanism where you can't gain access to that.
So this kind of like leans into the principle of least privilege, which, you know, everyone's all familiar with from a normal coding point of view.
From an agentic coding point of view, what are the types of guardrails or controls we need to put in place to achieve that in an agentic software development environment?
Yeah, I mean, there's some good hygiene things worth looking at.
You know, sandboxing your agent locally is going to reduce kind of blast radius of some things that can go on on your machine.
And then really, you know, you're not going to get a lot of success.
telling the agent not to do certain things because, you know, it will find a way around as you had your example a minute ago, which is a great example.
So really you need to look at like, how can you sort of strangle access at the right level?
So maybe that's some sort of network egress controls, you know, which domains can you be talking to?
capability-based permissions.
So, you know, which repos can you work with?
How are you setting up your Git remotes?
What kind of pushing can you do?
What actions do you have running on branches where agents can push to?
And then thinking about things that are dangerous and putting in approval gates that are not just like...
you know, please stop and ask the human.
It's like, it's physically impossible to do that without some kind of approval that then generates a hash that then you can kind of push it through.
But really, it's an interesting, it's an interesting situation because there isn't really like an escalation of privilege here, you know, like you're running an agent on a developer's machine.
Typically, that agent has the same kinds of permissions that the developer does.
And typically, you're not going to be able to tell the difference between the developer or the developer plus the agent hitting the various different, you know, services that they might be using.
Because essentially, it's performing actions on your behalf with your credentials.
Yeah, 100%.
How do we avoid because like, you know, we can always add more and more security controls in security guardrails.
How do we avoid securing ourselves into bankruptcy where the cost of over securing or securing ourselves actually starts having an impact on our company's time pressures of hitting that deadline, speed of delivery, those types of things.
Yeah, it's an uncomfortable conversation because I think the first thing to accept is that this is a nascent field.
We're still figuring things out.
And if you're going to be using agents, you kind of need to accept that.
there's going to be perhaps some breach at some point.
So really, maybe what you need to do is be prepared and figure out what your risk tolerance is and where your risk tolerance is.
So I sometimes like to think about this, about how reversible something is.
So if something is kind of like low risk and reversible, those are the kind of tasks that you might want to be giving to an agent autonomously, working in a branch, you know.
not a huge deal.
Pushing something up to the Git remote, probably not a huge deal.
Do you want to give the agent control to like push directly to production?
I probably wouldn't.
You know, that's a lot less reversible than, you know, working within a feature branch, for example.
Yeah, yeah.
And offline, we were talking a little bit about how you kind of consider an agent to effectively be similar to an employee where you almost, you know, you trust them as much as you do.
Maybe it's more of a junior employee.
Maybe it's more of a, you know, someone who's a contractor or something like that.
When thinking about where you draw the line on how much autonomy an agent has, is it similar to the kind of thought processes you go through if someone's just joining the team and you want to, you want them to be, you know, autonomous enough, but equally validating what they're doing?
Yeah.
Again, I think about it as like a sliding scale with the risk.
So I can maybe talk about an example that I have where, you know, mostly my agent is working directly on code and sort of pushing things from my machine autonomously.
But even when it comes to, say, PR reviews, if I'm getting some feedback on a PR, either from, you know, a colleague or from, you know, one of the AI PR review systems that we use.
I want to be in the loop there.
But it's also like kind of low risk.
Like if the agent posts a comment that makes me look silly, that's not ideal at work.
But I'm not like breaking production.
So there I've used a skill where I've kind of asked the agent to analyze the comments and come up with a plan and talk to me and wait for my approval a couple times kind of before pushing something through.
Whereas.
Again, I can use the pushing to production.
It just doesn't have that ability.
So I'm not relying on a skill to stop it from doing that.
But presumably it can get so far before there needs to be some human intervention to check or to have some ability to say, yeah, I agree with what you've done.
I can now push to production or I will allow you to push to production or something like that.
I guess, what do those checkpoints look like for irreversible actions?
Yeah.
I mean, personally, I just haven't implemented those kinds of checkpoints for high danger, irreversible actions, because how do you trust that the agent is going to follow that instruction if the checkpoint is...
So the checkpoints are autonomous.
The checkpoints are part of the autonomous system.
Yeah.
So like in my PR review example, it's like part of the skill.
So I'll invoke the skill when I want to do a PR review.
And in the skill, I say, you know, make sure you check with me and blah, blah, blah, blah, blah.
That's kind of fairly low risk.
If you wanted to have a checkpoint for something like push to production, actually systematically making it so the agent can't push to production until there's human confirmation.
Like how do you build that system?
Yeah.
Yeah.
Like without just saying, please ask for permission before running this scary command that actually you can always run.
You know, it's kind of about trust.
Like how much do you trust the agent?
You probably shouldn't with those kind of things.
Yeah.
And when we do think about that human oversight, how good are we as humans at, I guess, you know, we know we have always been pretty bad at reading other people's code naturally anyway.
As the amount increases, how good are we going to be as humans to actually...
monitor what agents are doing and actually say, yes, yes, yes, this is fine, this is fine, versus actually making sure we do go into depth with almost like the stringent methodologies of code reviews and things like that.
Do we actually need to lean more onto, you know, testing and deterministic code reviews as well as AI code reviews to essentially manage and maintain that, yes, this code is correct because...
I can see all this has been tested and passed, or is there a lot more manual intervention that humans need to make?
Yeah, I mean, this is the other big thing that changes, not just in security, but like in general software engineering is the sort of asymmetric velocity.
Agents can do like a ton of things.
You can invoke a bunch of them to do a lot.
And we can't sort of clone ourselves in the same way.
So how do you avoid kind of becoming the bottleneck?
And I think same principles kind of apply every point.
You know, what do you care about?
Maybe, you know, a certain point you really care that like the code style guide is being followed and PR reviews might be more focused around that.
I don't think anybody's particularly interested so much in that anymore.
The parts that you are interested, you're going to make sure that's like automated and linted.
And really, like if you have limited attention, where are you going to focus it now?
So A.
selecting the PRs that you're going to have more oversight over than others.
You know, something's touching the auth service probably needs some human eyes, some detailed human eyes.
You know, if something kind of seems like it's dealing with some new customer data or something, you might want to be paying more attention there.
And then when you're actually doing the review, what kind of things can you lean on to help you?
Like, can you use another LLM as a judge on this to kind of give you a bit of a report that you can then look at rather than having to crawl through all the code from scratch and yeah which things can you kind of automate away so that you can spend more time focusing on the higher risk areas like where can you leverage your time really I think is the thing to be thinking about all kind of points of the stack there because we will always be the bottleneck we're kind of just moving where in the development process that bottleneck is and if something Bad did go through interproduction.
How does the auditability and the logging, how is that affected by agentic methods?
Because as you kind of mentioned, you know, There could be multiple actors here.
It could be the individual, me or you, that's working with a group of agents.
There could be a number of different models, a number of different agents that we're working with.
How do we actually identify where these types of issues come through when there's so much behind potentially a single user commit?
Yeah, it's an interesting one.
I think, you know...
All of what we've done in the past still counts.
You know, the traceability of like a commit through CD into production and then your telemetry on top of that.
But there's kind of a new dimension that also becomes important now, which is like what actually happened on the developer's machine?
And, you know, how did you arrive at the code that got committed?
Because that's going to help you understand how can you avoid this kind of thing from happening again?
So being able to cross-reference, not only the commit to the issue but the commit to the session that was had with the agent and maybe what skills were invoked and what context was in the context window is going to help you understand yeah how do we actually get to this point and then also you know looking at things that we already have like the PR reviews and like how did how did this not get caught by your say agentic PR review system so all the same things that we had before are important and again just to go back to the supply chain thing, understand it, like having some kind of manifest and some kind of versioning on those skills is helpful here as well because, okay, you had the developer's machine had this particular skill and, oh, I wonder why it didn't work.
What version was it at?
Where was it installed?
And I think at the minute, we're not very well equipped to answer these questions.
Yeah.
And it'd be interesting when we can and we can determine it came from this place or that place.
When we think about accountability, And who's accountable for the software if it's got a bug in it?
There's this wonderful episode of The Office, the UK Office, where Gareth, he's on the phone to a calculator company.
And he said, I built this quote out for one of our clients.
And while I've eliminated all other aspects, I believe it's down to the calculator.
And so when something does go wrong, You know, what do we need to look at?
Is it the individual who is running the agent?
Is it the team that, you know, together are allowing code to go into production?
Is it the agent itself?
What typically is the accountable piece that we need to work through?
I mean, I don't know how far blaming the agent gets you.
It might make you feel a bit better.
You're absolutely right.
Yeah, exactly.
You know, it's a tool, right?
So, and it's there to sort of serve us.
So I think, you know, really it's the team are accountable and like the processes that got you there.
I'm sure there's no like malintent normally with these kind of things.
But how did this kind of thing happen?
How did we allow it to happen?
Are the interesting questions there, I think.
But yeah, I don't think you'll get very far with blaming an agent or even, you know, the frontier model companies in this kind of thing.
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.
When we think about humans and the cultural changes that we need to make, obviously at TESOL here, we're hyper into AI and we're very AI first with an AI native, the way we are building software.
But is it healthy still to have a level of skepticism, a healthy skepticism when using agents to build code versus having an overagency to models and agents and almost having too much trust?
Where's the right balance there where we're not all in on AI?
Yeah, I mean, it's so subjective, isn't it?
I think it really depends on your use case and your risk tolerance.
You know, a big investment bank is probably going to be quite different to a seed stage startup in kind of the things that they're optimizing for and also their risk tolerance.
I think some of the things that would apply well to everybody is like thinking about what is AI governance.
um you know strategy um and who owns it maybe at whatever size even if it's we don't really have one and it's the ceo owns it um you know putting a little bit of thought into that um but larger organizations uh that we're talking to uh you know interested in all kinds of like um governance tooling here um you know a lot of the same um hygiene things that you would normally have, you know, your branch protection, your SAST, your SCA, thinking about your logging and your retention of those logs, and maybe rethinking how you do secrets.
I think this one thing that agents do change is your approach to secrets may have served you well for humans, and that might start to fall apart a little with agents.
But then in terms of the actual agency you're using, you know, which agents are okay to use.
And then it's really the context piece, which is, again, what we're focusing on at TESL, like what context is allowed to be pulled in, which things are pushed to developers so they can't forget about or they can't be missing.
So would you say it's almost like skepticism through, you know, having real visibility and transparency to the issues that each of these things occur?
So like when you say...
you know, what the models do have, don't have access to.
It's about seeing how they trip over, seeing how they fall over and recognizing, ah, this agent's not great at this and understanding that kind of like skepticism through transparency.
Yeah, I suppose that.
But again, you know, depending on your risk tolerance, you might want to start with a much more sort of lockdown environment and see how things work and sort of slowly add abilities.
But, you know, I think you're going to get the fastest results by, moving fast and breaking things.
It's just maybe thinking about what things you're breaking up front.
If you're moving fast and breaking production, that might not be so good.
If you're moving fast and breaking your development process, that's probably interesting if you're trying to move quickly.
So let's roll up.
Let's wrap up with two more questions.
First of all, what would you say is the most underrated security risk that you see organizations take adopting agentic development tools?
Again, I probably sound like a broken record at this point, but I do think it's the context supply chain piece.
I think it's really interesting how we're just installing context into our agents in the same way that you might just pull something in from a repo pre-NPM or various package manager days.
Folks are finding all kinds of skills on developer machines and in their repos that have come from all over the place.
Maybe they don't even necessarily know where they've come from or who's authored them.
They haven't gone through any kind of scanning.
There's no companies that have their artifactory set up, but you can still just put in any skill into any repo or into your machine.
So I really think it's the whole supply chain of context.
How do you get that into your projects?
How do you get that into your machines?
And how can an organization have more oversight and more control over that and how you can have more trust?
in those pieces.
I think it's a governance issue that people are calling out for here.
This is one of the reasons why Tesla are really doubling down on that.
And a wrap-up question then, if you could give one piece of security advice to a CTO who's their company have just decided to go all in on AI native development, what would that be?
Yeah, I mean, so many detailed things, but I guess just at a high level to think of the agent as like a very competent, fluent, but...
somewhat inexperienced contractor or inexperienced in your context, how would you work with those kind of folks?
You'd probably bring them in, you'd give them a bunch of code to write, you'd give them a bunch of projects to work on.
You'd probably be thoughtful about which production systems you give them access to.
You can work in dev, but we're not going to let you push or access prod directly.
You probably would make sure at least their first couple PRs are getting some proper good human review.
you check their references, you check their work a little bit.
So I think that I find that framing kind of helpful to think about things in a way where, you know, you're not doubling down so hard that you're tying shoelaces together, but, you know, you're also being thoughtful about, you know.
There is some risk here.
So perhaps dress up a mannequin in the office, call them Claude, and pretend that they're quite a junior, less experienced, maybe a contractor.
And every time you think about giving an agent something that's potentially damaging, potentially irreversible, would you give it to that mannequin, that more inexperienced dev in the room?
Probably not.
Think about that twice when giving to an agent.
Yeah, for sure.
Yeah, amazing.
Joe, it's been a pleasure again.
And thank you very much for all the time today.
It's been great.
Thanks for having me.
Awesome.
Thanks very much for joining us on today's episode.
Really hope you enjoyed it and tune in to the next one.
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 Tesla offices in central London.
Visit tesl.io forward slash community to learn more, and I hope to see you there.