# Braintrust's Ankur Goyal: Code review doesn't cover prompts > Source: > Published: 2026-06-30 00:00:00+00:00 Ankur Goyal, Founder and CEO of [ Braintrust](https://www.braintrust.dev/), which bills itself as “the AI observability platform,” joined Zero-Shot Learning to talk about the problem every team shipping AI eventually faces, you can build something that works and then watch it quietly become something that doesn't. Braintrust sits in the iteration loop for AI products, helping teams trace production events, turn behavior into eval datasets, compare prompt or model changes, and catch regressions before they reach users. For teams building agents, quality depends on whether the system’s behavior remains useful and safe as prompts, models, tools, and user inputs change. In this episode, what begins as a conversation about evaluation frameworks and production feedback loops reveals a security gap many teams may leave open: prompt changes are behavior-shaping production artifacts. They can change what agents do, what data they surface, which tools they call, and how they use access and credentials. "I think enterprise developers are more comfortable iterating quickly on prompts than they are changing the underlying code," Nancy said. Before code is sent to production, a developer commits to version control, opens a pull request, waits for peer review, passes automated security scans, and gets sign-off before anything merges. The process documents who changed what, when, and why. By contrast, prompt changes often live outside the codebase, stored in a database row, prompt-management tool, or platform dashboard that a product manager or operations team can update directly. There are often no pull requests for review, no security scans, and sometimes even no recorded change a security reviewer would see. Many behavior-shaping changes don't register as prompt changes at all. A developer adjusts how a variable is injected, adds a retrieved context source, or modifies a template's structure, and nothing in the codebase signals that the agent will now behave differently. I am, almost to a scary amount, frequently surprised by what the ramifications of random prompt changes are.” –Ankur Goyal, Founder and CEO, Braintrust When a product manager updates a customer support agent's system prompt to be more helpful, the underlying code hasn't changed, nor have the credentials in use, or the access policy that applies to the agent. Without a dedicated review process, that change slips past security entirely. The agent may now answer differently, surface different data, call tools it didn't before, or treat a workflow as in scope that wasn't before. The [ credentials and access policies haven't changed](https://1password.com/blog/ai-agent-identity-and-accountability), but the system that appeared compliant on paper is now behaving differently in production. Agent behavior and access are intertwined. Agents depend on prompts that shape how they interpret tasks, tools that determine available actions, credentials that grant access, and models that affect how consistently they follow instructions. Any change to that execution context, the prompt text, the model version, parameter settings, or retrieval configuration can shift how the agent behaves without changing a line of underlying code. When a prompt changes, there are usually no alerts to fire and no tests to fail against. When LLM-integrated systems are haphazardly designed, a slight change in a natural language prompt can cause an agent to overreach without producing an error. When this happens, there is no way to detect if it exposed data or used a credential unintentionally. Unlike traditional code reviews, the risk lies in whether the system’s behavior stays within intended boundaries. Because agents work behind the scenes across SaaS apps, APIs, internal systems, databases, and dev environments, they rely on non-human identities, service accounts, and shared secrets. If the credentials they use are long-lived or [ over-permissioned](https://www.cnet.com/tech/services-and-software/meta-instagram-ai-chatbot-tech-support-hack/), a prompt change can quickly become more than a quality issue. Entro Labs’ [ 2025 NHI and Secrets Risk Report](https://23579664.fs1.hubspotusercontent-na1.net/hubfs/23579664/Assets/EL-The-NHI-Secrets-Risk-Report-H1-2025.pdf) found that 1 in 20 AWS non-human identities held full admin privileges, while only 38% of NHIs had been active in the previous nine months. That's the access exposure within which a prompt change can create risk. When Nancy asked Ankur what a [ minimum release gate for a prompt release](https://www.braintrust.dev/articles/what-is-prompt-versioning) should look like, his answer hinged on a maturity model. The minimum release gate should require humans to review representative examples before a prompt change ships. Then, a team translates that feedback into scoring functions, scales testing from a few examples to hundreds, and audits the highest- and lowest-scoring outputs to refine the signal. As scoring functions improve, the process requires less human attention per change, not because the gate disappears, but because the signal has earned trust. “You start building trust in the signal as an organization,” Ankur said. “You can still involve people in the review process, but you don’t feel nervous about always needing people as the gate to release things. Evals actually allow you to go way, way faster." "You're able to diagnose where the issues are, isolated down to the core component," Nancy agreed. With meaningful data, teams can stop guessing whether a prompt change improved the product. They can see where performance improved, where regressions appeared, and which examples need deeper review. Evals can tell you whether the output was useful, accurate, and safe against defined criteria. Observability can tell you what the agent did. Neither one, on its own, tells you whether the agent should have had access to the data, credentials, or system it used. That's why prompt review and access review have to work together. As [ TechTarget](https://www.techtarget.com/searchsecurity/tip/CISOs-guide-to-nonhuman-identity-security) wrote, "in many cases, there isn't a clear sense of who owns the identity, who controls and approves permissions, or who should rotate keys." Without a review process, prompt changes accumulate. Each update to an agent's instructions, a product manager adjusting tone, a developer adding a retrieved context source, or an automated pipeline responding to user feedback ships without anyone tracking how it interacts with previous changes. Over time, the system reflects decisions no one made deliberately and changes no one fully understands. When something breaks, who is accountable? As Ankur said, "If you let an LLM go, go, go, go, go, and no one takes the time to actually comprehend the work, then you build up comprehension debt. And so when the piper comes and your product breaks, someone needs to actually understand what's going on to be able to have accountability for the product outcome. I think it's probably the most important problem for our industry this year." Stay up to date with the latest 1Password Developer product news, industry insights, and community contributions. Plus, learn best practices for becoming a better, more secure developer – both at work and at home.