Podcast Episode 77

Episode 077 37 min

Inside Augment Code: Why security starts at line one

with Dirk Meister

0:00 / 37:00

Also on Spotify, Apple Podcasts, YouTube, Podbean, Player FM

Episode 77 of The Security Podcast of Silicon Valley. Hosts Jon McLachlan and Sasha Sinkevich, co-founders of YSecurity, talk with Dirk Meister, a founding engineer at Augment Code from 2022 to 2025 and now a staff software engineer at Google. Dirk explains why he doesn't think of himself as a security person even though much of his work is security, why getting the architecture right early makes everything easier later and getting it wrong can kill a company, swim lanes for personal data, the questions about architecture that no checkbox can answer, proof of possession, the design in which an engineer must prove they hold a source file before Augment uses it so that the shared ninety percent of a repository is usable by the team and the private ten percent only by its owner, why a stolen API token reaches the service but not the source code, why security teams are only five to ten percent of a company and if only the security team cares you lost, the big ask of sending source code to the cloud, customer managed keys and the ability to not trust the vendor, cryptographic deletion, support access that opens only with a business reason for a limited time and a limited set of data and is checked at the lowest level of database access, his time leading the CI team at Databricks during FedRAMP Moderate, Pure Storage, SOC 2 Type 2 and ISO 42001, AI for code as augmentation rather than replacement with a healthy amount of mistrust, the fundamentals that don't change, leaving Databricks, outages and camaraderie, writing simply without lying, and the mentors from his apprenticeship in Germany to his PhD. Published September 10, 2025. About 37 minutes.

Episode notes

What if your first lines of code determined your startup’s ability to scale? Dirk Meister, founding engineer at Augment Code, walks us through the intentional security architecture decisions they made on day one—and why trust isn't something you can bolt on later.

Hosted by Jon McLachlan and Sasha Sinkevich — co-founders of YSecurity.

The deep dive

Architecture is sticky

Dirk Meister joined Augment Code as a founding engineer when it had four people, and did much of its early product security work without ever thinking of himself as a security person. He explains proof of possession, the design that lets a stolen token reach the service but not the code, why customer managed keys give customers the ability to not trust the vendor, how support access opens only with a reason and a time limit, and why getting the architecture right on day one is what makes the certifications quick later. Here is the conversation with the public record beside it, his path from an apprenticeship in Germany to AI for code, and four tools to run against your own product.

By Jon McLachlan, host 32 min read

The most useful security idea in this episode started as a product question.

“We use this concept, we call it proof of possession, where an engineer has to prove to the system that they are in possession of a certain source code file, and then only we are reusing it.”

Dirk Meister, at 5:57

Listen · Dirk on episode 77, from 5:57
About 29 seconds: the ninety percent of a repository everyone shares, the ten percent only you have, and why nobody else can use yours. The clip stops on its own. Read the full transcript.

Dirk Meister was a founding engineer at Augment Code, the company building AI for software teams with large codebases, from September 2022 to December 2025. By his own account he joined when the company had four people, a few months before ChatGPT launched, and he built much of the production system: model serving, code indexing and retrieval, deployment, monitoring and security. Before that he spent almost eight years at Pure Storage and a year leading the CI team at Databricks, and before that he earned a PhD in Germany on data deduplication, after starting his career as an apprentice straight out of school. A note on where we sit, because it shows on the tape: when Sasha and I recorded this, I was Augment Code’s head of security, and YSecurity has run Augment’s SOC 2 Type 2 and ISO 42001 programs since 2024, so we talk about the company in the first person. Everything on this page about Augment comes from the tape or from what Augment and Dirk published. We published the episode on September 10, 2025, and the show notes were 42 words. This page is the rest of it: proof of possession, why a stolen token reaches the service and not the code, why Dirk doesn’t call himself a security person, why architecture is sticky, the questions that don’t fit in a checkbox, the big ask of sending source code to the cloud, customer managed keys and the ability to not trust the vendor, support access with a reason, the CI team in the middle of FedRAMP, the certifications, augmented and not replaced, the hardest day and the best ones, writing simply without lying, and what Dirk did after we hit stop. There are four things to try along the way: a quiz, a scorecard for whether your trust is built into the architecture, a calculator for how much standing access to customer data you have, and a timeline you can filter.

Ninety percent shared, ten percent yours

I asked Dirk whether, in the early days, an engineering problem had turned into a nice engineering solution with a security benefit. He went straight to the design he is known for inside the company. An AI coding assistant gets better the more of your code it can draw on, and in a company most of that code is shared.

“So like when the ninety percent of the repository that is shared between all engineers in the company, they prove that they have access to the shared files and then we complete out of that, and the ten percent they only have access to, then only they can get access to, because nobody else can prove possession of that file.”

Dirk Meister, at 5:57

The reason the ten percent matters is human, and Dirk was honest about it. “People shouldn’t put secrets or tokens into files, but let’s also be honest, that sometimes happens.” If the assistant completed from somebody else’s private files, “maybe they’re preparing a bash command or something like that, that would be horrible.” So even inside one enterprise, engineers are kept separate. The mechanism is in a post Dirk co-wrote with Markus Rabe in January 2025: Augment keeps “a real-time index of your codebase, for each user,” and before any content is used, “the IDE must prove to the backend it knows a file’s content by sending a cryptographic hash” (Augment Code).

Top row: shared files, about 90 percent of a repository, usable by everyone who has them, your private files, about 10 percent, filled, usable only by you, and someone else's files, dashed, which nobody else can prove. Bottom row, a chain: the IDE hashes the file it already has, the backend checks the hash against the index, and only then is the content used. Below: completions draw on shared code for the whole team, while a private file, perhaps a script with a token in it, never shows up in a colleague's completion.
The index is per user, and the proof is the file itself. Nobody can borrow what they can't hash.

“So this is proof [of] possession that came early on out of a product question, but I think it ended up really beneficial from a security perspective.” That sentence is the episode in miniature. Nobody wrote a policy that said engineers must not see each other’s secrets. The system was built so that it couldn’t happen, which is the kind of control that holds up when a policy wouldn’t.

A token reaches the service, not the code

I wanted to make sure I understood the strength of it, so I played it back: if someone took over my Augment Code account and tried to trick it into suggesting code from what I had already uploaded, they couldn’t, because they would have to prove they already had the files. Dirk put it more precisely.

“But like you cannot, with just the API token of a user, you cannot get access to the source code the user might have uploaded six months ago or a minute ago.”

Dirk Meister, at 13:24

Listen · Dirk on episode 77, from 13:24
About 30 seconds: what a stolen API token can and can't do. The clip stops on its own. Read the full transcript.

A stolen token still lets someone use the system, “more than, than you’re allowed to do, or something like that,” which is a billing problem. “It does not grant access to the source code that was uploaded before. I think that’s an important difference.” It is a big one, and it is why I called it an incredibly powerful security position on the tape.

“That’s an incredibly powerful, like, security position to take, because now, like, a breach of credentials, which usually would mean like a breach of like the data that the credentials are protecting, is not actually a breach of the data.”

Jon McLachlan, at 13:55

Two rows of three boxes. The usual design: a stolen token, dashed, reaches the service, which accepts it, and through it the stored data, filled, everything the account could see. With proof of possession: the same stolen token reaches the service, which is usable and billable, but a bar stops it before the stored code, which needs the files themselves. Below: usually a breach of credentials is a breach of the data, while here the token grants access to the system, not to code uploaded earlier.
Most breaches start with a credential. This design makes the credential worth much less.

Most incident reports start with a credential that was phished, leaked in a repository or lifted from a laptop. The usual answer is to protect the credential harder, with shorter lifetimes, device binding and more factors, and all of that is worth doing. Proof of possession adds a second idea: make the stored data unreachable with the credential alone. It is the same instinct as the 30-minute credential inventory, turned around. Instead of only asking what each key can reach, design the system so that the most valuable thing isn’t reachable by a key at all.

Not a security person

My first question to Dirk was whether he thinks of himself as a security person. “I actually don’t, but a lot of the work that I do is security, and I’m thinking about it.” He did a lot of Augment’s initial product security work and tried to make sure the right foundations were built to extend later. “But I’m not a security expert, I’m just really passionate about like getting that right, for us and for our customers.” Later in the conversation he explained why that distinction matters to him, with some arithmetic.

“Because security teams are only like what, five percent of a company, ten percent of a company. So 90% of the company is not the security team, the people that think about security all day long.”

Dirk Meister, at 7:37

Listen · Dirk on episode 77, from 8:28
About 42 seconds: five to ten percent of a company, and the question to ask about the other ninety. The clip stops on its own. Read the full transcript.

Sasha had asked what customers should be asking about how a vendor protects the crown jewels. Dirk’s answer was that everybody says yes when you ask whether their engineering takes security seriously, so the useful question goes past the security team and tries to gauge the culture outside it. “Because if only the security team cares, you lost.” Most of the people who care about security at Augment, he said, were normal engineers on normal teams, spread around the organization, “have their ears on the ground.”

Two horizontal bars: the security team, the people who think about security all day, is five to ten percent of a company, filled, and everyone else is ninety percent, outlined. Below: everybody says yes when asked whether engineering takes security seriously, so the useful question goes past the security team to the culture outside it, where most people who care about security should be normal engineers spread around the organization.
The security team is the smaller bar. The culture lives in the bigger one.

I’ve been on the other side of this, in a large engineering organization with a siloed security team, where security champion programs try to spread the knowledge one training at a time. It works, slowly. At Augment the culture came from the top, from the founders and the chief executive, and the reason was simple: customers were turning over their source code. That is the part of the episode I would hand to any founder hiring a first security person. The hire matters, and how you staff it matters, and none of it works unless the engineers who write the code own the outcome too.

Architecture is sticky

Sasha asked why security should come early, when a young company usually treats it as overhead. Dirk’s answer was his whole philosophy of engineering.

“Like when you get your architecture right, everything else becomes easier later. When you get your architecture wrong, everything becomes harder and harder. And I have seen companies dying on these kinds of mistakes.”

Dirk Meister, at 1:21

His example was personal data. If you introduce the right swim lanes at the beginning and know where data flows, then two years in “we don’t have to find out like, oh, some data is there and some data is a different place and somebody has like a shadow IT somewhere.” Otherwise you step back and redesign everything, which stops the company, and the cost “is not only in money but also time that it takes to redesign.” When I asked about his superpower, he came back to it: “five percent of thinking on a whiteboard or on a piece of paper can save you months and months later.” He was just as clear that this is a balance. A startup has to find product-market fit, iterate fast and take on tech debt, “but in a conscious way.” And it is a long race. “Startup is a marathon. It’s not a sprint.”

Two rows of three boxes. Get the architecture right: day one, five percent of thinking on a whiteboard, filled, data in swim lanes so you know where the personal information is, and year two spent on the next feature, not a rewrite. Get it wrong, all dashed: ship it and fix it later, data everywhere with shadow IT somewhere, and in year two a redesign that stops the company. Below, Dirk's line that code can always be fixed but architecture is sticky, and that tech debt is fine when taken consciously.
The cheapest security decision is the one made on a whiteboard before the first service exists.

He gave the idea its shortest form in a post he wrote in January 2026, looking back on his time at Augment: “Code can always be fixed, but architecture is sticky,” and “I strongly believe security and trust is hard to bolt on later” (Dirk Meister). Security people have been saying a version of the second sentence for a long time. One of the best was on Hacker News in 2008.

"It would be nice if that were possible, but experience has indicated that security cannot be bolted on after the fact."

cperciva, on Hacker News, August 2008

That was Colin Percival, then FreeBSD’s security officer, answering a post that suggested you could add application security later with a module. Seventeen years later the founding engineer of an AI company said the same thing about a product that didn’t exist in 2008, which is the best evidence there is that it’s true.

The questions a checkbox can’t answer

Sasha pointed out that the foundations Dirk described build trust with prospects in a way that checkbox security doesn’t. Dirk agreed, and was careful about it. For Augment, which stores its customers’ source code, “security is like checkbox for them, but it’s also not checkbox for them.” The questionnaire still matters. What builds trust is being able to show “this is really how our architecture is built,” so the customer concludes “these are people who like know what they’re doing, who we can trust.”

“[The] questions that you cannot answer with the checkbox are, I think, the most important questions. Is the architecture built for security? Is not a checkbox, it’s complex, it’s messy, it’s not easy to answer.”

Dirk Meister, at 4:09

He didn’t claim to have a solution for scaling those conversations, and nobody does yet. What a vendor can do is make the architecture explainable, the way he did in public, and answer the questionnaire in a way that points at it. We wrote about the gap between a setting being on and a control actually working in enabled isn’t enforced, and about the format buyers use in what a DDQ is. The questions Dirk describes are the ones that come after the checkboxes, on a call with the buyer’s engineers.

We are asking a lot

I said on the tape that customers hand over their source code because they want their engineers to enjoy this new technology, and that there’s an adoption question underneath it: what happens to our code in the cloud? Dirk didn’t soften it.

“We are asking a lot. We are asking a lot from our customers. Like we are asking from them, hey, if you want to use our product, we need your source code to really, really work. That’s, that’s a big ask.”

Dirk Meister, at 11:37

Everyone would prefer the same quality without the code, he said. But with large code bases and complex organizations, the system relies on indexing the code base and getting the patterns out of it, so the only honest answer is to earn the trust: “it’s not something unimportant to them, it’s something that is really important to them, and we want to earn the trust as good as we can from as many people as we can.” Augment had launched publicly in October 2024, with co-founder Igor Ostrovsky putting the bet in one line.

Augment's co-founder, formerly chief architect at Pure Storage, on launch day. Codebase knowledge is the product, which is why the codebase needs protecting. View on X.

Dirk’s February 2025 post on the platform’s security set out the promises that go with the ask. “We do not train on your code or your messages, nor can engineers read them by default,” and the proof of possession system “ensures the AI only sees the code you’ve explicitly granted it access to” (Augment Code). The company said the same thing in a few lines that spring.

Four commitments that are architecture, not policy. Each one is a design decision someone made early. View on X.

The ability to not trust us

Sasha brought up customer managed keys, which Augment had added quickly because of how the system was already built, and asked Dirk why they matter. His answer is the best line in the episode.

“And the trust here comes from the ability to not trust us.”

Dirk Meister, at 21:39

Listen · Dirk on episode 77, from 21:39
About 40 seconds: the ability to walk away, and data that turns into random bytes. The clip stops on its own. Read the full transcript.

The customer holds a cryptographic key and gives the vendor access to it, and if they ever want to walk away, they revoke it. “We don’t have to delete anything. Even when we don’t delete anything, we are, we are like, it’s useless to us. It’s just now random bytes.” Sasha called it cryptographic deletion, and Dirk agreed: the files, the data and the rows are all still there, “they are useless.” Augment made it live for enterprise customers on April 16, 2025, describing it as a key “you manage in your own environment,” and “If access to the key is ever revoked, Augment loses access to your data” (Augment Code).

The launch. The word that matters is "immediately": revocation is one change on the customer's side, not a deletion request. View on X.
Four boxes in a row: the key, filled, lives in the customer's cloud, the customer grants access so Augment can decrypt, the customer revokes it with one change on their side, and the data becomes random bytes, dashed, with nothing to read. Below: trust comes from the ability to not trust the vendor, revocation works as cryptographic deletion without deleting a row, and it was a swift project because the team knew where all customer data lived.
The customer keeps the off switch. That is what makes it safe to turn on.

The reason it was quick is the architecture section again. “Because we knew exactly where our data is and how our data is stored, and we controlled the access to the data very tightly, it was a really swift project to add CMK to all the customer data in a way that’s transparent to the customers.” It wasn’t a rewrite, and nobody had to go find all the data first. A team that has to search for its own data before it can encrypt it is a team that will find some of it later, in an incident.

Access with a reason

I asked Dirk what he is most proud of in the system. It wasn’t a feature. It was a trade-off: how to keep security by default, with no access to customer data at all, and still be able to help a customer who asks for support.

“So it’s not about shutting everything down. It’s leaving this controlled holes that, on customer demand, we can look at the pieces that are relevant to the customers when they ask us to look at.”

Dirk Meister, at 23:00

Engineers can ask for access with a business reason, linked to a support ticket, and get it for a limited amount of time and for a limited set of data, “not the complete data.” Then the detail that makes it real: the check is not done once in the support website or the extension. “It’s a check that we do to the lowest level of the database access, so that it’s much more difficult and, I hope, impossible to, uh, circumvent.” Augment’s own description adds the second person: each request “is time-limited, audited and requires approval from a second person” (Augment Code).

Four boxes in a row: by default, dashed, no access at all, then a support ticket where the customer asks, then a request with a business reason, a scope and a time limit, and finally the check, filled, enforced at the database layer. Below: controlled holes that open on customer demand for the relevant pieces, a limited set of data for a limited time approved by a second person, and enforcement at the lowest level of database access rather than only in the front end.
Every hour of access has a ticket, a reason and a second approver behind it. The calculator below counts the hours.

I called it security in layers that goes all the way down into the infrastructure and connects to a real business need, and I’d add one thing for anyone building the same. The hard part is not the approval form. It is putting the check where the data is, so that a bug in a dashboard can’t skip it. The calculator further down compares standing access to this kind of grant for your own team.

The CI team in the middle of FedRAMP

Dirk got interested in security a little before Augment. At Databricks he was tech lead of the team responsible for continuous integration: all the test infrastructure, what gets tested, and also what can be merged to the main repository and what can be deployed. Databricks was going through FedRAMP Moderate at the time, and his team was in the middle of it.

“Can you bypass these checks? [Who] bypasses checks? How do we do glass breaking? How do we merge? What code is secure and trusted? What code is not secured?”

Dirk Meister, at 15:12

When he decided to leave for Augment, it stuck with him that Augment was “as security relevant and asking as much from our customers as Databricks [is] asking from their customers,” and he took the lessons with him. His LinkedIn fills in the rest: at Databricks he scaled the CI system, Runbot, by four times, and before that he spent from November 2013 to July 2021 at Pure Storage, which he joined, he said, at about sixty engineers and two hundred employees, leaving as a principal engineer who led engineering productivity (LinkedIn). Igor Ostrovsky, Augment’s co-founder, had been Pure Storage’s chief architect, and Dirk’s own account is that a former colleague invited him to the new AI for code effort. If you want to see the engineer before the AI, here he is in 2019, explaining Pure Storage’s portable snapshots at Cloud Field Day.

April 10, 2019: Dirk, then technical lead for snapshot mobility at Pure Storage, on self-describing snapshots that keep their metadata and compression and only send the changes, about sixteen minutes. Watch on YouTube.
A timeline of Dirk Meister's career in six entries: an apprenticeship as a software engineer in Germany after school, a bachelor's and master's at Paderborn and a PhD at Mainz on data deduplication from 2003 to 2013, Pure Storage from 2013 to 2021, joining at about sixty engineers, Databricks from 2021 to 2022 as tech lead of the CI team during FedRAMP Moderate, Augment Code from 2022 to 2025 as a founding engineer when the company had four people, filled, and Google from 2026, dashed, after his last day at Augment on December 5, 2025.
Storage, then the systems that decide what code may ship, then AI for code. Each step is about what the system allows.

The thread through all of it is the question his CI team asked under FedRAMP: who can get around this check? It is the same question behind proof of possession and the database-level access check, asked by someone who spent his career on the systems that decide what is allowed to happen.

Landing the checkboxes faster

When Dirk talked about getting the security fundamentals wrong, “you will have big projects, big rewrites,” I picked up the other side of it: when you get them right, a whole bunch of other things fall into place, faster product-market fit, adoption in larger and larger organizations, and certifications.

“You can land certifications, even though those are just checkboxes, you can land them much more quickly, like SOC 2 Type 2.”

Jon McLachlan, at 19:29

I said on the tape that Augment was, I thought, the first engineering AI platform with a SOC 2 Type 2, and Dirk said he thought so too. The record is more modest than our memory, and it’s still good. Augment’s attestation came on July 10, 2024, after an observation window from April 1 to July 1, and its announcement said “other AI tools, like GitHub CoPilot, have yet to reach this level of SOC2 Type II” (Augment Code). That is a comparison at the time, not a first, so treat my line on the tape as enthusiasm. ISO/IEC 42001, the management system standard for AI, is better documented: Augment announced the certification on May 29, 2025 (Augment Code), and its certification body’s release was headlined “Augment Code Becomes First AI Coding Assistant to Achieve ISO/IEC 42001 Certification from Coalfire Certification” (Coalfire). My line about Augment being the thirty-somethingth company in the world to get it is from memory, and I couldn’t find a published count to check it against.

A timeline of six entries. July 10, 2024, the SOC 2 Type II attestation after an observation window from April 1 to July 1. January 2025, Augment's real-time index post by Dirk and Markus Rabe, describing the hash that proves possession. February 2025, Dirk's post on the security architecture, with no training on code and time-limited access approved by a second person. April 16, 2025, customer managed keys go live. May 29, 2025, ISO/IEC 42001, which Coalfire's August release calls a first for AI coding assistants. September 10, 2025, this episode.
The certifications were fast because the architecture was already written down.

Because YSecurity ran both programs, I can say what made them quick, and it was mostly what this page is about. The data flows were known, access to customer data was already gated, and the controls were in the system rather than in a document. We wrote the engagement up as case studies, SOC 2 Type 2 in five months and ISO 42001 in 93 days, and the phase-by-phase timeline is in how long a SOC 2 audit takes. Dirk added the customer’s side: some of Augment’s users are security conscious “sometimes to a painful extent,” and “they look at us [very] deeply, and they come out and say yes, that’s, that’s the one that we can trust.”

Augmented, not replaced

Sasha asked what advice Dirk would give a new engineer or a founder. He called himself an old schooler: foundations matter, and computer science is not overhead. Then he turned to the tools he builds.

“If you trust the AI completely and you don’t read it anymore, you will be in quite a problem in six months.”

Dirk Meister, at 28:17

Listen · Dirk on episode 77, from 28:38
About 32 seconds: balance, the engineer on the other side, and a healthy amount of mistrust. The clip stops on its own. Read the full transcript.

It is still the engineer on the other side that matters, he said, from someone who built AI for code professionally. “This company is called Augmented, not Replaced, for a reason.” Use the AI as much as possible, “but don’t trust it. Always have a healthy amount of mistrust. Be curious. Stay learning.” I’d put it the way I put it for agents: the software is ours, the prompts are ours, and so are the results, so we understand it, test it and keep a playful sense of adventure about what it can do. Dirk’s list of what doesn’t change is the useful part. The fundamentals of computer science and software engineering, and the skill of getting requirements out of people that actually hold, like translating what a salesperson is really asking for. “It’s a skill set that was valuable twenty years ago. I deeply believe it will be a skill set that is really important to you in 20 years.”

He went further back than that. Software engineering has been a team sport for a long time, and “when you look back to like the classical papers about software engineering of like Fred Brooks,” the problems they solved are the ones we solve now. Brooks’s The Mythical Man-Month came out in 1975, and its most famous line is still true: “Adding manpower to a late software project makes it later” (Wikipedia). The work of review, the same discipline we wrote about in agentic code review and SOC 2, is how you keep the mistrust healthy without slowing everything down.

The hardest day, and the best ones

I asked about his most difficult day. It was leaving Databricks, a company with a fantastic culture that was doing well. But the chance to build something new came along, at a time when AI for code wasn’t yet the hot topic it is now.

“And I think AI for code is [the] biggest change in how software is written, at least in the last thirty, forty years. Being part of that was something that I really wanted to do. But it was a really tough day.”

Dirk Meister, at 25:02

I said you need a sense of adventure for that, the decision that the world is changing and you want to be part of it. He agreed, and added the line I’d put on a wall: working at a startup as a founding engineer, “[when] you’re getting comfortable, you’re doing something wrong.” Would he have believed six years earlier that he would work on product security? “No.” Sasha asked about the brightest day, and Dirk picked the darkest ones: a big outage, when engineering and leadership come together, work through a tough problem and restore the service. “So it’s, it’s like this [camaraderie] that comes out of, uh, this intense pressure.” Those are the days he looks back on most fondly.

Write it simply, and stay truthful

My last question was the one I ask everyone: what would you tell your younger self? Dirk was a math kid who didn’t see the point of learning to write, or of learning English, living in Germany. “I think I was wrong. I think writing is a really important skill.” He learned it in technical writing courses at university, and now gives the same advice to the early career engineers he mentors. I plugged the articles he had written for Augment, which explain hard ideas plainly, and he gave the rule he writes by.

“And you want to do it as simple as possible without going to the point of lying. Like you can explain everything simple, but sometimes you’re like, that’s actually no longer true.”

Dirk Meister, at 33:11

Find the right abstraction for the right person and stay truthful, because “it’s all about trust,” he said, “especially, I think, in security.” It is also how he explained proof of possession on this show, and how he wrote it up in public, which is why the design is easy to check. Sasha asked who had made the biggest impact on his career, and the answer was a set of people, not one: mentors at his apprenticeship after high school who guided him to university when he hadn’t gone straight from school, then on to a PhD, and the smart people he has looked for at every company since, “standing on the shoulders of giants.” His PhD was at Johannes Gutenberg University Mainz, on advanced data deduplication techniques, after a bachelor’s and master’s at Paderborn University (LinkedIn). And he likes an office: a whiteboard, coffee talks, and, as an introvert, the forcing function of being in the same room.

What happened after the tape

Dirk’s last day at Augment was December 5, 2025, and a month later he wrote up the whole journey, from storage to engineering productivity to AI for code (Dirk Meister). It is the best companion to this episode. He describes joining as a founding engineer when the company had four people, building a custom inference stack for embedding models, an indexing system that handled thousands of files per second, CUDA kernels and the TypeScript of the VS Code extension, and why latency is a product feature: “A good code completion that appears after 300ms will be accepted by developers,” and “The same completion arriving after 700ms? Too late.” He also names the two Augment posts he co-wrote, on the security approach and the real-time index, as the place to read the design. In January 2026 he joined Google as a staff software engineer (LinkedIn).

“I strongly believe security and trust is hard to bolt on later.” He wrote it after he left, and it is what he said on the tape, which is the best sign that it was never a slogan.

Did you catch it? A six-question quiz

Interactive · six questions

Did you catch it?

Six questions on what Dirk actually said, with the timestamp for each answer. The answers are under each question for anyone reading without JavaScript.

  1. What does proof of possession require before Augment uses a source file?

    1. A manager's approval for each repository
    2. Proof that the engineer is in possession of that file
    3. A second login from a trusted device

    b. "an engineer has to prove to the system that they are in possession of a certain source code file, and then only we are reusing it." Transcript, 5:57.

  2. What can someone do with a stolen user API token, in Dirk's words?

    1. Use the system, but not read the source code uploaded before
    2. Download the user's whole repository
    3. Nothing, because tokens can't be stolen

    a. "It does not grant access to the source code that was uploaded before." Transcript, 13:24.

  3. Where does the trust in customer managed keys come from, according to Dirk?

    1. From the audit report
    2. From the encryption algorithm
    3. From the ability to not trust the vendor

    c. "And the trust here comes from the ability to not trust us." Revoke the key and the data is random bytes. Transcript, 21:39.

  4. What was Databricks going through when Dirk led its CI team?

    1. An initial public offering
    2. FedRAMP Moderate certification
    3. A move to a new cloud provider

    b. "At the time, Databricks was going through their FedRAMP Moderate certification process." Transcript, 15:12.

  5. What share of a company is the security team, by Dirk's estimate?

    1. Five to ten percent
    2. About a quarter
    3. About half

    a. "security teams are only like what, five percent of a company, ten percent of a company." Transcript, 7:37.

  6. What did Dirk do right after high school?

    1. Went straight to university
    2. Joined Pure Storage
    3. Worked as a software engineer apprentice

    c. "I started working as like a software engineer apprentice, and I found great mentors there." Transcript, 33:55.

Is your trust built into the architecture?

Dirk’s test for a vendor is whether the architecture was built for security, which no checkbox can answer. This scorecard asks eight questions about your own product, in the order the episode raises them, and tells you whether your security is a checkbox, present in places, or in the architecture.

Scorecard · eight questions

Is your trust built into the architecture?

Answer for the product that holds your customers' most sensitive data, as it runs today. If two answers fit, pick the lower one.

  1. Do you know where every kind of customer data lives, including personal data?

    • Not really, and there is some shadow IT
    • Mostly, for the main production systems
    • Yes, by design: swim lanes, owners and a data-flow map kept current

    "we know where data flows all the time." It is what made customer managed keys a swift project instead of a search.

  2. If an attacker steals one user's API token, what can they read?

    • Everything the account can see, including stored content
    • Only data within a narrow scope
    • The service, not the stored data: reading content needs a second proof, such as possession

    "you cannot get access to the source code the user might have uploaded six months ago or a minute ago." The token section has the design.

  3. Inside one customer, can one user's private data show up for another user?

    • Yes, everything is shared within the account
    • Role-based separation, enforced in the application
    • Per-user separation enforced on the server, for private data like the ten percent

    Secrets end up in files. A colleague's completion should never contain them.

  4. Who holds the keys to your customers' data?

    • The cloud provider's defaults, and nobody has thought about it
    • Encrypted at rest with keys you manage
    • Customers can hold their own key and revoke it, which works as cryptographic deletion

    "the trust here comes from the ability to not trust us."

  5. How do your engineers get access to customer data?

    • Standing access to production data
    • By request, but broad and long-lived
    • Time-limited, scoped to a support case, approved by a second person

    The calculator below turns your answer into access-hours a week.

  6. Where is that access check enforced?

    • In the user interface
    • In the application's API
    • At the lowest layer, on the path to the database or storage itself

    "It's a check that we do to the lowest level of the database access." A bug in a dashboard shouldn't be able to skip it.

  7. Do you train on or keep customer content?

    • By default
    • By default, with an opt-out
    • Never by default, and engineers can't read it by default either

    A commitment to no training or retention unless explicitly allowed is only as good as the architecture that enforces it.

  8. Who cares about security in your company?

    • The security team, if there is one
    • Champions in some teams
    • Engineers on every team, with security as their partner

    "Because if only the security team cares, you lost."

Security as a checkbox

The questionnaire answers are probably true, and the architecture underneath them isn't doing much of the work: a stolen token reads stored data, access to customer data is standing, and nobody could say exactly where the personal data lives. Start with the map. Write down where every kind of customer data lives this week, then put a time limit and a second approver on every human path to it.

Security in places

Some of the right decisions are in the system, and some are still in a policy. Move the access check down to where the data is, separate users inside an account for the data that is theirs alone, and design so that a credential reaches the service without reaching the stored content.

Security in the architecture

A stolen token reaches the service, not the data, customers can hold their own keys, access to their data opens only with a reason and closes on its own, and the culture doesn't depend on the security team. Write it up the way Dirk did, simply and truthfully, so a buyer's engineers can check it.

How much standing access do you have?

Dirk is proudest of the trade-off between no access by default and access for support. This calculator compares the two for your team: how many hours a week customer data is open to engineers with standing access, how many it would be if access opened only for a support case, and how much smaller that is.

Calculator

How much standing access do you have?

Engineers who can read customer data today, the support cases a week that actually need it, and how long a just-in-time grant stays open.

–engineer-hours of access a week today
–engineer-hours with a grant per case
–times less access
–access-hours removed a year

With 20 engineers who can read customer data 168 hours a week, customer data is open for 3,360 engineer-hours a week. If access opened only for a support case instead, 10 cases a week at 4 hours each is 40 engineer-hours, about 84 times less, or 172,640 fewer access-hours a year, and every remaining hour has a ticket and a reason behind it.

An access-hour is one engineer able to read customer data for one hour, whether or not they do. It counts exposure, not use, which is the point: a stolen laptop or a phished engineer with standing access is open every hour of the week. The 20 engineers, 10 cases and 4-hour grants are placeholders, not research. Augment's design added a second approver to every request and enforced the check at the database layer, which this calculator doesn't model.

From Paderborn to proof of possession

Everything on this page sits on one timeline, from Dirk’s first degree to the month he joined Google. Filter it by thread.

Timeline · 1975 to 2026

From Paderborn to proof of possession

Filter by thread. Dates are from the public record except where marked as Dirk's own account on the tape.

  1. The Mythical Man-Month

    Fred Brooks's book, the classic Dirk points to (Wikipedia).

  2. An apprenticeship

    A software engineer apprentice in Germany, and mentors who pushed him toward university.

  3. Paderborn University

    A bachelor's and a master's in computer science (LinkedIn).

  4. "cannot be bolted on"

    Colin Percival on Hacker News, on adding application security after the fact (Hacker News).

  5. A PhD at Mainz

    Advanced data deduplication techniques, Johannes Gutenberg University Mainz (LinkedIn).

  6. Pure Storage

    Through July 2021, ending as principal engineer for engineering productivity (LinkedIn).

  7. Portable snapshots

    Dirk presents at Cloud Field Day 5 (YouTube).

  8. Databricks

    Tech lead of the CI team, during FedRAMP Moderate, by his account on the tape (LinkedIn).

  9. A founding engineer

    Augment has four people, and ChatGPT hasn't launched yet (Dirk Meister).

  10. Out of stealth

    A $227 million Series B, with founders Igor Ostrovsky and Guy Gur-Ari (Business Wire).

  11. SOC 2 Type II

    The attestation, after an April to July observation window (Augment Code).

  12. Augment Code launches

    "AI + codebase knowledge" (X).

  13. A real-time index

    Per user, with a hash to prove possession, by Dirk and Markus Rabe (Augment Code).

  14. Securing the code that writes code

    Dirk's post on the platform's security (Augment Code).

  15. Customer managed keys

    Live for enterprise customers (Augment Code).

  16. ISO/IEC 42001

    Certified by Coalfire, a first for AI coding assistants (Coalfire).

  17. Episode 77 airs

    This conversation. "the ability to not trust us."

  18. A last day at Augment

    After three years and four months (Dirk Meister).

  19. "architecture is sticky"

    Dirk's look back at AI for code, and a staff software engineer role at Google (Dirk Meister).

What to do this week

Four things, in the order Dirk would do them.

  1. Draw the map. Write down where every kind of customer data lives, personal data first, with an owner for each store. Anything you discover along the way is the shadow IT Dirk warned about, and the map is what makes everything after it quick.
  2. Make a stolen token worth less. List what one user’s credential can read today. For your most sensitive stored data, add a second proof to reading it, the way proof of possession requires the file itself, and keep one user’s private data out of everyone else’s results.
  3. Close the standing access. Replace standing access to customer data with grants that are tied to a support case, limited in time and scope, approved by a second person, and checked where the data lives rather than only in the interface.
  4. Give customers the ability to not trust you. For the customers who need it, offer keys they hold and can revoke. Then write the whole design up simply and truthfully, so a buyer’s engineers can check it instead of a checkbox.

Key takeaways

  1. Proof of possession keeps private code private

    "an engineer has to prove to the system that they are in possession of a certain source code file, and then only we are reusing it." The shared ninety percent of a repository serves the whole team, and the private ten percent only its owner, because nobody else can prove possession of those files.

  2. A stolen token reaches the service, not the code

    "you cannot get access to the source code the user might have uploaded six months ago or a minute ago." A stolen API token lets someone use the system, not read the code that was uploaded before, so a breach of credentials is not a breach of the data.

  3. Secrets end up in files

    "People shouldn't put secrets or tokens into files, but let's also be honest, that sometimes happens." Completing from a colleague's private files would leak them, so engineers are kept separate even inside one enterprise.

  4. Architecture is sticky

    "Like when you get your architecture right, everything else becomes easier later. When you get your architecture wrong, everything becomes harder and harder." Dirk has seen companies die of these mistakes, and five percent of thinking on a whiteboard can save months later.

  5. Know where the data flows from day one

    Introduce swim lanes for personal data early and you won't discover in year two that data sits in a different place and somebody has a shadow IT somewhere. Otherwise a redesign stops the company, and it costs time as well as money.

  6. The important questions don't fit in a checkbox

    "[The] questions that you cannot answer with the checkbox are, I think, the most important questions. Is the architecture built for security?" The questionnaire still matters, and trust comes from showing how the architecture is built.

  7. If only the security team cares, you lost

    Security teams are five to ten percent of a company, so the useful question goes past the security team to the culture outside it. At Augment, most of the people who cared about security were normal engineers on normal teams.

  8. The ability to not trust the vendor

    "And the trust here comes from the ability to not trust us." With customer managed keys, a customer who revokes the key leaves the vendor holding random bytes, a cryptographic deletion with nothing deleted.

  9. A swift project because the data was mapped

    Adding customer managed keys to all customer data was quick and transparent to customers because the team knew exactly where the data was and controlled access to it tightly. It wasn't a rewrite.

  10. Access with a reason, checked at the bottom

    No access by default, and controlled holes on customer demand: a business reason linked to a support ticket, a limited time, a limited set of data, enforced at the lowest level of database access rather than only in the support website.

  11. Who can bypass the check?

    Leading the CI team at Databricks during FedRAMP Moderate taught Dirk to ask of every decision who can bypass a check, how glass breaking works, and what code is trusted, and he brought those lessons to Augment.

  12. Augmented, not replaced

    "If you trust the AI completely and you don't read it anymore, you will be in quite a problem in six months." Use the AI as much as possible, keep a healthy amount of mistrust, and invest in the fundamentals that aren't changing.

  13. Explain it simply without lying

    "And you want to do it as simple as possible without going to the point of lying." Writing is a form of communication, and in security especially, it's all about trust.

Chapters

Tap a chapter to play from there.

Pull quotes

“But I'm not a security expert, I'm just really passionate about like getting that right, for us and for our customers.”

Dirk Meister ·

“Like when you get your architecture right, everything else becomes easier later. When you get your architecture wrong, everything becomes harder and harder.”

Dirk Meister ·

“[The] questions that you cannot answer with the checkbox are, I think, the most important questions.”

Dirk Meister ·

“We use this concept, we call it proof of possession, where an engineer has to prove to the system that they are in possession of a certain source code file, and then only we are reusing it.”

Dirk Meister ·

“People shouldn't put secrets or tokens into files, but let's also be honest, that sometimes happens.”

Dirk Meister ·

“Because if only the security team cares, you lost.”

Dirk Meister ·

“We are asking a lot. We are asking a lot from our customers.”

Dirk Meister ·

“It does not grant access to the source code that was uploaded before.”

Dirk Meister ·

“That's an incredibly powerful, like, security position to take, because now, like, a breach of credentials, which usually would mean like a breach of like the data that the credentials are protecting, is not actually a breach of the data.”

Jon McLachlan ·

“And the trust here comes from the ability to not trust us.”

Dirk Meister ·

“So it's not about shutting everything down.”

Dirk Meister ·

“If you trust the AI completely and you don't read it anymore, you will be in quite a problem in six months.”

Dirk Meister ·

“And you want to do it as simple as possible without going to the point of lying.”

Dirk Meister ·

About the guest

Dirk Meister, Staff Software Engineer, Google

Dirk Meister is a staff software engineer at Google, which he joined in January 2026. He was a founding engineer at Augment Code from September 2022 to December 2025, joining when the company had four people, and built much of its production system: model serving and custom inference for embedding models, a real-time, per-user code index and retrieval system, deployment, monitoring and observability, and product security, including the proof of possession design that requires an engineer to prove they hold a source file before it is used. He co-wrote Augment's posts on its real-time index and its platform security. Before Augment he led the code and continuous integration team at Databricks during its FedRAMP Moderate certification, scaling its CI system, Runbot, by four times, and spent from 2013 to 2021 at Pure Storage, ending as a principal engineer leading engineering productivity. He started as a software engineer apprentice in Germany, then earned a bachelor's and master's in computer science at Paderborn University and a PhD at Johannes Gutenberg University Mainz on advanced data deduplication techniques.

Google ↗ LinkedIn ↗ From storage to engineering productivity to AI for code, Dirk's post, January 2026 ↗A real-time index for your codebase, Dirk Meister and Markus Rabe, Augment Code ↗Securing the code that writes code, Dirk Meister, Augment Code ↗Pure Storage Portable Snapshots, Cloud Field Day 5, April 2019 ↗

About the host

Jon McLachlan and Sasha Sinkevich are co-founders of YSecurity, the on-demand cybersecurity team for startups, and of Cyberbase.ai. The Security Podcast of Silicon Valley is hosted by Jon McLachlan and Sasha Sinkevich. Jon McLachlan on LinkedIn ↗Sasha Sinkevich on LinkedIn ↗

Context and sources

  • Dirk Meister and Markus Rabe, A real-time index for your codebase: secure, personal, scalable, Augment Code, January 2025: a real-time index for each user, and an IDE that must prove it knows a file's content by sending a cryptographic hash. Source ↗
  • Dirk Meister, Securing the code that writes code: a look inside our AI platform, Augment Code, February 3, 2025: proof of possession, no training on code or messages, and time-limited, audited access approved by a second person. Source ↗
  • Augment Code, Customer Managed Keys: your keys, your rules, April 16, 2025. Source ↗
  • Augment Code on X, April 16, 2025: customer managed keys live for enterprise customers. Source ↗
  • Augment Code on X, May 6, 2025: a platform built for high-trust environments. Source ↗
  • Augment Code, achieving SOC 2 Type II, September 5, 2024: an observation window from April 1 to July 1, 2024, and the attestation on July 10, 2024. Source ↗
  • Augment Code, the first AI coding assistant to be ISO/IEC 42001 certified, May 29, 2025. Source ↗
  • Coalfire's August 5, 2025 release: Augment Code becomes the first AI coding assistant to achieve ISO/IEC 42001 certification from Coalfire Certification. Source ↗
  • YSecurity case study: Augment Code's SOC 2 Type 2 in five months. Source ↗
  • YSecurity case study: Augment Code's ISO 42001 certification in 93 days. Source ↗
  • Augment Inc. raises $227 million at a $977 million valuation, Business Wire, April 24, 2024: co-founders Igor Ostrovsky, formerly chief architect at Pure Storage, and Guy Gur-Ari, and chief executive Scott Dietzen. Source ↗
  • Igor Ostrovsky on X, October 24, 2024, launching Augment Code. Source ↗
  • Dirk Meister, From storage to engineering productivity to AI for code, January 3, 2026: joining Augment when it had four people, the production system he built, his last day on December 5, 2025, and why security and trust are hard to bolt on later. Source ↗
  • Dirk Meister's LinkedIn experience: Google since January 2026, Augment from September 2022 to December 2025, Databricks from August 2021 to September 2022, and Pure Storage from November 2013 to July 2021. Source ↗
  • Dirk Meister's LinkedIn education: a bachelor's and master's at Paderborn University and a PhD at Johannes Gutenberg University Mainz on advanced data deduplication techniques. Source ↗
  • Pure Storage Portable Snapshots, presented by Dirk Meister at Cloud Field Day 5, recorded April 10, 2019. Source ↗
  • Colin Percival on Hacker News, August 2008: security cannot be bolted on after the fact. Source ↗
  • The Mythical Man-Month by Fred Brooks, 1975, and Brooks's law. Source ↗

Transcript

Automatic transcription, with speaker labels assigned by ear (there is no diarization on the tape), and a few of the hosts' lines may be swapped between Jon and Sasha. Names and product names were normalized where the recognizer misheard them (Jon McLachlan, Sasha Sinkevich, Dirk Meister, Augment Code, Databricks, Pure Storage, PII, FedRAMP Moderate, SOC 2 Type 2, ISO 42001, CMK, Fred Brooks). Bracketed words are best guesses where a syllable was lost. Timestamps are the start of each turn to within a couple of seconds.

Read the full transcript 6,109 words

Jon McLachlan

Hello, everyone, and welcome to another episode of The Security Podcast of Silicon Valley. I'm one of the hosts, Jon McLachlan. I'm joined with the other host, Sasha Sinkevich. And we are super excited to have an amazing guest with us today, Dirk Meister, a founding engineer at Augment Code. Welcome to the show, Dirk.

Dirk Meister

Thank you for having me.

Jon McLachlan

So Dirk, we're here on The Security Podcast of Silicon Valley. We've got the ear of the security community. Do you think of yourself as a security person?

Dirk Meister

I actually don't, but a lot of the work that I do is security, and I'm thinking about it. I'm like founding engineer at Augment, I work on like all the different things, especially from the product side. I did a lot of the initial product security work and tried to like ensure that the right foundations are built that like we can later extend on. But I'm not a security expert, I'm just really passionate about like getting that right, for us and for our customers.

Sasha Sinkevich

Why do you think it's important to get security right in the beginning of the life cycle of the product, especially when the company is just starting? Often security is seen as an overhead. Maybe there are good reasons why we should think about these certain security controls earlier than later.

Dirk Meister

I think that two answers to that. One is it's my general approach to software engineering and startups. Like when you get your architecture right, everything else becomes easier later. When you get your architecture wrong, everything becomes harder and harder. And I have seen companies dying on these kinds of mistakes. So I think a bit of thinking in the beginning: what do we want to do? Where do we want to end up? Even when the implementation is not there yet, but like getting the architecture right will pay extreme benefits later. And that extends to security, when you get your security architecture right in the beginning. And, um, that extends to later. For example, when we think about like PII, which like is not security itself, but closely related to that. When in the beginning we introduce the right swim lanes and systems and we know where data flows. We know where data flows all the time. Two years in, we don't have to find out like, oh, some data is there and some data is a different place and somebody has like a shadow IT somewhere. Then you built in the right infrastructure that people can work with, and you think about where we want to have data, and what do we want to store where, and what is PII and what's not PII. Later, when it then becomes really important, it's much, much easier. Otherwise, you have to like step back and do a redesign of everything, and like stops the company, and nobody wants that. And then when you redesign, it usually has an associated costs, and cost is not only in money but also time that it takes to redesign.

Sasha Sinkevich

But the foundational work that you just mentioned probably helps to build trust with the potential prospects and customers, because we're not talking about the checkbox security, we're talking about the proper implementation and security controls.

Dirk Meister

I think that's completely right. For Augment Code, we store the source code of our customers. That is really important to them. So, uh, security is like checkbox for them, but it's also not checkbox for them. I think when we as Augment talk with them, like, this is what we're doing, this is really how our architecture is built, it builds trust with them. Like, yes, these are people who like know what they're doing, who we can trust, who clearly have thought about it, but it's not like some afterthought that came in like two years later because something happened. But like from the beginning, oh yeah, how do we secure the customer data? Is part of the DNA of the company.

Sasha Sinkevich

Yeah. Do you think there is a question that is related to security and privacy the enterprise should be asking, but are not asking today, or not asking as often?

Dirk Meister

I don't know. I think that too often security is check boxes, and the check boxes are because this is like the agreed standard between companies and the prospect, this is what you are supposed to ask. I think eighty percent of these checkboxes are going to the core questions. [The] questions that you cannot answer with the checkbox are, I think, the most important questions. Is the architecture built for security? Is not a checkbox, it's complex, it's messy, it's not easy to answer. But I think is then really in product security, this is where the difference comes in. And I don't have a solution how to make that easy and how to scale that for companies and for prospects.

Jon McLachlan

Love the idea that security can make a real impact and can be very specific. You mentioned, uh, product security. And you mentioned engineering. And I think when engineering is done with a discerning eye, when you engineer a system with intent and you know what you're building, almost like you can isolate out the components that matter the most. And when you do that, you're actually like trimming things down, making a system simpler. Almost, you can just look at the system as simple as it is, as it needs to be, and have a much more confident answer that something is secure. And I'm super curious to hear: like in those early days, as a founding engineer at Augment Code, was there anything in particular, an engineering problem that kind of turned into a really nice engineering solution and resulted also maybe in a benefit for security too?

Dirk Meister

We use this concept, we call it proof of possession, where an engineer has to prove to the system that they are in possession of a certain source code file, and then only we are reusing it. So like when the ninety percent of the repository that is shared between all engineers in the company, they prove that they have access to the shared files and then we complete out of that, and the ten percent they only have access to, then only they can get access to, because nobody else can prove possession of that file. People shouldn't put secrets or tokens into files, but let's also be honest, that sometimes happens. So like when Augment would complete off somebody else's private files that nobody else has seen, maybe they're preparing a bash command or something like that, that would be horrible. So that's even within an enterprise that we keep the different engineers separated was an important decision on that side. So this is proof [of] possession that came early on out of a product question, but I think it ended up really beneficial from a security perspective.

Sasha Sinkevich

Those technical controls are super important. [We] speak about the actual security controls, not checkboxes, when we are talking about trust, building trust with a potential prospect or an existing customer. This goes back to the original question. What are some of the things that customers should be asking but are not asking? And questions around how do you protect the crown jewel? Because essentially, a prospect is given the control over that crown jewel, and it hands it over to the processor.

Dirk Meister

I don't know how to frame that as an easy answer. When you ask anybody, is your engineering taking security seriously? Everybody will say yes. Nobody will say no. Security is always a shade of gray. Like we try to do our best and think through it and do all the controls. Still not a one hundred percent. People might find, an attacker always might find one bypassing through the back door that we didn't, that nobody thought about. What customers should do, what prospects should do, is try to [get] past the checkboxes and see if people like, the best thing companies can hope for is that people take that seriously, not only in the security team. They might be facing this. Because security teams are only like what, five percent of a company, ten percent of a company. So 90% of the company is not the security team, the people that think about security all day long. If you, if you have a company where like 10% really care about security and 90% don't care about the security, that's not a good state to be. So I think the question people should ask, and I don't know what that question is, is getting past the security team and try to [gauge] what is really the culture. What is the culture outside of the security team? Because if only the security team cares, you lost. And I think that is why I don't see myself as a security person. I am, I'm part of engineering. I'm not part of the security team or like only caring about security. And most people who care about security at Augment are part of all normal teams, normal engineers, and like [spread] around the organization, have their ears on the ground.

Jon McLachlan

That's a very important mindset. I've witnessed firsthand the culture [at] Augment, where every engineer, every function that is executed, it's taken with the context of the security controls in mind: how do we do things making sure that the crown jewels are well protected. And I've been on the other side of this equation, where you have a large organization of engineers and a siloed security team. And for that reason, you hear about the security champion programs, where we constantly try to come up with ways to share that security knowledge. And that can be quite challenging. It can be time consuming to train or retrain the culture. I think in Augment, right, the security culture's coming in from the top. The culture there is all from, you know, it's coming in from Dietz, it's coming from Igor, it's coming in from Guy, and an incredible foundation, and the values are clear that customers are turning over their source code to Augment, into the cloud, right? And they're doing that because they want to enable their own engineering teams to enjoy this magical new technology of AI, and all of the AI augmentation to enhance engineering productivity, to help us write code, to help us write code more securely, to help us write more code more quickly with less bugs on complex systems. Um, and AI can be used to enhance all of that. But at the same time, like, there's an adoption issue, right? Like, okay, if we're going to put all of our code up in the cloud, what's going to happen with it? And a lot of the customers, I imagine, especially in the enterprise space, are cognizant of those security requirements, because those are their crown jewels, right?

Dirk Meister

We are asking a lot. We are asking a lot from our customers. Like we are asking from them, hey, if you want to use our product, we need your source code to really, really work. That's, that's a big ask. And everybody understands that. It would be easier if we couldn't, if we could do the same quality without it. Everybody would prefer that. It's just that with like large code bases, complex organizations, we, our system relies on indexing the code base, getting all the intelligence out of it, getting the patterns out of it. But like we understand, oh, we are asking a lot of these people, and we are aware of that, and we want to earn their trust that they allow us to do that. So I think that's the realization that it's not something that people do like nilly-willy. It's not something unimportant to them, it's something that is really important to them, and we want to earn the trust as good as we can from as many people as we can.

Jon McLachlan

Yeah, that's right. That's right. And so to go back to like the strength that proof of possession brings to the table. You know, if, if there is, you know, to just highlight what that means, because I was, I was digesting that as we were talking about it. And it seems like even if someone has access to my Augment Code account, and they're, they're malicious, and they, they try to trick Augment Code into using the context that's already been uploaded to produce code suggestions that would [divulge] this very sensitive IP, they would not be able to. Just because you have to prove that you have that context already. You have to prove that you have locally on your machine the, the, all of the IP that's already there. So it, it wouldn't even be possible.

Dirk Meister

Completely right. The access token in some sense is like, you, you can use the system, you can like defraud us of like using it more than, than you're allowed to do, or something like that. But like you cannot, with just the API token of a user, you cannot get access to the source code the user might have uploaded six months ago or a minute ago. So the, the access key, the access token, the access to the system does not, does grant access to the system. It does not grant access to the source code that was uploaded before. I think that's an important difference.

Jon McLachlan

That's an incredibly powerful, like, security position to take, because now, like, a breach of credentials, which usually would mean like a breach of like the data that the credentials are protecting, is not actually a breach of the data. It's just, it's just [a] breach to the access of the system. You could steal like the service, but you can't steal any of the data that's been uploaded unless you already have that data locally, which like you don't.

Dirk Meister

That's correct.

Jon McLachlan

So in security, you know, we have these journeys that we go on. And, you know, if we back up just a little bit, I would love to hear what inspired your entrepreneurial journey, because being a founding engineer, you're really there from the beginning. You know, you're thinking through a lot of these technical challenges that are being faced with these new use cases. And they're delicate. They're just as important to the success of the company as the marketing or the sales deals that go through. Um, because, as you put it, like, you know, these types of decisions can make or break whether or not something is even adoptable, whether or not something could scale, whether or not it will hold up. Um, and so you have a really interesting story. I feel like there's just, uh, and I'm, I'm curious to hear what's the inspiration behind it.

Dirk Meister

I've worked in like later startups most of my career, at Pure Storage, at Databricks. I joined Pure Storage when like sixty engineers, two hundred employees. So I was always in startups, but not as early as Augment. I was never in the, in the room in the beginning. And when like the excellent founders, and Igor, and the VP of Engineering, and other founding engineers contacted me years ago, hey, we are starting this new thing in engineering productivity, combining [with] AI, I said that, yeah, like it's a new thing. I can really build something from scratch with these excellent people in a field that I'm really passionate about. So [I've always cared] about engineering productivity. I said yes to that. Let's do something as early as possible. It is a really excellent team. I just got into, interested in security a bit earlier. When I was at Databricks, I was, uh, working on these, uh, CI team. The CI team at Databricks were responsible for all the test infrastructure, testing, what is tested, but also what can be merged to the main repository, what can be deployed. At the time, Databricks was going through their FedRAMP Moderate certification process. And the CI team, the team that I led as tech lead, was like directly in the middle of this transition of like, okay, we really have to think every decision we are doing through. Can you bypass these checks? [Who] bypasses checks? How do we do glass breaking? How do we merge? What code is secure and trusted? What code is not secured? And like that was a really fascinating journey. And when I made the decision to leave Databricks to join Augment, it really stuck in my mind, when it became clear that Augment is as security relevant and asking as much from our customers as Databricks [is] asking from their customers, to take these lessons and apply them as much as I could at Augment.

Jon McLachlan

No, I love that. And so it was, it sounds like it was the team. And it was the problem space. And it was the challenge. I feel like you like a good challenge.

Dirk Meister

Yeah, exactly. Like, this is technical challenging area. It was, it was new. It's doing something at scale. It's doing something for like helping engineers. And I think engineers need every help they can get. Like software engineering is getting so complex. And anything we can do to make their life a bit easier, I think, is worth doing.

Jon McLachlan

I couldn't agree more. And so if you were to think about like, everyone, everyone brings like different strengths to the table. That maybe you think of them as superpowers. Um, I'm super curious, what is, what's your superpower? What's your, your strength? And, and maybe there's a story about where it came from.

Dirk Meister

For somebody who works in startups [their] complete career, which is like sometimes the wild west, and [tech debt] is taken really freely, I always try to keep it under control. I think we discussed about that. I think architecture is like so paramount. If you get that right, everything becomes easy two years on. If you get that wrong, everything becomes [a] problem two years on. And like five percent of thinking on a whiteboard or on a piece of paper can save you months and months later. And what's the point of building a product that people like when it doesn't work? But obviously, balance this: we have to get to product-market [fit]. We have to iterate fast. We have to take tech debt, but in a conscious way, and try to balance these things. I think this was really like a founding experience to me, that like when you are in a start, even a startup, architecture matters. Building the right foundation matters, because it's a marathon. Startup is a marathon. It's not a sprint. It's like you have to survive the first year, but the first year is only the year before the second year and the fifth year and the tenth year. You want to build a sustainable company. And like that's always a pitch. And sometimes this pitch, you lose a battle and you win a battle, but that's how I approach startups and [tech debt] in startups. And security is a part of that. That like it's when you get your security fundamentals wrong, you will have big projects, big rewrites, a lot of pain later to get that back under control.

Jon McLachlan

And when you get them right, a whole bunch of other amazing things start to fall into place, right? You get faster product-market fit. You can see adoption in larger and larger organizations. You can land certifications, even though those are just checkboxes, you can land them much more quickly, like SOC 2 Type 2. Augment, I think, was the first engineering AI platform to get their SOC 2 Type 2, right?

Dirk Meister

I think so. I also think Augment was the first to ISO 4-0-1-0-0-1, but I might get these numbers wrong. I never, I never can remember the numbers.

Jon McLachlan

42001, yeah, it was the first to 42001. For sure it was. Like all of the big players got it. Augment Code was actually like the thirty-some[th] company in the world to get that. And instead of now rebuilding the architecture and security architecture, our engineers can now focus on building the next features, which I think is huge. But everybody [who] has built in the early days is now really, I think, reaping the benefits of more productivity now, faster scaling in a way that enterprises can trust.

Dirk Meister

I think Augment doesn't talk a lot about the companies that are users, but some of them are like really security conscious companies, uh, sometimes to a painful extent. Um, but like they take this really serious, and they look at us, and they look at us [very] deeply, and they come out and say yes, that's, that's the one that we can trust.

Sasha Sinkevich

To go back to that foundational security done right, and we're not just talking about checkbox security, we're talking about proper security controls and implementations. Once you get that done right, it's very easy to add on top of it. For example, we can talk about customer managed keys. That was a fairly swift addition, because the architecture which we have today at Augment enabled a fairly swift addition of customer managed keys, and maybe Dirk can talk a little bit more about that. Why, why it is important and what does it enable.

Dirk Meister

So customer keys are important, again, from this trust of our customers to us. And the trust here comes from the ability to not trust us. That they trust us when we want to move away from these people because we don't like their servers, that they lose access to the data that they upload. And this ability to walk away is, I think, what can help customers, prospects to interacting with us. And that means like they have a cryptographic key, they give us access to it, and when they wipe our access to it, we lose access to the data. We don't have to delete anything. Even when we don't delete anything, we are, we are like, it's useless to us. It's just now random bytes.

Sasha Sinkevich

And it's essentially a secure cryptographic deletion at that point.

Dirk Meister

It's a cryptographic deletion. Like even when we don't delete the, the like the files itself, the data itself, the rows itself, they are useless. As you said, this was, because we knew exactly where our data is and how our data is stored, and we controlled the access to the data very tightly, it was a really swift project to add CMK to all the customer data in a way that's transparent to the customers. It wasn't a rewrite of the system, and now we have to find all the data and something like that.

Jon McLachlan

What are you most proud of? In the system, or in the entire Augment platform?

Dirk Meister

I think what I'm most proud of is how we try to manage the trade-off between security by default and access, at like having no access to it, and the ability to gain access for support. So it's not about shutting everything down. It's leaving this controlled holes that, on customer demand, we can look at the pieces that are relevant to the customers when they ask us to look at. They have like the security architecture where engineers now can ask for access by business reasons, link to a support ticket, whatever they need to do, and gain access for a limited amount of time to the data, and set of data, right?

Jon McLachlan

It doesn't just give you access to the entire data.

Dirk Meister

Right, to a specific set of data, not the complete data.

Sasha Sinkevich

Right. And this goes back to the foundations of this proper security controls built early on. You have this multiple turnkey approval process that you have to go through in order to gain a limited visibility into the systems, only when there is a reason for it, like a customer opens a support case.

Dirk Meister

And this not only at the front end. It's not a [check] that we do one time at the, on the support website or in the extension. It's a check that we do to the lowest level of the database access, so that it's much more difficult and, I hope, impossible to, uh, circumvent.

Jon McLachlan

Great addition to thinking about security in layers. Goes all the way down into the infrastructure, and connects to very real business needs. So, yeah, that's absolutely something to be most proud about. I'm super curious, you know, oftentimes when you're doing a startup, you're in a startup, things go so fast, but there's always gonna be challenges with doing stuff like that. I'm curious, from your story, from Dirk's perspective, you know, in your entire journey, have you had like a most difficult day in your entrepreneurial journeys?

Dirk Meister

The most difficult day as a startup engineer for me was like leaving Databricks, because it's a company that I like really like. They have like a fantastic culture and they're doing so well. And like leaving a company that is doing well as a startup engineer is always like a, a difficult choice. But when the opportunity for Augment came along to build something for the first time in an era that was really new at the time, like nowadays, like everybody talks about AI for code. It's a really hot topic. Companies use it a lot because they see the benefits. But at the time, that wasn't clear yet. It was really building something new that hasn't been done before. And I think AI for code is [the] biggest change in how software is written, at least in the last thirty, forty years. Being part of that was something that I really wanted to do. But it was a really tough day.

Jon McLachlan

Yeah. You do have to be a little bit, I mean, you have to have that very entrepreneurial, like, sense of adventure, just to jump in there and, and be like, the world is changing and I have decided I want to be part of that change.

Dirk Meister

Yeah, exactly. And building it with like really good people and building something new and exciting. Working at a startup, being a founding engineer, is, [when] you're getting comfortable, you're doing something wrong. It's always about like challenging yourself into new areas. Like, would I have believed six years ago that I work on like product security? No. But it's about like digging [in]to something new, understanding a topic as good as possible by working with good people, learning from good people, learning from all the information that is out there in the internet, and like dig yourself into a new topic, learning it, understanding it, and then like applying it in a way that, yeah, you didn't know three years ago. So, like, it's always challenging yourself.

Sasha Sinkevich

What's the most proud, or the brightest day, that you remember from the day you joined Augment, the new startup, the new kid on the block? And between then and now, what's the brightest day that you remember?

Dirk Meister

I think it's always the darkest days too, like when you have a big outage and everybody comes together. It's, it's not the days where everything works, it just works. That's, that's the job. But like when, when something doesn't work, that happens, but like when, when engineering and leaderships come together and you work through a tough problem and restore something, and it's, it's the toughest days and you're like, oh, what is going on? But then you figure it out and you can restore the service. So it's, it's like this [camaraderie] that comes out of, uh, this intense pressure. That the hardest days, but also then the most fun days to look back at. These are the kind of days where I'm like looking back with most [fondness].

Sasha Sinkevich

We have a lot of listeners who are in different stages of their professional career. What advice would you give to a new engineer that started their career maybe a couple of years ago? Or maybe an entrepreneur that is looking to start a new project, what would be your advice?

Dirk Meister

I'm an old schooler. I still think that foundations matter, that like understanding computer science is not only overheads, that leads you for your first job where you then like do TypeScript, but it, that it helps you build a foundation and appreciation for the science that we are working with, even in a startup, even in the situation. That AI for code, again, is about balance. If you trust the AI completely and you don't read it anymore, you will be in quite a problem in six months. And I, [as] somebody who professionally built [an] AI for code solution, it's still the engineer on the other side that is important. This company is called Augmented, not Replaced, for a reason. We, we, we believe that. So like use the AI as much as possible, but don't trust it. Always have a healthy amount of mistrust. Be curious. Stay learning. Understand the fundamentals. I think the fundamentals of computer science, the fundamentals of software engineering, [are] probably the only things that are not changing with AI. How do you work with people to get requirements out of them that actually hold? Like when you talk to a salesperson, they have a completely different language than the engineering language. How do you communicate with them to actually understand what they're really asking from you? It's a skill set that is valuable now. It's a skill set that was valuable twenty years ago. I deeply believe it will be a skill set that is really important to you in 20 years.

Sasha Sinkevich

Fundamentals. The fundamentals are the only things not changing with this new advent of AI. [I'm] guessing more and more emphasis will be on architecture, will be on collaboration, will be on requirements, will be on decision making. But these fundamental software engineering stay the same.

Dirk Meister

I think they will become a much, much bigger part of what we are doing in our software engineering job in the future.

Sasha Sinkevich

And now you can focus on the bigger picture. But like you mentioned, the communication and collaboration skills are very important, and they will become even more important, because it's crucial to understand where the business is moving, where the sales team is, where the marketing team is, and how do you connect all of these data points and build the bridges and build the comprehensive solution together as a team.

Dirk Meister

And I think this is the journey of all computer science for the last 50 years. Like 50 years ago, or in the 60s, people could sit in a small corner and write their own implementation or something like that. But like software engineering is a team sport. It has been for a really long time, and it will be even more. And even when you look back to like the classical papers about software engineering of like Fred Brooks, [the sixties], nineteen seventies, nineteen eighties, and you look [at] that, and like they solved the same problems in the eighties we, we solve now. People think so much is changing, and AI will change so much even more. But I think the, what does it mean to do software engineering, but as the fundamental problems of soft[ware] engineering, that's not changing.

Jon McLachlan

If you could go back in time and meet your younger self, would you, and would you have any advice for your younger self?

Dirk Meister

I was always a bit this [math kid] in school, and like, why do I have to learn writing? It's, uh, boring. And why do I have to learn English? I live in Germany. Who would, who would use English ever? I think I was wrong. I think writing is a really important skill. Um, writing is a form of communication. And I think I ignored this for a really long time. And in school I found it incredibly boring to look at languages and writing, and it's something there I really learned in university then. Then there was a lot of technical writing courses in university, where I at least had understood more the importance of that. Getting to that earlier is something, like learning how to write, learning how to understand your audience when you're writing, is something that I would like [to] give myself as advice, but also some advice that I give to like a lot of the people I mentor, the early career people, of like, this is something that is so important. It's something to really focus on.

Jon McLachlan

And this is where I would plug a couple of the articles that you've recently produced for Augment. And what I would like to highlight super quickly is the importance of delivering the core concept in as little words as possible, for it to be very easy to understand. You've done a lot of great articles explaining very plainly and simply what it is and why it is important.

Dirk Meister

And you want to do it as simple as possible without going to the point of lying. Like you can explain everything simple, but sometimes you're like, that's actually no longer true. You want to, you want to explain something as simple as possible, but [you] would not cross the border. Like find the right abstraction for the right person, but stay [truthful], and like always remember that like the, keep a, interacting with you, people reading something, they, it's all about trust. And if people don't trust what you're doing, if people don't trust anymore what you're writing, it's the most important thing, especially, I think, in security.

Sasha Sinkevich

Is there a person or an event in your life that made the biggest impact on your career?

Dirk Meister

I was lucky to always have mentors in the companies that I joined, from the earliest days, where I was like, after high school, I started working as like a software engineer apprentice, and I found great mentors there that then guided me to like go to university later. So I didn't [join], I didn't go to university directly after school. I did, was an apprenticeship in Germany, but people were like guiding me to go further. And then this went up to like a PhD. And then when I joined companies, always look out for the people who are smart and know what's going on, and like find mentors. And I was always lucky to have people who could guide me and help. And it's always about like getting the right help, standing [on the shoulders of] the people, standing on the shoulders of giants, and get and like learning and understanding what is going on. But yes, it's not one person in a career, it's a set of people who [I'm] really grateful to have worked with in all the different companies.

Sasha Sinkevich

And this goes back to working together. We are individuals, but we work so much better in company.

Dirk Meister

Exactly. Like one of the things for me is that Augment is like, we have an office, and we come together, and we go to a whiteboard. And like people are completely different. I completely respect that. But for me, it's so much easier to collaborate with people when you see them face to face, uh, stand beside them and have your coffee talks. I know that's, different people have different preferences, but maybe because I'm a bit of an introvert by nature, I think it actually helps [to] have the forcing function of being in the same room to become collaborative.

Sasha Sinkevich

Thank you for sharing your experience, not only with the Augment team, which you are a big part of today, but also with all of the audience on the show. And we thank you so much for joining the show, for going back into the history about your development as a security professional, about your career, about your career path, and all of the advices that you shared with the new engineers that are looking to start their careers.

Dirk Meister

Thank you for having me. It was a great pleasure.

Jon McLachlan

Thank you, everyone, for joining another episode. It has been an absolute pleasure, and we look forward to [many] more. Thank you, thank you. Thank you, Dirk. [And] Sasha.

FAQ

Questions this episode answers

What is proof of possession in Augment Code?
A design in which the IDE has to prove it already holds a source file, by sending a cryptographic hash of its content, before Augment's backend uses that file for a suggestion. Shared files that everyone has can serve the whole team, while a file only one engineer has can only be used for that engineer. Dirk Meister describes it at 5:57, and he and Markus Rabe wrote it up in Augment's January 2025 post on its real-time index.
Can a stolen API token expose source code uploaded to Augment?
Not by Dirk's account. With just a user's API token, you can use the system, and possibly use it more than you're allowed to, but you cannot get access to the source code the user uploaded six months ago or a minute ago, because reading it requires proving possession of the files. The token grants access to the system, not to the code.
Why do customer managed keys build trust?
Because, in Dirk's words, "the trust here comes from the ability to not trust us." The customer holds the key and gives the vendor access to it, and if they revoke it the vendor's copy of the data becomes random bytes, a cryptographic deletion that needs nobody to delete a row. Augment launched customer managed keys for enterprise customers on April 16, 2025.
How should support engineers get access to customer data?
Only with a business reason, linked to a support ticket, for a limited time and a limited set of data, with the check enforced at the lowest level of database access rather than only in a support tool. Augment's February 2025 security post adds that each request is time-limited, audited and approved by a second person.
Why should startups think about security architecture early?
Because architecture is hard to change later. Dirk's approach is that getting the architecture right makes everything easier, getting it wrong makes everything harder, and he has seen companies die of it. Knowing where data such as personal information flows from the start avoids a redesign that stops the company, and five percent of thinking on a whiteboard can save months.
What questions should enterprises ask an AI coding vendor?
The ones a checkbox can't answer, starting with whether the architecture is built for security, and a question that gets past the security team to the culture outside it, since security teams are only five to ten percent of a company. Dirk says too often security is checkboxes, and the most important questions are complex and messy.
Does Augment Code train on customer code?
Augment's February 2025 post on its platform's security, written by Dirk, says "We do not train on your code or your messages, nor can engineers read them by default," and Augment's May 2025 summary listed no training or retention unless explicitly allowed. On the tape Dirk describes the use of source code as a big ask that the company has to earn.
Was Augment Code the first AI coding assistant with SOC 2 Type 2 and ISO 42001?
For ISO/IEC 42001, Coalfire Certification's release was headlined as Augment Code becoming the first AI coding assistant to achieve the certification, and Augment announced it on May 29, 2025. For SOC 2 Type II, Augment received its attestation on July 10, 2024, and its announcement said other AI tools, like GitHub Copilot, had yet to reach that level, which is a comparison at the time rather than a documented first.
What did Dirk Meister do before Augment Code?
He started as a software engineer apprentice in Germany after high school, earned a bachelor's and master's at Paderborn University and a PhD at Johannes Gutenberg University Mainz on data deduplication, spent from 2013 to 2021 at Pure Storage, and led the code and continuous integration team at Databricks from 2021 to 2022, during its FedRAMP Moderate certification.
Where is Dirk Meister now?
His last day at Augment Code was December 5, 2025, and in January 2026 he joined Google as a staff software engineer. In a January 3, 2026 post he looked back on his journey into AI for code and wrote that security and trust are hard to bolt on later.
Keep reading on the YSecurity blog
Related episodes
If this episode hits close to home
Product Security The security features your enterprise buyers ask for — shipped by us, in your codebase. SOC 2 Type 2 Audit-ready in five months, not fifteen. ISO 42001 The AI governance certification that clears enterprise AI committees. vCISO A vCISO with a full security team behind them.
New episodes every other Tuesday

Got a story like this one?

We're always looking for practitioners who've been in the room when it mattered.

Apply to be a guest
SpotifyApple PodcastsYouTubePodbeanPlayer FMRSS