This Much I Know · 2026-07-01 · 59 min
Key moments - from our scoring
Substance score
57 / 100
Five dimensions, 20 points each
The episode examines enterprise security's complete unpreparedness for agentic AI systems. David frames the problem at the application layer: agents execute chains of autonomous actions - reading files, calling APIs, spawning sub-agents - that traditional firewalls and WAFs cannot monitor because they lack business context and semantic understanding. Johannes approaches it from identity governance, noting that companies are giving agents root-equivalent permissions with no accountability framework, effectively creating a new class of actor with machine-speed autonomy and no liability. The key insight is that agents don't need to be compromised to become security disasters; they can autonomously decide to delete databases or leak data with good intentions. Neither identity verification nor network-layer controls alone suffice. Arcjet embeds runtime policy enforcement in application code, scanning both inputs and outputs across every agent action (file reads, API calls, queue operations), while Cakewalk's new AI Access Management product extends human identity governance to agent workforces. Both founders agree the market is in a "wild west" phase where companies face a binary choice: paralysis (waiting for solved security) or adoption-with-risk. The conversation reveals that traditional security primitives - built for stateless web requests and single entry/exit points - are fundamentally misaligned with multi-step agentic workflows.
Traditional firewalls inspect HTTP requests and responses, but agents perform actions internally - reading files, calling APIs, spawning sub-agents - that have no web protocol layer. This means all existing signature-based and ML-based detection models built on decades of HTTP data no longer apply.
An agent receives a URL to documentation, reads it, and receives back a response containing hidden text (in metadata or non-rendered content) that wasn't visible to humans but changes the agent's interpretation of context, causing it to perform unintended actions.
When an agent acts on behalf of a human (like a CTO connecting Claude to GitHub), it's ambiguous whether the agent should inherit the human's full permissions, what subset it should have, and whether the human, company, or agent itself is liable for autonomous decisions the agent makes.
Legacy IAM is built around human user identity with assumptions that don't hold for agents: agents operate at machine speed, can spawn sub-agents invisibly, may need different permission scopes than the human delegating them, and audit trails are completely absent in most deployments.
Arcjet is an SDK embedded in application code that enforces runtime security policies at the application layer, scanning inputs and outputs for every action an agent takes (API calls, file reads, queue operations) to detect prompt injection and enforce business rules like budgets and rate limits.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers a solid cluster of non-obvious technical insights - indirect prompt injection via hidden web page content, the MCP tool-blast-radius problem, the zombie identity issue, and the 5-10 action-point control gap in agentic flows - but is padded with repeated metaphors (the runaway train appears three times) and some generic developer-vs-security-mindset observations that dilute the density.
I checked the other day. I think the GitHub MTP has over 100 tools. Bam. That's the exact opposite of least privilege.
when the agent decides to read a file, you need to sanitize the commands and then when it reads out the response you've got to look at the output. And you might have to do that five or 10 times in an agent flow. Whereas the firewall is looking at two the input and the output
A few genuinely fresh angles emerge - that good developer experience accidentally produces agent-readable tooling, that the risk profile of agents has shifted from probabilistic to near-certain, and that pure policy-based control paradoxically destroys the autonomy value of agents - but much of the framing (OAuth wasn't designed for this, regulation lags innovation, security requires a disaster to change) is well-worn.
an agent doesn't have to turn malicious in order to become a severe security risk...An agent might simply, quote, unquote, decide that it really needs to go to this instance now and delete that entire database in order to complete its job with very best intentions.
if you create a uh, product that works really well for developers, good docs like proper, uh, code comments, all those kind of things...you've also created something that an agent can read
Both guests are genuine hands-on practitioners building directly in the problem space - David with a prior security exit (Server Density/Cyberdentity sold 2018) and Johannes with direct enterprise sales discovery across hundreds of security and AI officers - making for credible firsthand testimony, though neither has operated a large-scale security organization and both are very early-stage on their current companies.
Started my first Company as you mentioned, Cyberdentity back in 2009 which is one of the original CCAMP companies...built that company and sold it in 2018 to an edge security platform.
I spoke in the last month to hundreds of security IT um AI adoption officers, um, in mid sized and enterprise companies
The episode includes several concrete data points - GitHub's 100+ MCP tools, 50M tokens consumed in 30 minutes at ~$50, GitHub taking nearly two decades to ship fine-grained tokens, the 5,000-employee company anecdote - but relies heavily on illustrative hypotheticals ('Julia from marketing connecting Claude to the CRM') and unnamed companies, and produces no benchmark data, market sizing, or independently verifiable metrics.
I used like 50 million tokens within half an hour. And so I was like, well, this is fun, but it's costing me $50 to play around with this
how many years are we like it was almost two decades now of GitHub and they've only just added that
The host shows genuine structural creativity - flipping questions across domains and asking each guest to critique the other's space - and the accountability and 'unit of control' questions are sharp, but he regularly embeds the answer in the question, delivers multi-part compound questions that let guests pick the easiest thread, and visibly lets Johannes refuse to answer an entire question without any pushback.
how do you stop a sequence that looks safe step by step, but becomes dangerous in aggregate? And what is the right unit of control for that? Is it at the login? Is it the API? Is it that the session? Is it the API request? Is it the business action, the outcome, the intent?
I have a strict no bullshit policy applied um, to myself. I launched a new product last week. I have too little context about David's company to uh, to give that one a go next time.
Computed from the transcript - who did the talking, and the words that came up most.
Your AI agent just deleted a database. Who gets fired? There's no good answer yet - and that's a huge problem. Companies are handing AI agents sweeping access to their systems, often more than they'd give a new hire, without knowing who's accountable when something goes wrong. In our latest podcast episode, Carlos Eduardo Espinal MBE sits down with Johannes Keienburg, Cofounder of Cakewalk, and David Mytton, CEO of Arcjet: two founders building solutions to this exact problem. They explore why AI agents don't need to "go rogue" to cause serious damage, the "zombie identity" problem of agents that outlive the employees who created them, and why the security tools built to stop hackers simply don't work when it comes to agents.
Transcribed and scored by The B2B Podcast Index.
Speaker A: The type of access that companies that are uh, moving quickly now and are uh, adopting agents at scale, the type of access that they give agents is insane from a security perspective. It is literally wild west and insane, which is in the nature of things. The way I like to compare it is like we just invented a real quick high speed train, uh, and we're driving it and now we're realizing fact there are no brakes, um, and that's where we are essentially in terms of agentic adoption.
Speaker B: Welcome everyone.
Speaker C: Today's episode we have two long standing friends of seedcamp, Both Seedcamp founders, David from arcjet and Johannes from Cakewalk. I'll let them share what their companies do in a second, but I just want to introduce this episode because this episode is very much a timely one. There's so many companies out there chasing agentic workflows either as a sell or as a buy, and they're all struggling with the same things. How do I secure this? What does it mean to secure this? What should I allow? And a lot of the technology that's being released right now is super useful in terms of single user mode, personal use. But when you start looking at, in, in uh, an organization or compounding it or having some sort of like stable enterprise solution, it starts getting really scary really quick. And so that's what this episode is about. So welcome guys.
Speaker B: Hello.
Speaker C: I'd love for you guys to uh, start. Maybe we'll start by alphabetical order. David, I'd love to just share a little bit who you are, what your background is. I mean you definitely have to tell the server density story a little bit there and then you know why you started Arc Jet and then what is ARC Jet? And then uh, then, then you go. Johannes.
Speaker B: Yeah. Thanks, Carlos. So I'm David. I'm the founder and CEO of artjet, which is runtime security policy enforcement at the application layer. So think web applications getting public traffic and agentic applications taking actions behind the scenes, reading files, calling websites. When those actions are happening, you need to enforce certain controls like budgets for users. You need to check for prompt injection detection both on the input from a user, but also when you're reading a file or accessing a website. And that's what our check can help you with. It lives inside your code, can be configured remotely by security teams and um, developers can use it to build security into their application. Started in 2023 and CCAM came in as one of uh, our first investors. But this is not the first time I've been working with you. Started my first Company as you mentioned, Cyberdentity back in 2009 which is one of the original CCAMP companies where uh, our uh, investment was 50k which these days uh, uh, is a little different. It's different model uh, but built that company and sold it in 2018 to an edge security platform. So this is now technically my third company, second one. Console.dev is a DevTools newsletter. I've done a few angel investments through that but just writing about DevTools every week and still going about 30,000 subscribers. Um, mostly engineers, few investors as well. Use the source deals but the day job is artjet helping developers with agentic security. Awesome.
Speaker C: Johannes.
Speaker B: Hey.
Speaker A: To start with David, it's really cool to be in touch. We never met even though um, both C and um, portfolio and um, uh solving adjacent related but different problems. So I'm Joe and uh, day in, day out I'm working on helping companies to control uh, access of their workforce. And that's really interesting coming back to what you just said Carlo. We started cakewalk also in 2023 and we built um, Access Control platform for Human Identities. That's our existing product. And um, end of last year uh, we went all in and literally last week launched uh, an entirely new version which is the CISA product of the Human Access Management in caswant. It's controlling the access of the future workforce which I believe is going to be a very agentic workforce. And that's what we do. In short.
Speaker C: Nice. Well with that I think we, we warm up with a couple of really easy but insightful questions for the audience. Let's just start defining what it is. Like when you guys think about agentic enterprise security, what is the real thing that people should be worried about? Is it the data access? Is it the, the sort of the bad actions? Is it the lack of accountability or is it something else?
Speaker A: David, you go first.
Speaker C: Yeah.
Speaker B: So we think about this at the application layer. So that means understanding what the user is trying to do to which particular objects in which workflow state with what input and really try and connect that with the business rules. That's in contrast to large app with something that sits on the network like a firewall or a waf and we're complementary to that. The network will see the packet but it doesn't understand the intent. And the network is a great place to deal with things like volumetric DDoS attacks. Just huge volumes of traffic that might try to take your application down. But it's very difficult in the network to distinguish large volumes of traffic. Maybe it's your most important enterprise user, uh, who just purchased a quota upgrade because they are about to send a huge amount of API traffic to your application on the network that could look indistinguishable from an attack because the pattern suddenly changed. It's uh, an attack potentially on a public API endpoint, but without the business context you don't know that you shouldn't block that user, uh, because they have just paid you for the extra quota, the access to your API. And that's what lives with the application context. And so that's where we sit understanding whether something should happen in what context, for how long and understanding the risky action. The risky thing is often the action, it's not necessarily the user identity that comes into it and that's important, but that we let other applications deal with that. Which I think is where apart comes in.
Speaker A: Yeah, exactly. So just to compliment David there, who obviously takes an application layer view, we take the workforce view. Your question, Carlos, was like how to define security in the enterprise and probably could speak for 24 hours about that. But the view and the lens that we are taking is access, governance. And the way I would frame it is that the brutal truth is that you. Human access, which was traditionally the field of identity and access management, is an unsolved problem in almost every company I meet. Historically companies try to solve it through the identity providers, but identity providers are really not made for that. There are tons of blind spots, there's a huge lack of automation. And whilst this is unsolved in companies now, a new sort of player entered the stage and that's agents. And as a matter of fact, the type of access that companies that are moving quickly now and are uh, adopting agents at scale, the type of access that they give agents is insane from a security perspective. It is literally wild west and insane, which is in the nature of things. The way I like to compare it is like we just invented a real quick high speed train. Ah. And we're driving it and now we're realizing, fuck, there are no brakes. Yeah. Um, and that's where we are essentially in terms of agentic adoption. And there are many things I'd say the market has to get right from how to best authenticate agents definitely in the future, ideally not through the human credentials that an agent gets these days. Um, how to govern the super broad permissions that agents get these days. As a matter of fact, again, if you connect agents in your enterprise setup, they get got status in your stack in terms of the access they get. And that's the big new elephant in the room for, I would say the identity, um, part of security. And that's the piece that we are tackling, um, with our new product.
Speaker C: While you're sharing that, Johannes, I mean, maybe just to double down on that for a second. Uh, first of all, I agree with your metaphor of the train. It reminds me of how long it took before automobiles had seat belts. Yeah, you see that and you're like, wow, how did that happen? Right? But, ah, but let's just talk a little bit about that sort of identity and agentic, uh, identity. There's an element of it which is easily understood. But one thing that classical cybersecurity has dealt with is where responsibility lies and where the ultimate permission lies. Where do you think accountability sits with work that has been delegated to an agent? Obviously you could argue that it's the human, but it's not always the human that authored it. Right. So is it the company? Is it the department? Like it's a bit of an abstraction. So where, where are you seeing accountability sit with agentic workflows?
Speaker A: I absolutely love that question. It's almost a philosophical question. So I mean as a counter question, have you tried, when you ask about accountability or liability, have you tried to sue an agent? Maybe we're going to see that in the future, I don't know. But I'm no lawyer and I'm also not interested in legal conversations. But I would assume, um, uh, for now it's a combination or it shall be a combination of the human who delegated an agent on behalf of their organization. Uh, that's how I would think about it. And we should double click on actually what type of identity an agent is. I would argue as of today, the new identity concept that we see is this combination of an agent acting on behalf of a human. So we definitely cannot forget about the human, um, behind an agent. As a very transparent or clear example, like if you take the CTO of a company who wants to connect Claude core to their GitHub instance, obviously that agent, there's a big question if that agent should have like identically mimic the permissions and entitlement scope of the cto, or if it should be different. But definitely the fact that it's acting on behalf of the CTO will impact as a variable, um, the permission scope that this sort of cloud agent will get in comparison maybe with the permission scope that the, the same cloth of a junior sales rep will have. Right. So I, I do believe that maybe, and I mean the, the world is moving so quickly these days as you, as you mentioned in your opening statement. So six months feel like previously five years maybe in six months and 12 months maybe we're going to see already purely agentic workforces where the agent itself will become the, the sort of identity there we are not there yet I would argue. And therefore for now it's the combination of an agent and the human behind an agent. You could argue the specific job even of an agent and uh, of an agent and a human behind that agent. And therefore the human is still the person who delegates the agent and they should, shall be in charge. As a matter of fact, this delegation is already completely out of control because today companies, it's almost impossible for them to get a clear understanding of all the agentic jobs out there, let alone a proper sort of audit trail, um, where you could even go and see any type of um, lock. And in order to get a complete picture of the accountability or liability. But again, to answer your question precisely for now, in my perspective, it has to be the human behind an agent from a boss.
Speaker C: It probably is. I mean, I'm torn on this as well. I feel like it's, it's uh, ambiguous. Once you've given it some, some level of independence and you've delegated it to others to manage, it becomes really ambiguous. I don't want it to inherit my permissions. The, the more senior I am, the less I want it to inherit and I don't have a mechanism I wish to control it. But maybe, maybe David, you can comment on that question. But also maybe a slightly parallel one more in the, in the sort of network layer you're in. You know, if I look at agents, I think of them as uh, a long chain of small actions. In many cases. Cron jobs, glorified cron jobs with a lot of speciality. Right. And how do you stop a sequence that looks safe step by step, but becomes dangerous in aggregate? And what is the right unit of control for that? Is it at the login? Is it the API? Is it that the session? Is it the API request? Is it the business action, the outcome, the intent? What is it? Ryan?
Speaker B: Um, this is where identity becomes necessary but not sufficient because you have chains of agents. So you might have a one to one with your chatbot, but if you ask it to do something, it might launch 10, 15 agents behind the scenes going off and doing things. And um, that's fairly common if you're using something like Claud Code or Codex. That's what it's doing behind the scenes. Even if you don't know what's happening, there are sub agents there. That's this, uh, kind of sci fi world of agent swarms where you've got a UI that shows you hundreds of agents. It's just happening behind the scenes and you don't really know. And so identity is important there. But an agent might have valid credentials, but still be manipulated into leaking data or calling the wrong tool, spending more money than it should, or doing some kind of other irreversible action. And so you need to know the identity, but then you, you have to be very granular, uh, on what that identity is allowed to do at what particular time and how you then connect that back to the audit side of things. Because you always need to be able to understand what has happened. Now that question, what happened is a classic security question and it's normally asked after a breach. And that is the core of setting up your security foundations, is understanding how you can answer that question in the future and in the past. That's just mean putting logs in place, installing a siem, installing MDM on your laptop, logging everything to one of the SIEM providers so you can query that data. But the more and more systems we have, it makes it, uh, difficult to get the right data and the volume of data is increasing significantly and then you may not even be able to tie it back to a direct identity if it's just logging in using your own credentials. So everything has become very messy very quickly and yeah, serious business consequences as a result of this.
Speaker A: Yeah. But if I may add one additional layer, I agree, by the way, that there's of course a certain sort of moment where the identity layer is not enough even to ultimately control the security setup of an agent. What I find super interesting, David, because you explicitly said, like, when an agent turns malicious or gets hacked. What I find so fascinating, like the mere fact that we have these actors now that act on machine speed with no liability accountability, um, but complete autonomy is an agent doesn't have to turn malicious in order to become a severe security risk. And that's really, that's a new phenomenon. An agent might simply, quote, unquote, decide that it really needs to go to this instance now and delete that entire database in order to complete its job with very best intentions. And that is new. That is new. And that's something that we definitely have to crack from a security perspective. And I would agree. Of course, in order to solve that end to end, there will be stuff like intent control, um, and similar things that you have to add to the equation to control that end to end, if you like.
Speaker B: The traditional security tools are not designed because they assume that there is a single, ah, entry point and a single event that happens. So if you think about a firewall, it's looking at a web request that comes in and then the response that comes back. And that maps very nicely to a chat interface where you type in your question, you send the question and then you get a response back. And the firewall is a great thing to put in at that point. But then when you have an actual agentic system that's going to do things as a result of the chat, where does the file sit? Um, and that is their good question right now. And you essentially have to put controls in every single action point. It's not just the chat form post and the response you get back. It's when the agent decides to create an item in a queue, you've got to have the input scanned. It's when the agent decides to read a file, you need to sanitize the commands and then when it reads out the response you've got to look at the output. And you might have to do that five or 10 times in an agent flow. Whereas the firewall is looking at two the input and the output on the um, web request. The remaining eight requests could be to another website, could be to a file, could be putting something on the queue and each of those input output opportunities, um, give you a chance to inject something into the agent's context or to give it some to manipulate the input or the output. And this is where the um, security layer is missing right now. That's what we're trying to solve at arcjet, but it's a brand new problem because agentic systems like this are uh, the new form of application design. But it's so new that it's only really in the last few months that this has started to become effective because the models are better but also the primitives are there designed to allow you to build these applications.
Speaker C: David, maybe this is a good point to do a little bit of ancient firewall history as well as arcjet cutting edge technology insofar as a customer is concerned. You know, if you look at the history of firewall firewalls in general and how they, you know, went from stateless to stateful to then AI ones and smarter and smarter at the network layer. Walk us through a little bit about how some of your customers are incorporating a level of intelligence into arcjet so that it can figure these things out. Because we're now looking at a very different way of learning, like for detection you need to have like much more switched on semantic understanding of what the hell is supposed to be coming in and out. And how do you do that? How do you, what's the setup look like for a customer? What does training look like, what does deduction look like? Just walk us through that a little bit.
Speaker B: In a classic firewall you've got a web request. So the CATP protocol, you might be using something else like GRPC perhaps, but essentially it's a web request. Um, you've got the HTTP headers and then you've got the body. And so in a request you can inspect the request headers and what the user is requesting. So you can look for um, signatures of malware or SQL injection type attacks and then the response, you can analyze that as well because you might want to get full pass information that shouldn't be coming out through that endpoint. And this is done m as a firewall on the network or you proxy all of your requests through a firewall and it does the analysis, just looks at um, the actual request itself. When you have an agentic application that is doing things internally, like reading a file off a file system, there is no web request, there's no HTTP protocol being used. It's doing things like accessing the file system. And so the handler behind the scenes rather than just being an HTTP handler, it's responding to an event. Maybe it's on a queue, maybe uh, it's calling a system command, maybe it's doing something else. But there is no web request. And so all of the signatures and the analysis and the machine learning models have been built up over decades of looking at this web data, uh, are m no longer relevant. They don't work because it's a brand new data set. And so what we try to do with Arcjet is the SDK uh, itself that you install in your JavaScript, your Python, your Go application sits inside your code flow. So the request comes in and then you call object to do an initial check on the incoming payload, whether that's a web request like traditional application or it's a um, completely custom request, because maybe it's an event that's been pulled off the queue. And then for every single action that you take, like making an internal web request or reading a file, you need to scan the input and the output because the input might have manipulation in it, but the output might as well. And a classic example is indirect prompt injection attacks where an agent makes a, ah, call to a Website reads the web page. Maybe it's documentation. You've just given the link to your agent to help you implement something. It reads the web page and to a human the web page looks just like a documentation page. But to the agent which is looking at uh, maybe he's looking at images, maybe it's looking at the source code, there's some hidden text that doesn't show up to the human and that hidden text changes the context of the page and it makes the agent do something different. And so you've got to scan not just the input which might look perfectly fine, just a web URL, um, but then the output that it then passes back into the rest of the flow could have this context manipulation inside it. And um, that's where the risk comes um, in is when agents are taking these actions that you can't detect through a traditional firewall.
Speaker C: Yep. And if you walk us through the average customer that you're engaging with right now and as well as you Johannes, what are people doing right now? To some extent there is anybody who's listening to this, whether they're a founder or an investor will definitely hear anecdotes about how companies are paralyzed. Even though this conversation can make total sense to somebody. They're paralyzed by the tools that they have available through their normal systems providers and or resellers or whatever and they're struggling to think about how to adopt these technologies for better use. What's the, what's the current state of your enterprise engagements? Johannes?
Speaker A: Yeah, I love that what you just said and Carlos about being paralyzed and I can, I can totally um, confirm that, I mean pre launch of our agent or uh, access management for AI agent product. I spoke in the last month to hundreds of security IT um AI adoption officers, um, in mid sized and enterprise companies and if I simplify there are two buckets. Ah, these are the extremes. There's a category of companies where security simply says like look, I know we need to adopt AI and we will do it but unless some of the most fundamental security questions are not solved, we are not going to do it because there is too much at stake. Stake, um, because we're dealing with health data uh, or with financial data and like a single severe incident would be too, too harmful. I think personally that this is a very very risky category but because like even if I agree to the statement that some of the security fundamentals are not solved, coming back to the high speed train running at high speed with no brakes but um, the only way to get used to solving them and to even understand what's the problem that needs to be sol. The only way to get there is to adopt it, ah, and learn it if you like on the go. And as you're adopting and therefore there's a second category of companies that simply say look, I'm again simplifying a bit. We can't fall behind. Ah, the upside is so enormous we have to adopt it. And um, yes there are unsolved security, like fundamental unsolved security problems that really give me bad night of sleep. But we still have to do it. And what I will say what I thought was very interesting and the guy themselves uh, referred to it as a French Revolution. I spoke to um, US based, uh, it was actually a CTO and um, Salso and they, they stopped agentic adoption. And their company was I think a 5,000 employee company because they said there are too many um, uh, open questions. And that was a revolution from the bottom literally starting no surprise in their sales and marketing organization but also in their engineering organization teams bottom up simply said this like this is unacceptable, this cannot happen. Which I think is very interesting from an organization perspective. Apparently that company CEO ultimately took decision, no, we have to do it, we need to take the risk. Um, so that's what I, what I keep hearing from companies and I said that earlier specifically for the very problem that we are solving. Um, of course the access that companies are giving um, agents at the moment, if you think about it, is insane. It's insane. Ah, um, just in super short, what happens is, I don't know, Julia from the marketing team connects um, Claude to um, the company CRM. She's using the human credentials to authenticate and authorize the human. There's not even a clear differentiation between the two. Those two uh, are for very good reason. Two different concepts. So she's borrowing her human access and authorization and authenticates um, the agent. Why is that a problem? Because after this happened, this agent by definition has static access. No one is ever going to revoke it again. With the technology that is out there today, this agent is not going to be caught in any access review. Um, potentially even if she's offboard, that agentic connection might prevail. That depends a little bit if it's SSO or not. But that's the first problem. So it's a static access. And everyone who knows like how a proper access governance looks like is that least privilege and constant access removals are really fundamental to reduce your access tech surface. That's not happening with agents at the moment. The second Problem is um, I know we uh, Carlos spoke a lot about mcps and everyone is speaking uh, about MCPS these days. So what's happening if you connect CLAUDE to a third party system um, as NCP server, uh, by definition there are a few differences but to simplify by definition the agent get access to all the tools that are available on the, on the respective MCP server. I checked the other day. I think the GitHub MTP has over 100 tools. Bam. That's the exact opposite of least privilege. Yeah. Why should an agent by definition get access to read, write, um, delete and so on. And this is what's happening today. Yeah. And that's why I made the comment earlier that I said an agent doesn't even have to turn malicious. If you bear this in mind, this static broad got status type of access that this agent has. Now if Claude now decides and says like ah, I think in order to um, to complete my job here I should actually delete that page deal pipeline in the cnn. Yeah. Then it has per se the setup uh, to come sort of complete that task. And that's a problem. And that's a problem and we're very passionate about and we are trying to solve um, through a deterministic policy based approach to give companies um, uh, sort of a heuristic to define what type of access an agent should have and what type of access an agent should not have and what type of access should require extra approval to sort of mitigate this kind of catch. All got status.
Speaker C: Yeah, no, I agree and maybe David, this is an unfair question to ask, but I'm going to pick you to ask it. It's like when you look at, you know, some of the things that are being built by startups like Johannes and yourself, there's another set of tools that are being built by Claude and others that are designed to sort of at least appease some of the security elements of it. Some of them are built on, you know, the standards that exist today. Which means as Johannes said, there's limitations that are crude and that's why he's built Cakewalk. But when I look at the speed that Claude uh, well, anthropic and open hour shipping, I look at some of the innovations they're having and I'm wondering, do you think this is the part that's unfair? Do you think that there's a world where the cybersecurity stack for agentic parsing sits within anthropic and everyone's using it both for inflows and outflows or do you think it will exist and continue to exist externally through companies like arcjet?
Speaker B: The fundamental problem is that all of the connection mechanisms I've designed for human m everything connects through OAuth apparently. And OAuth does that flow. Everyone I'm pretty sure has seen where you click to connect something and you go through to the, the other person's website and it gives you a list of all the things that application is going to access and you approve it because you always approve it and then it goes back and you've got that kind of back and forth flow and you can already see that load that there is a problem because it's a human being connected and the access controls are not granular, they're almost always read or write and that's it. And you need much more granular controls there Even just thinking connecting your email, okay, well I can read your inbox. Can I delete things, can I delete things that uh, I uh, were in the last 30 days? What about all of your email? Can I delete everything? Can I Certain tags, all of these different levels of granularity is just not possible right now. And that's the fundamental challenge. I think that's probably what we'll see the AI labs do is they'll stay at the high level authentication primitives, there'll be something different, there'll be an agent equivalent OAuth uh protocol that will be much more granular and give you far more control over what you get access to which kind of exists right now in fine grained authentication authorization type applications uh where instead of role based access you get fine grained access. But you just look at GitHub um, when you create a token for access to your GitHub profile it's only very recently that they've released the fine grained authorization feature and you still have this, what's called a classic token which kind of gives you almost access to your entire GitHub M access. And how many years are we like it was almost two decades now of GitHub and they've only just added that. And typically in security and maybe in society in general is the we only ever implement controls after there's been some major disaster or problem. It's very rarely proactively implementing these things because we're going to try and prevent problems. It's more as a response to something that's happened. And whilst there've been a lot of security issues and endings, things like deleting databases, we haven't yet had like a huge catastrophe that has happened in a particular country or region and that has been pointed directly at AI. And um, I think that is still to come. And when that happens, that's when we'll start to see a sudden change in what regulation probably will come as a result of that. But uh, the companies and the organizations building these tools and uh, will have to rethink how all the security works. But there's always going to be opportunities for startups to build in areas that are, uh, just not part of, they're not broad enough or for the AI labs to build it. And I think getting into the details of every single call that's being made inside an application, like what we're doing with arcjet, is one of those things is best done by us. Obviously I would say that rather than the AI, uh, agent developers, they're more likely to do things like code scanning or looking for vulnerabilities and helping you, um, patch them rather than building in a full runtime policy enforcement layout.
Speaker C: Yeah, fair and then, and I was hoping you would say that, David, but, um, you know, the funny thing is that, you know, we wake up every day, I wake up every day and I look at what's going on in geopolitics and what Claude shipped. You know, it's like there's such a speed there that it's like you, it's not entirely insurmountable that some of that control layer might start popping up. But I do agree that it'll be rudimentary for the nuanced application that many companies need. But you brought up a very interesting point, which is around how slow standards, protocols, compliance, all those things evolve relative to the innovation. Obviously, uh, the innovation's outstripping all those things. And you know, you look at even older protocols like email, right? We've never even been able to figure out how to add encryption to it because it wasn't built as part of the original protocol. So even to this day we're still trying to figure out how to do that. Well, for medical records and other things. And I look at the current tech stack and the protocols and I think some of them are not built for this weird middle ground between agents and identities. And you know, like, I look at one of the questions I was going to ask you, Hannes, but as a pass through was this idea of a, uh, transitory identity where an employee leaves their identity created and gave permissions to an agent. They're no longer in it, but that agent's still productive on behalf of the company.
Speaker A: You often now you have a zombie,
Speaker C: you have a zombie identity in the organization that needs to have some sort of connection. But you've already deleted the Google workspace.
Speaker A: Whatever. But uh, you know, if you think
Speaker C: about that and you think we're missing a lot of protocol layer stuff, we're missing a lot of features. What do you think, Johannes? We're missing at the sort of audit level, maybe at the log level. What are we missing at uh, the protocol level in the. To be able to really secure this generation of future agents and users.
Speaker B: Cool.
Speaker A: I do want to quickly go back to your anthropic questions. I have to, I'm sorry. And then, then let's talk about um, audits. What I will say is like when we looked at that access control gateway or um, access governance layer for agents, obviously we uh, ask ourselves and challenged ourselves heavily like is this something that anthropic could ship and kill it within seconds? And I'm more than convinced that this type of layer by definition cannot come from one of the big LLMs. Um, that would be just a design flaw and failure. Then it's just Claude. And if you think of sort of the access control logic that any larger organization in this world has to take, that's always like it's multi human and it's like multi agent as well. Right? Um, it can't sit there. And by definition it needs to be an independent layer across all the agents that you are using. That's the, the whole idea of such product. And therefore yes, in theory a company like Anthratic could ship, ship an agent gateway and then this would be the layer to control also all other agents. But that doesn't feel natural to me. So um, I would argue the, the access control and governance piece is one of the few um, sort of areas within security that will very likely not be touched or attacked by planet like Anthropic. I'm sorry I had to give that um, answer. Go back to that one. With regard to your good look, with regards to the audit, I can only specifically speak about audit logs for human access. I would say 50% of the companies I meet still don't have that when it comes to audit locks. Granular audit locks for your agents. Again, cross agent. Ah, not just maybe through some aggregator that you're using. And that is very limited. It's simply not existent in companies. And what's happening already is that in certified companies, auditors are starting to ask questions about like hey, okay, um, you have, are you sub 2 certified? How do you think about agent access control Right. None of these frameworks have been written with agents in mind because they uh, are prehistoric, if you like. But uh, very clearly, if you read the language, agent access falls under the access control policy. So you need a heuristic and a mechanism to control the access and locks are not existent at the moment. I will say that in the V1 of the product that we shipped last week, there's a very granular audit section. And I think that that is for now the real wow effect. When prospects see that section, it's like, sorry for the French, fuck me. This is exactly what I need. Um. M, this is where it becomes very evident that you have a problem if you don't know your history. David, refer to that because that's the first thing you need if something goes wrong.
Speaker C: Yeah, no, fair enough, fair enough. All right, so for this next question I want you guys to answer on behalf of each other. So I'm flipping it around. David, what do identity and access management companies underestimate about application layer context?
Speaker B: Yeah, I think this three or end Access Control is uh, attributes to make an access decision, like which group you're in, what tags do you have on the user? And that's like, that's the right way to think about understanding who the user is and what login they're allowed to do. It's kind of course resource access control. And I think what is missing from that is the business context. Because like I said earlier, you can prove who is allowed to log in, but you still need to make a decision as to whether the particular action can happen right now. And that can change from moment to moment depending on the context. So for example, if you have a support agent, a human or an AI agent M, they might be able to make refunds to a particular customer up to $50 before it has to be escalated. But does that mean you can make ten $50 refunds to the same customer? And that's the kind of business logic that you can't encode in Access Control the access control gates, the ability to access that uh, functionality, but the business logic defines whether the action is approved or escalated. And it's not that authentication M and Access Control is getting it wrong. It's not just that the decision has to be made at a different stage. Access Control happens before and then you get the decision and action control happening when it happens.
Speaker C: Fair enough, yeah, that's true. Now Johannes, you can comment on that, or I can ask you the inverse question.
Speaker A: Yeah, I would love to comment. And to start with, I actually agree, of course and historically I would argue this, like why is that statement so true? Because this dimension was non existent in this dimension of the problem was not existent in human access. Really. And therefore I agree. And that would be my, my projection is that um, there needs. And the honest answer is I don't know what this is going to exactly be and how you can build it, but I do believe that something around intent control, uh, will have to be part of a genetic access control in the future. This can become a sister product or essentially needs to become once. The basic questions of access control are. So it doesn't need to be married? I don't know yet.
Speaker C: Um, we've invested in one of those companies. Johannes, by the way.
Speaker A: Yeah, that's good for you.
Speaker C: And if you think it's hard to sell what you guys are doing to enterprises who feel like reticent to try something new, imagine this abstraction layer that you just described is like another level of difficulty.
Speaker A: Absolutely. And therefore, and I mean this is now almost turning into a strategic brainstorming conversation if you, if you add this intent control element to the equation and then there's of course there's the context element sort of helping, maybe even in a functional logic in your go to market stack, in your finance stack, uh, like how to make sure that the agent has the context it needs. That's probably also only an adjacent problem and not the ultimate access control problem. What I find very fascinating and more to come on that one from Cakewalk very soon is there's of course a question of control access of an agent, but there's also a dimension of enable an agent. And let's not forget about that. We spoke a lot about like what type of brakes we need to build to slow the high speed train down. Again, having said that, we love the high speed train, right. And we love the autonomy um, that agents have. And therefore what I will say is that there are quite some players now that think like only deterministically and only policy based in a very rigid manner about sort of controlling agents. And that almost if you think it through takes away the autonomy again. And that will be a shame. That can't be the solution in my perspective. So it will be a trade off, um, between getting some sort of control um, into the game but also enabling an agent and telling like think of a system where an agent gets going and it gets the task to, I don't know, write a certain marketing copy and you enable the agent in the first place and tell it, look, your user just told me to go, I Don't know through that notion page and read some of our marketing claims. But actually I think there are other uh, instances in your company where I should also go. I don't have access yet, but I should go there because I'm fairly certain that I will find very relevant information there. So enabling that agent to do that and to sort of know the unknowns, but in a controlled manner, that's something that I personally find extremely fascinating.
Speaker C: Yeah, not fair enough. I agree. And um, I would love to see how that evolves. I mean it's so, so fast moving. So now, Johannes, it's your turn. What? Developer security companies like arcjet.
Speaker A: I don't know. To be honest, I'm not, I'm not
Speaker C: well equipped to underestimate about governance life cycle and compliance. You can't get, Come on, you can't squeak out of that.
Speaker A: No, no, I'm, I'm saying no to that question because I, I have a strict no bullshit policy applied um, to myself. I launched a new product last week. I have too little context about David's company to uh, to give that one a go next time.
Speaker C: Fair enough. So David, you can answer your own question. What do developer security centric companies underestimate about governance lifecycle and compliance?
Speaker B: Well, it's the classic that developers don't care about security and M, that is ah, application. A funny line that has some truth to it. And um, at the beginning of starting Archer, my theory was that it's because they don't have the right tools. And this was part of the differentiation of focusing on an SDK with developer experience. And that accidentally allowed us to create an amazing agent experience. Because if you create a uh, product that works really well for developers, good docs like proper, uh, code comments, all those kind of things, so the agent can, or the developer can discover and um, the surface of the product and the API, you've also created something that an agent can read. And so we very quickly shifted to focusing on agents and agent as the primary user, uh, on behalf of developer. And that kind of solves the first problem, which is developers security is such a different mindset that is the opposite of developer. Developers build and security try and break or at least they minimize risk. And that's very different because developers are thinking about what feature do I need to implement, what problem am I solving? Whereas security teams are thinking about minimizing risk or understanding attacks and trying to find vulnerabilities. And by creating agent skills, our MCP server, our cli, we can bootstrap security knowledge into the developer's agent. And it makes them look like they are amazing at security because they can ask the agent to do things like solve security for me or find the security issues. And what we see is developers are saying add, uh, protection, add rate limiting, add budget controls, add prompt injection detection to my app using arcjet and it will just do it for them and we don't need to try and teach them all on the security principles. So AI, we would had a very difficult job of teaching developers all of these techniques to try and get them um, the skills they need to effectively protect their applications through an SDK where we try and solve some of the problems for them, but they still have to understand the rules to configure, uh, where to put it into an application and how to look at the results of that to tweak the rules and make sure you don't get false positives and false negatives. And now we can just do that through the agent. And the agent already knows everything there is to know about security and we can focus that with targeted skills and understanding to implement our jet specifically. I think that's the biggest challenge of building a developer security product is the developers don't necessarily want to learn about security. And then the second challenge is that they don't necessarily have the buying power. That's where the security team comes in. So you then have to build the product for the security team as well.
Speaker C: So just to maybe broaden the scope that arcjet is possibly engaging with. So one thing is security as what we described it for up to now within this podcast, uh, of arcjet, you know, like injection attacks, escalation, you know, those kinds of things. Then there's kind of like the softer security stuff which is like compliance policies, you know, that kind of stuff is the vision. Do you reckon that the something like arcjet would have a living breathing connection to a different department in the organization that deals with policies and all that stuff and then also feed that in to the developer or are those two things separate in your eyes?
Speaker B: They are separate, but they are related. And it's where we're going. This idea of AI compliance, the challenge with something like RAID limiting for budget controls or bot detection for sign up spam, is that uh, typically you'll add that once you have a problem. And so you have to build your application, you have to deploy it, you have to have users, you have to be at scale, you have to be starting to face the pain and then you try and solve problems. That problem, it's the opposite with compliance because you have to have the compliance completed before you can release the application or at least before you can go to certain customers. And they require SOC2, they require the ICO compliance. You have to be compliant with the different regional AI regulations around image generation, for instance, and whether you put watermarks or what you're allowed to create and then sell, because the payment processes have restrictions on the kind of content that they are allowing to sell. Um, and that's essentially where the pain point changes to something that's reactive to something that is blocking sales, essentially. And there's a lot more incentive to solve that. Second compliance bit. You could ignore it, but then you're going to probably come up against regulations and laws and there's all sorts of challenges there. Whereas if you ignore bond detection, you're going to face it. Maybe you get woken up in the middle of the night with an alert or maybe you just get a load of annoying noise in your analytics. That's not as painful as the compliance side of things. And so what we are, um, we're going into, particularly with the prompt analysis side of things, is the uh, compliance component of that. Tricking agents and LLMs that are doing the same things, but in particular around what the output of that is and whether that is compliant with the various regulations.
Speaker C: Yeah.
Speaker A: Here I would love to weigh in because in my experience in the last few months I'm almost perceiving a slightly different color. David. So the way I phrase it is, I agree, like, why is compliance ultimately becoming a buying trigger in a company? Because sales want that. Right. I mean the tremendous success of drata and Oneta specifically is because for me they are ultimately, in my perspective, they are sales tools. Yeah. Their sales team come go to management. Hey, we've lost that big deal. Because we don't have a proper compliance, um, framework. We need that as ap. Yeah. And we've, we've been riding that wave too to some extent. Because like our, our, I call it, refer to it as our old product, human, human, active management was almost the operational end to end implementation of a company's access control policy.
Speaker C: Yeah.
Speaker A: Huh. So you first get certified, you get a GRC tool in place, um, to be compliant, you've got something, um, that you can show in your sales, um, process. But then you will get more questions like show me how we do access control specifically. It's something that is always at the top of any compliance list. So. But sales is, if you like, a key in that driver within company to implement that. My experience from the last few months Is that the harm that an agent can cause, an uncontrolled agent, the harm that an uncontrolled agent in a company can cause, people understand that this outweighs sort of the harm that a human user can do by quite a factor that I almost perceive a certain shift that people like, since I'm doing security for the first time, I feel that people are really, really concerned about security in the first place and really come and say like, no, look, I really understand we have to adopt AI, but we can't do it without guardrails and frameworks and controls around it because it's almost guaranteed. It's less a statistical sort of game as in previous times, and we might get hit, but we might get away with it. Therefore, let's solve security in the next quarter. My perception is this is changing now because people, um, everyone who's not completely dumb understands it will hit them for sure. And therefore I would say, like security, security is becoming an even more imminent and urgent buying trigger than compliance. And I see a certain shift there.
Speaker B: That's good news. Thanks.
Speaker C: I actually want to shift away, but on um, this little point you just made about the uncontrolled damage that an agent can have into two fun abstract questions for both of you. What is one agent capability that you would not allow inside your company yet?
Speaker B: Well, the thing that we are, ah, not allowing right now is anything equivalent to the item claw or any of the variants of that. There's plenty of them. Um, I think it's an amazing tool and everyone should play around with it, but not on your company laptop, put it on a vm, um, don't connect it to your company tools to begin with and just understand how it works and what it's going to do. Um, because it goes back to everything, we'd just be talking around because it has access to absolutely everything. And if you put on your laptop or a system that essentially your laptop, your computer, it's going to have full system access. Now there are other variants that have much more constrained permission sets that are much more secure to work with, but all of them have the same floor as they have full root access because you've installed it as part of your user. And I think this is just the early stages of this type of tool. And um, the future of this category is going to be probably provided by the likes of Google. They already announced something recently, proper Google system. And I'm sure OpenAI and Atropic are going to be doing it as well. For something that does have all of the security controls that you need, but something like opencore, we just, uh, we have detection rules in our MDM that will block those from being on your company laptops just because they're so. And they have so much access right now. It's just not the right time for that on a company system.
Speaker C: Just out of curiosity, has anybody tried and you've caught.
Speaker B: We haven't. We told our team before we put the technical restriction in place to detect and block it automatically. We just told people probably don't install this. So we haven't seen someone that's always
Speaker C: the ultimate judge is like, does anybody try? And you're like, guys, what are you thinking?
Speaker B: Yeah. Anyway, I installed it on a vm, I've installed it on a separate vm and like the number of tokens it ate through and then used like 50 million tokens within half an hour. And so I was like, well, this is fun, but it's costing me $50 to play around with this, so I'm just going to delete the VM now. And I'm trying different things at different times. I tried it, but just. I didn't put it on my laptop.
Speaker C: Yeah, fair enough. Be honest. What's the one agent capability you would not allow inside your own company yet?
Speaker A: Actually, identical answer as David just gave. Um, same here. I know some of our folks are playing around with it heavily, but that's for private usage. Yeah, apparent. Like, apart from that, what I find very interesting is that I believe like 18 months from now, maybe 18 months ago, our engineering team, Cakewalk is mainly an engineering organization. Our engineering team, which I deeply love with all their pride, would go and say, like, oh, agent coding. That's not going to happen.
Speaker B: Ha. Uh, ha.
Speaker A: Uh-huh.
Speaker C: Ha.
Speaker A: It's never going to get as good as a human. And then probably 12 months ago and six months ago, it fundamentally changed. And then the way their work more sort of plays out has fundamentally changed in the last six to nine months. Um, so we're using it heavily for all our engineering work. I posted recently about like reaching token limit for our engineering LLMs. And hell broke loose, um, when some of the models were not running for a few minutes because, uh, essentially the entire engineering organization is heavily relying on it. We are massively using it, um, in the marketing team as well. And restrictions are similar as in David's organization. What I do find very interesting, obviously I'm also doing a lot of. So it's a marketing work in Cakewalk, and I'm using AI heavily for, let's Say back office automation, but I'm going away after testing it for a while from sort of agentic content creation because what I'm seeing there, I was a journalist in my very first professional life, as you might remember, and I think it's just terrible. It's regression to the mean. It all sounds the same, it's shit content. And you can even see by now how social networks are punishing AI m only content. It's pretty easy to sort of identify and I think there's a huge opportunity. There's a huge opportunity not only to almost a need, um, for companies to again build very authentic, original, um, edgy, almost true content, uh, non AI driven. Again it can be very powerful for your back office automations. But the content itself, like this conversation, lasts 60 minutes. It's human. So there will always be a resurrection of true human personal brand and content. And I think that's actually a great consequence of the AI times that we are living in.
Speaker C: Yeah, yeah, I agree, that sounds fair. And maybe as a last fun question for the two of you, in five years a lot of things will obviously have changed. If you recall back in the day when the iPhone came out, there was this distinction between mobile and web and it got merged. Now it's just what version of responsive site are you building? Right. Do you think agent security will become its own category with its own set of tools in its own thinking and different forms of optimizations? Or do you think it'll just disappear into application security, IM and observability like current applications are?
Speaker B: With the uh, caveat that the AI scene is changing so rapidly in five years, like five years in the past, ChatGPT didn't exist. So, um, with that, and I'm um, about speed caveat. The security industry loves an acronym and it loves a vast number of categories. Just go to RSA or Black Hat and or grand. And there's just so many different types of products and they're all making huge amounts of money. So I think it's highly likely that there'll be more categories and agentic security right now means, will mean something completely different and there'll be probably five subcategories of agentic security. That's my bet, based on the history of the security industry.
Speaker A: Yeah, I agree. I give you a twofold answer. Um, Carlos, for once I always hated the acronyms and security. I really hate them. And uh, I think it would be a relief to get rid of them. But I'm not very optimistic um, about that. Apart from that, it's like AI Security, non AI Security. This is all going to merge. I find the debate about if SAS is dead or not so ridiculous. There's like, companies will need to deliver value and if you don't leverage AI, you're not going to be able to deliver value. And this is so every company out there to some extent will be an AI company and these companies will need security. Ah, I would answer that question almost like my 13 year old son. Um, that's my take on it. And if the acronyms and abbreviations could someday go away, that would be good news for all of us.
Speaker B: Yeah, fair enough.
Speaker C: Well guys, it's been a pleasure to have you both and to cover such a broad topic in which we could keep on going because there's tons of questions I could ask you, but if somebody wants to get in touch with you, what's the best way? David Johannes.
Speaker B: For me it's email. I still use emailavidchat.com for me it's definitely LinkedIn.
Speaker A: Um, you'll definitely find us on LinkedIn and some more fun videos there. And Adidas training suits.
Speaker C: So iconic, right? Iconic. Well, with that guys, see you later. And everyone, until next time.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.