API Evangelist Conversation with Anna Daugherty on Application Security, Developer Workflows, and Governing AI-Generated Code with Rules

I found myself in application security, but probably because it’s still in the developer tooling space — it’s still considered a developer tool. So even though it’s AppSec, it’s still very much developer-workflow oriented, and that’s where I’ve found most of my career success. I was at Stoplight where we focused on improving the documentation experience and the spec experience, then at Armory commercializing Spinnaker and trying to make that workable, and now I’m at Arnica doing AppSec. The theme is still very much what’s going on with developers trying to create code that is scalable and secure. And when you bring AI into the picture, it confounds the problem a bazillion percent. So our goal is to fix some of these workflow issues so developers aren’t feeling held back — they feel empowered and like they can get the job done without so much friction that things just don’t go to production.

Shadow IT and unsanctioned servers can be identified — that’s part of it — but it’s more about code that has secrets in it, or vulnerabilities, or you’re using an open source package that’s vulnerable. We want to identify all of those things before they get to production, because once they get to production it takes an average of 200 days to fix them. So it’s about identifying vulnerabilities at the sweet spot of when a developer is most likely to fix them. Some people believe that’s in the IDE — you’re coding and you immediately get an alert. My philosophy is that’s a little too early, because they’re solving a problem at that moment and the problem is not security, it’s the thing they’re building. That becomes too much noise, too interruptive — like getting a Slack message right when you’re trying to build something.

From my experience, a vendor will try to tell you it has changed because they want to sell you something, and that something is this brand new, exciting, shiny thing your developers will love. But in reality it’s what it’s always been: individuals like to work individually, in the way they appreciate working. So the more an enterprise can support that work in a flexible and sustainable way, the more efficient and effective it will be — and governing that is always going to be the problem. The governance question comes back again and again. It doesn’t matter where I’m at, it doesn’t matter what tools — it’s always the question of governance. And now teams are standing up MCP servers and we don’t know where they are or what they’re doing, so there’s that whole new question on top of it.

The IDE, in our research, is at most 20% adoption across enterprises, and it’s usually because of the noise problem — different people work different ways, and opt-in isn’t always the best way of doing business, especially from a governance perspective. The CI/CD pipeline is too late: there’s a gate, security says these vulnerabilities aren’t going to production until they’re fixed, and now you’re chasing the problem instead of preventing it, and you’re in the developer’s way. Our sweet spot is what we call the pipelineless approach. You’re at the pull request, about to merge, and you get a scan that identifies the problems so you can fix them before code review — which you have to go through anyway. We found 72% of notifications sent to developers in Slack get fixed immediately, and 92% of everything identified in Arnica is fixed before it ever gets to production. For the most part a developer has no idea anything is even happening; they only become aware when a problem exists.

For AI, what we’re doing is taking the rules.md files for Claude, Copilot, all of these different AI code tools, and creating our own sets of policies that get injected at the point of code creation, so the LLM has to follow those risk rules. You can absolutely do something similar — take those and amend your own rules.md files, because they do work and the LLM will listen to them, especially if there’s an attestation at the PR level of which rules it followed. That’s almost like an SBOM of “did the AI follow the rule set,” and we can see each line in the PR where it does. It doesn’t slow anything down: the LLM is adhering to the rules, we’re governing it, and the developer who’s vibe coding doesn’t have to deal with the security aspect because they can be assured it’s being followed. We had to tweak it and tweak it until we got that one-to-one, but finally yes.

At the source code level is where we’re going to have the most coverage. An enterprise might use GitHub and GitLab, or Bitbucket and GitLab — whatever that mixture is, it’s a smaller mixture, and everyone is using source code. It is the source of truth. So if you can inject your code rules at that point, you have the most coverage. The IDE and the pipeline are both problematic in the ways we discussed, and targeting the source code levels the playing field. But once you’ve got that coverage, you still need a person to review — you still need something to touch that code to make sure it’s ready for production. Now you’ve created a huge amount of code review with only a few reviewers to touch all of it, and they’re not just concerned with security, they’re concerned with bugs and every element of good quality code. So the next thing we’re tackling is how to make their jobs as efficient, effective, and governed as the AppSec teams’.

It’s very much dependent on your governance team’s and AppSec team’s policies. You might have a lower appetite for risk, so you’re more likely to alert on lower-risk items that another team might not care about as much. So it’s about what appetite you have for risk and how you set up your policies to make sure things get addressed before anything happens. We’ve seen that in health tech and FinTech and the more regulated industries, where they have to adhere to higher standards than a company that’s trying to move faster. Something we’re developing is what we’re calling tribal knowledge — taking the context your teams provide and training your scanner on your internal team’s knowledge. A team might say, we always dismiss these risks because they don’t matter to us, and the tool takes that intrinsic knowledge and applies it going forward. It’s actual person-to-person knowledge rather than just an AI determining it, which is a really interesting way to train the model from the team’s real experience.

We’ve had a lot of European folks reach out and ask for help, especially around compliance and what’s happening in the EU versus the US right now. And one thing that’s really interesting is it’s not just engineering teams using Arnica — we’ll have legal and compliance teams using it too, because they want to ensure these organizations are compliant. With software composition analysis, one of the main components is determining whether you’re using licensing correctly, so a legal team might be really interested in that and just want a report of what’s out of compliance. It’s a little crazy that a legal team might get a report from an AppSec tool and find value in it. In my experience the people who care about this stuff aren’t always the people directly doing it — it’s the people who have to clean up the mess down the road and answer to the customer, connecting the dots in a different way than those of us in the weeds building things.

What do you do with an API? You build an application, or an interface, or something for someone to use to solve a problem. It’s the same thing — you’re doing the same things, just with different tools and different outlets, but the same fundamental principles still apply. Sometimes organizations are bigger and have more complex needs, so there’s a different appetite for different types of groups, but I see so many commonalities. That’s what made it so easy to transition my experience into AppSec: I saw all this stuff with APIs — standards of excellence, governance, rule sets, developer experience — and every single one of those questions applies, just with a different set of tools and a different outcome. There’s so much synergy between the problems we’re solving, and I think there’s space for everybody. What’s for me to decide is to say I’m solving problems and to make sure everybody knows how we’re solving them.

When our co-founders woke up one day and said we want to go in this AI direction, as a humanist I thought, great, another AI story, and as a product marketer I had to figure out whether it would actually prove value or just be another buzzword. But when I looked at the capabilities it made sense. There’s AI SAST — taking the very static rule set and applying AI to make it more dynamic, which everyone is trying to do. And then there’s the agentic rules enforcer, injecting those code rules at the time of AI code creation, which is brand new and nascent. I was thinking, what is that thing? And it’s really like a good robot trying to keep the bad robots in line — Terminator 2, Arnie does that. So Arnie AI was born, because Arnica is our name. We did a whole “come with me if you want to vibe” campaign. That was my aha moment that this can have a humanistic, real impact — it doesn’t just need to be buzzwords, AI all over the place. It’s a real thing.

Having real conversations absolutely helps — talking to customers, whose bullshit levels are high too. They’re not buying this thing unless it works; they’re not taking the risk if it’s going to introduce vulnerabilities. So if they believe in it, if they’ve seen it impact their business with fewer vulnerabilities, that speaks volumes. Last week we had our customer advisory council, and AppSec folks aren’t usually willing to talk publicly about what could be problems at their businesses, but so many of them raised their hands to go on camera. I took them into a back room and asked about the evolution of their AppSec program — not a single question about Arnica or our product — and yet every answer was “Arnica helped us do this.” That’s validation from customers willing to pay us, and to pay us more for the AI products we’re developing with them. Outside of work, I’ve gotten really into physical media — I have an extensive VHS collection and vend at dead media swaps. I love the preservation of the physical, because when you talk about ownership and licensing, they can rip that stuff away from you at any time. I love that tactical feel; it’s really important.