Securing Agentic Coding at Scale

0:00 Yeah, thank you all for for joining us. My name is Nate Umoff. I am an AI deployment manager here at Cursor. And really what that means is I work with some of our enterprise customers and just make sure that they are getting the most out of the tool and help them deploy Cursor at scale. And then I have Kevin from our product team. Kevin, if you want to give a quick intro as well.

0:21 >> Hey everybody, I'm Kevin over on the Cursor product team. really thinking about the ways in which uh agentic coding can work for large teams at scale uh working with some of the biggest enterprises in the world adopting AI coding. >> Sweet. And just as kind of a a sort of a housekeeping and and setup thing here, uh if you guys do have questions as we're going through the webinar, feel free to just throw them in that little Q&A button down on the sort of toolbar of of Zoom. that's going to be an easier

0:53 way for us to answer questions rather than if you just throw it into the the Zoom chat. So, feel free to put questions in there and then we'll kind of answer some just over chat and then some we'll we'll definitely make sure to kind of address as uh a group live. So, Kevin, are you able to see the slides that I have pulled up? >> Yep.

1:13 >> Okay, sweet. So, the topic for today is how to secure agentic coding at scale. And so before we really dive into the the content there, just to kind of set the stage, uh cursor is not like a niche tool anymore, uh it's really, you know, become the default way for a lot of companies to build software using AI. We have over 50,000 enterprises building on cursor. Almost 2/3 of the Fortune 500 and over a 100 million lines of enterprise code actually get written by

1:46 the Cursor agent every day. And so this is kind of the scale that we're talking about when we discuss security for agent coding. We're not, you know, topic talking about something that is going to happen in a few months. This is something that is happening right now across every major industry and all the customers that we work with. Uh and the adoption isn't just numbers on a page.

2:05 So quick example, Jensen Hang, the the CEO of NVIDIA, he calls Cursor his favorite enterprise AI service. All 40,000 Nvidia engineers are using Cursor daily. And so when you have that kind of density inside a single organization, I think the security question sort of shifts from should we allow this feature to more of how do we govern this responsibly at scale? And that's really exactly what Kevin and I are here to talk about today. And just a couple

2:36 other I guess sort of pieces to to set this up before we get into the cursor specific items. Um here is just kind of a a quick way of thinking about like AI maturity for engineering orgs as they scale across this process. So most organizations start on the left hand side of this visual. Um you can think of this as you know manual coding then maybe using some type of like autocomplete. So uh in cursor terms this would be like cursor tab sort of our our

3:08 first uh real launch into sort of AI assistant coding. And then as you move along this this curve, AI takes more and more autonomy. So using the cursor agent as almost like a pair programmer. And then you know today I'd say we're kind of in in this section of uh cursor 2.4 which uh you can almost use cursor's AI agent as a junior engineer. And then as we kind of continue along this curve and and release new updates, you'll be able to use these agents for longer running

3:42 tasks, more autonomous development, and then you know finally uh what we're calling here on the the right hand side is intentoriented product creation. So almost using uh an AI agent as a co-founder or a builder. And I think the key insight for this is that each step gives AI more agency and more agency means more surface area. And so you can't just, you know, flip a switch and have everything sort of be secure. You need to have guardrails at every single

4:11 stage. And cursor is here to sort of help your teams move along this curve uh safely and with the right guardrails. Uh and just a quick statistic here is um this is kind of some proof that this does matter. When we made agent uh the default mode cursor, we saw the team saw almost a 40% increase in merged PRs while baseline orgs kind of remained flat. And that's a massive jump in in code velocity. And so I think the question here from a security perspective becomes if we're shipping 40% more code, how do we ensure that the

4:41 review processes, policy enforcement, access controls, all those other things also scale uh with that throughput? And that's kind of the problem that we're we're going to talk about today. And so, uh, some of the the real themes that we're going to touch on today and really where, uh, Kevin's team is is focused on building are kind of around these four pillars. So, uh, first we'll talk about global controls and collaboration, essentially giving admins

5:09 the ability to set policies across the entire organization. And then we'll touch on integrations and extensibility, basically meeting your existing security tool chain, uh, where it lives. And then analytics and ROI. We know that's a huge important part of uh this conversation so you can measure what's happening and then underpinning all of it is uh just enterprisegrade security and and compliance. We'll kind of focus heavily uh on sort of the pillars above that as

5:36 well. But um you know this is also really important just from a sort of product standpoint. And Kevin, I don't know if you have anything else you'd like to add in terms of where your team's focused and sort of how you think about these different themes.

5:52 No, I think you covered it well. I think it's really, you know, there is a sort of narrow view that you can take on the value that AI can deliver to your organization. And really what we're seeing is in the enterprise, it's about a much broader set of capabilities. It needs deep integrations into your stack.

6:10 It needs to be extensible so you can customize it in various ways. and obviously needs to meet some of the strictest security and compliance standards out there. And so, you know, I think we've been really thoughtful in how we've built out cursor and making sure that it's great for, you know, the individual developer all the way up to, you know, 30,000 40,000 different developers waking up every day and building software together.

6:37 >> Cool. And so before we get into maybe the like agentic specific controls, we can just cover the foundation. Uh and so you know none of the governance stuff we're going to talk about after this matter if the basics aren't locked down. And so these are some of the the things that come out of the box with cursor for enterprise. Uh first privacy mode which is on by default for enterprises. So code snippets never leave your environment unless explicitly allowed.

7:03 We also have uh zero data retention agreements with every model provider. So your code is never going to be used for for training. And then on the compliance side uh we're sock 2 type2 certified support SAML and OIDC for ident identity and then MDM for uh device management. And so really you know this is this is pretty table stakes. You got to have this layer solid before you can even begin to talk about giving AI agents more autonomy in your codebase. So

7:34 really where we'll spend the majority of the time is talking about the controls we've built for governing uh AI agents. So to kick things off um we'll dive into sort of these three capabilities in a bit more detail. Uh the first is going to be hooks which will allow you to run custom scripts during the agent execution loop. I would think of these as policy checkpoints. So maybe before the agent commits, before it runs a command, you can intercept and sort of

8:05 validate that that's what you want the agent to do. Uh second, we'll talk about model and MCP controls. So admins have the ability to restrict exactly which models and tools teams have access to. If you don't want agents calling an unapproved MCP server, for instance, or using a specific model, you can just lock that down across the organization. And then finally our sandbox which allows for isolated execution environment. So the agents will only

8:33 have access to what the admins explicitly allow. Uh and these three things layered together sort of give you a really robust governance model. And so the idea here is that your security teams will be able to control what the agent can think with, what it can do, and essentially uh very granular controls over what it can interact with. So to kind of start with hooks, uh these are deterministic scripts that run at specific points in the execution loop.

9:08 So I would think of these as life cycle in inceptors basically um where they will kind of let you inject custom logic either before or after the agent takes an action. So if you see the uh JSON config on the right hand side uh in this example we have a before submit prompt hook which is running an audit script.

9:33 And so, uh, maybe every time a developer sends a prompt to the agent, your audit script fires first and that could log the prompt. It could scan for sensitive content before it ever hits the model. Basically, you'd be able to um specify whatever you want to do before that prompt is submitted in that audit shell script. And then there's another example here around before shell command. And so, uh, here we've actually got [clears throat] two hooks chained

10:05 together. So, it's the same script that was above for logging. And then there's a whitelist script. And so, that script could inspect the command uh that the agent is about to run and maybe block anything that's not on your approved list. Um, so really the idea here is that these shell scripts um are just shell scripts. You write them, you own them, you check them into your repo. Uh there's nothing really proprietary about the enforcement layer here. It's your

10:34 code, your policies and then hooks would be layered by priority. So enterprise policies you can set at the MDM level would take precedence over something like uh a user level hook that a user could configure. And then the next point here is just around controls related to models and MCPS. So on the model side, we allow you to maintain an allow or deny list of which models you can use. So if your team hasn't approved a particular provider or model, you can block it orwide and no one can select it. Uh it's

11:12 pretty straightforward there. And then on the MCP side, it can get a little bit more granular. Um so you basically can control this at almost like three levels, which MCP servers agents can connect to at all. And then you can also select specific tools within those servers uh that users can can use. And then you can also decide uh whether tools are allowed to auto run or if they require manual approval every time. And so, you know, if you do want to just

11:46 lock down everything completely, there is a toggle to disable all external MCP servers or uh you can get into a little bit more of this like fine grained uh access through the per tool permissions in some of the the execution guard rails. So, I guess like a a practical scenario here is let's say you want to allow your team to use an internal MCP server for your CI pipeline. you can go ahead and allow list that. But if you don't want agents calling some other

12:18 thirdparty server that might post to production, you can go ahead and uh just block it by default. And then the last piece in sort of these three pillars is that sandbox mode that I talked about. And you'll see uh there's actually a little video running here um that shows sandbox mode in action. And really the point of sandbox mode is to control the blast radius. So when an agent runs in a sandbox, it's isolated. It can only see and touch files inside the project workspace and

12:52 nothing else on your machine. So network access is off by default. And uh you can also ensure and restrict git operations to read only. uh in that way the agent won't be able to like force push to any of your repos. And I think the key thing to note here is for enterprises uh this is enforced at the org level not the user level. So an admin can pretty much mandate sandbox for everybody and you wouldn't be able to have an individual engineer or developer uh turn that off.

13:30 Cool. And then the next couple things are actually items that are going to be released very very soon. Um or that we are going to be uh shipping in the the kind of near-term over the next month or so. Um one thing that I'm going to call out first is is just the ability to have team rules within a workspace. This is something that I think uh people uh you know utilize a lot in cursor and get a ton of value out of. So just wanted to call this out as well. Um this is

14:02 basically the ability to bring shared context to uh your entire organization. So if somebody has a rule and you want everybody on the team to use it, um you can go ahead and make that a team rule and that will be applied across every developer within the uh the organization. We've also shipped this for bugbot. Um, and so this behavior would be consistent across not only people using the cursor IDE and agent, but also folks using uh using Bugbot.

14:34 Cool. And then that is kind of uh the the main points of I guess sort of the the granular controls aspect of it. And maybe before we get into anything related to these kind of like new releases, Kevin, any other color you'd want to add in terms of just how your team thinks about the direction of some of the more granular controls that we talked about and maybe what that looks like in sort of the near- term for for Kerser.

15:01 >> Maybe we can just pick from a few of these questions that are coming in. I see one uh around the enterprise dashboard and what sorts of admin visibility do you have both in terms of the configuration of cursor overall as well as sort of code level views views into security vulnerabilities that agent may be uncovering uh across your codebase. So uh we can start there one is yeah there you can think of cursor in sort of two layers. First is the uh

15:29 different surfaces that you use to code. So whether that's the editor or the CLI or cloud agents, uh that's sort of layer one. And then on top of that is an administrative dashboard which gives you a view both in terms of analytics and usage uh which we'll talk about in a minute as well as all of the controls that you need to uh you know set up sandboxing, set up team rules, team hooks uh and view and audit uh your configuration of cursor. So we put a lot

16:00 of thought into the design of uh the enterprise dashboard largely to give administrators a better view into how agents are working on their behalf uh and uh where are the places where you may want to augment or change or uh adapt your deployment.

16:21 >> Sweet. Anything else from the chat you think we should answer live? I'm just taking a look now. Cool. Yeah, I think we're probably good to keep going here. So, some of the the more I guess exciting stuff that we have on the immediate near-term is related to plugins and uh marketplaces within cursor. So, >> yeah. So this is actually about to go live uh imminently. So very excited to give you all a preview of uh what we are launching here. You can think of so Nate

17:06 I think covered in in great depth the uh new extensibility primitives that we've introduced over the last year. So uh hooks uh rules we also now have skills and sub aents. And so you can think of all of these as ways in which you can customize additionally secure uh or extend the set of capabilities that agents are running on your behalf. Plugins you can think of as sort of this higher order abstraction, the box that you can put a bunch of these different

17:36 primitives into. And so uh you can combine hooks and skills and sub aents and MCPs into a definition of a plugin. uh that can be something like your front-end plugin or your data science plugin or your backend plugin, right? Different sort of higher order use cases that can combine these different primitives. Uh so that's sort of layer one of uh what we're introducing with plugins. On top of that, we are introducing a firstparty marketplace which will be global. Uh and so you can think of some of the uh you know SAS

18:11 providers, different service providers that you may use in your infrastructure, different security providers, publishing a plug-in uh that you can install either within your individual cursor implementation or across your org. Uh as well as the emergence of private team marketplaces. And so these can be you know the custom plugins that you are you and your team are building and defining.

18:37 Uh these can then be discoverable for the rest of your team as well as autoinstalled for uh developers on your team to ensure that they are using the plugins that they need to be successful within your organization. So if we could click to the next one uh you can see a uh a screenshot of what's in the works here. Uh so think of this as both the public view uh which will have public plugins as well as you know private uh plugins that you all are uh

19:07 building and publishing. This is backed by a GitHub repo. So uh you can have githops around uh the publishing flows uh within your organization have you know give grant access in the same way that you uh manage uh git access and ensure version control of these plugins. uh as you release them across your work. >> Sweet. And yeah, I know this is something that uh a lot of my customers have been eagerly awaiting and so we're super excited to to launch this and we should have comms coming very soon. Um

19:41 in terms of the sort of next steps here, um we [clears throat] also have uh a couple other things related to just giving security teams like more control from like a network perspective. So this is something that we're also excited to to kind of be working on related to just giving folks uh more control from like an egress perspective. So we have sort of a three-layer policy model where we'll have an enterprise allow where you can list trusted destinations that will

20:12 essentially auto run. You uh could also have like a hard block list to ensure that any unwanted destinations will always be blocked. And then this will work uh in sort of a default deny stage where everything not explicitly allowed uh will require approval from the the user before routing. Um we'll also have some DNS filtering features as well as a built-in HTTP proxy. Uh and so this is basically just allowing your teams more control from a network perspective when

20:43 when utilizing cursor. And then the last piece here uh is going to be related to analytics and and ROI. And so cursor does offer a number of of things within the analytics dashboard that I think might be super interesting for security teams. So I think governance isn't just about like blocking bad actions or making sure that everything is audited. Uh I think people also want visibility into what the agents are actually doing. And this is what conversation insights are for. And

21:18 so the idea here is that um conversation insights will tell you what folks are actually doing within cursor in terms of like the categories of work. Are they using the agent for code refactoring? Are they building new features? I think we've talked to, you know, a lot of CTO's who want to understand how people are actually using cursor and are we spending a lot of time just keeping the lights on or are we actually using the agent to develop new features and these

21:48 conversation insights that are available within the cursor analytics dashboard today help you answer some of those questions? And Kevin, anything else you'd like to add here? I know you've been spending a lot of time talking to folks uh on sort of an analytics front.

22:05 You know, we hear a lot of excitement around uh this set of features largely because it's it's one of the first times in which admin security teams can have better visibility into the actual type and complexion of work that is going on across their organization, right? And so typically you've had to uh manually review all of the tickets that may have been completed within some time frame or uh you know go survey your team to go get their pulse on you know how much

22:33 time do they spend on bug fixing versus new work. And so uh this is sort of this passive uh in the background computation of uh you know the type of work that is going on across an organization which is you know really cool to see and is able to deliver some uh really valuable insights for reporting and board level understanding of uh you know how engineering time is being spent. uh but also there is some feedback here for the developer right there is underspe you

23:00 know how many of uh the agent turns are underspecified and could potentially shift into plan mode for better specification there's you know all of this learning and enablement that needs to happen as we collectively learn and adopt agentic coding and so we're looking at this as both you know very helpful view across the organization but also feedback for individual developers and teams as to how they can get better at agentic coding.

23:31 >> And then another item that we've rolled out fairly recently is cursor blame. And so cursor blame essentially augments get blame with line level agent co-authorship. So, you can see in this screenshot, um, I guess it's probably pretty hard to see, but, uh, there's essentially a line in this that, uh, if you were to kind of hover over this, it would say co-authored by the cursor agent on the specific lines that that cursor authored. And so, this goes down

24:03 in the git log. It tags the commit with AI code tracking. Um, we also have a new AI code tracking API, so you can get a lot of this information programmatically from that endpoint. And so when you're doing like a security review or an incident in investigation and you need to answer who wrote this code, this kind of helps answer that question. Um, and the attribution chain uh matters a lot for things like audit trails, compliance, and just for knowing which

24:33 code deserves extra scrutiny during review. And so this is something that uh we are excited to roll out recently as well. And then in terms of where we're going, we're continuing [clears throat] to kind of add in additional features to the sort of inapp cursor dashboard. So you can expect to see even more enhanced ROI focused analytics metrics. So uh we plan to include things like PR velocity, cycle time, revert rate of your code and essentially the idea here is that we want to make it as easy as possible for

25:10 developers, admins, executives to be able to come into cursor and answer questions like you know how much am I getting uh in terms of return on investment with my my cursor spend? Where are my engineers spending time? and where are some areas where uh maybe we could uplevel engineers and push them in the right direction for how to use the the cursor agent and tool holistically. So, we'll likely have uh some more things coming soon on this front, but this is kind of what what the team is is thinking about in terms of a

25:42 near-term and and medium-term roadmap. And Kevin, I don't know if there's anything else you'd want to add here in terms of just how you think about the ROI story within Kerser. No, you know, I don't think uh we collectively as an industry have settled on any silver bullet metrics. And so it's really about getting a view of uh you know AI lines of code PR and commit velocity what does revert rate look like as well as qualitative feedback that you're hearing

26:14 from your teams uh to give this holistic perspective of the ROI and uh acceleration that teams are feeling where there are still existing bottlenecks uh that can use help. You know, I think like the new challenges around code review and security review and so you know, a lot of the the work that we've covered here and are thinking about going forward is uh sort of what is the new set of bottlenecks uh now that code generation is relatively easy and we have expert agents that we can work with. Uh how do we review all this

26:48 code? How do we do that securely? uh what are the sets of agents that can run to both classify risk for an individual commit or PR as well as uncover additional security vulnerabilities that may have been missed in that first pass. And so a lot of work going in there and I think we're excited about this, you know, multi-perspective view that we are bringing to analytics and ROI uh to give folks a good sense of uh you know, how things are trending and where the

27:16 bottlenecks are. >> Sweet. Yeah. And I do see some questions in the chat just about uh the recording and if you join late, no worries. Uh if you signed up for this webinar using uh your email, we will go ahead and email you a recording uh pretty soon. Uh so you will have the the full recording in your inbox and then yeah, definitely be on the lookout for upcoming webinars.

27:41 Um, if again you can't join at the scheduled time to see it live, if you sign up, we will email you the the recording afterwards. So, thanks a lot for joining and see you guys on the next one.