Vibe Coding for Production: What Has to Change When the Agent Has to Pass a Compliance Review

By Adam Wolf

The prototype works. You built it in a weekend with Claude Code, Cursor, or Codex. It reads a spreadsheet, calls a model, does the thing, and writes the result. Your manager saw a demo and said, “Can we ship this?” The productivity gains from AI-assisted development are real, and the tooling deserves the credit it is getting.

This piece is not another article telling you to slow down. It is a builder’s guide to what actually changes when the agent you prototyped has to run on real production traffic, on real production data, in a context where somebody will eventually ask, “Who signed off on this?” The five things that break in that transition (identity, data access, secrets handling, deployment, and observability) are each fixable, and Klique addresses each one at the platform layer so you do not have to solve them individually the hard way.

The moment the prototype stops being a prototype

The transition from “it works on my laptop” to “other people depend on this” happens faster with AI-built agents than it did with traditional prototypes. The agent that took a weekend to build gets a demo on Monday, gets scoped for a real use case on Wednesday, and gets asked to handle live customer data by the end of the sprint. The velocity is the point. It is also the reason the failure modes stack up so fast when the prototype design assumptions do not survive contact with the production environment.

The environment you built the prototype in and the environment production actually operates in are different in five specific places. Each one is a place where the shortcut that made the prototype fast becomes the reason the compliance review fails. This is not theoretical. The 2026 KPMG survey of large-enterprise leaders found that 75% cite security, compliance, and auditability as the most critical requirements for agent deployment. Multi-agent orchestration complexity has become the primary bottleneck as organizations move from pilots to production. Compliance is not a hurdle bolted onto production. It is production.

Here is what actually changes in each of the five dimensions, why the change matters, and what a workable path forward looks like without abandoning the tools that got you here.

Identity: Who is this agent, really?

In the prototype, the agent runs as you. It uses your API keys, your database credentials, and your OAuth tokens. When it makes a request, the request identifies it as you. When it does something, the audit trail (if there is one) says you did it. This is fine on a laptop. It is a serious problem in production.

The issue is not that you cannot be trusted. It is that the agent is not you. When multiple users need to invoke the same agent, when the agent runs on a schedule, when the agent runs unattended for hours, or when the agent hands off work to a downstream agent, there is no coherent notion of who is acting. Everything shows up under your identity, or (worse) under a shared service account that a previous developer created and nobody has rotated in three years.

The documented consequences of this pattern are direct. When an April 2026 AI coding agent deleted a Railway production database in nine seconds after finding a long-lived API token in an unrelated file, the token had account-scoped permissions with no environment isolation. The deletion happened because the agent inherited access it should never have had. In the same month, an internal Meta AI agent posted an error-filled response to an internal forum without the requesting engineer’s approval because the agent had the scope to post. Both incidents share the same root cause: the agent was not operating under its own scoped identity, so nothing constrained what it could do on someone else’s behalf.

The fix, at the platform level, is that every agent gets its own identity. Not a shared service account. Not the developer’s personal token. A first-class identity with its own permissions, its own audit trail, its own lifecycle.

When the agent acts, the log records both the agent and the human who authorized it. When the agent is retired, its identity retires with it. When a user leaves the company, the agents they created do not silently continue running on their credentials.

This is the “every agent is its own tenant” architecture that Klique treats as foundational: each agent is registered, named, and governed against the enterprise identity provider, with the human on whose authority the agent runs traveling with the call. The practical builder benefit is that you stop worrying about credential hygiene as a personal responsibility and start relying on it as a platform property.

Data access: What is the agent actually allowed to touch?

In the prototype, data access is whatever gets the agent working. You point it at the CSV you exported. You give it a read-only database connection you found in a shared credentials file. You paste an example row into the prompt so the model understands the schema. All of this is fine on a laptop. In production, each of those steps has a compliance failure mode attached.

The CSV you exported was not classified. The database credential you found had access to columns the agent should never see. The example row you pasted into the prompt contained PII that is now in the model provider’s logs, retained under whatever data retention policy applies to the account you authenticated with. The agent did not do anything wrong. The data access architecture around it did.

The production version of data access has three properties the prototype version usually skips. First, the agent has scoped access to the specific data it needs, not the broadest access the credential happens to allow. If the agent reads customer contact information but not customer financial history, the credential it holds should reflect that split. Second, the access is attributed. When the agent reads a row, the read is logged with the agent’s identity and the human who authorized the invocation, not just “system.” Third, the data classification travels with the read. If a row is marked as containing regulated data, the agent inherits the handling obligations that attach to that classification.

The builder shortcut that makes this work in practice is that the data governance layer sits above the agent code, not inside it. You do not want to be writing per-request access checks in your agent logic. You want a platform where the connection between the agent’s identity and the data it can touch is expressed as policy, and the policy is enforced whether the agent asks nicely or not. Klique’s end-to-end user token pass-through is built to solve exactly this: the credentials the agent operates under carry the delegating user’s permissions rather than a shared superuser account, so the agent cannot exceed what the human on whose behalf it is acting is allowed to do.

Secrets handling: Where do the keys actually live?

This is the section that most developers already know they are getting wrong. GitGuardian’s State of Secrets Sprawl 2026 report found 28.6 million new secrets exposed in public GitHub commits across 2025, a 34% year-over-year increase and the largest annual jump in the report’s history. AI-assisted commits leaked secrets at roughly twice the baseline rate. Over 1.2 million AI-service secrets were exposed in 2025 alone, an 81% year-over-year increase. Twelve of the top fifteen fastest-growing leaked secret types were AI services. In the MCP configuration ecosystem specifically, GitGuardian identified around 24,000 exposed secrets in MCP config files on public GitHub, of which 8.8% were confirmed valid credentials at the time of scanning. And 64% of credentials leaked in 2022 were still active in January 2026.

The prototype version of secrets handling is usually a .env file, sometimes a hardcoded string, occasionally a shared 1Password vault the team pulls from. That works on your laptop. In production, it fails four ways. First, the credentials outlive the developer: the key you generated a year ago still works, and nobody knows if it should. Second, the credential scope is wrong: the STRIPE_KEY that lets the agent create invoices can also issue refunds and read customer data, because the API key does not know what the agent needs. Third, the credentials are attributable to nothing: you cannot tell whether the agent used the key or a human used the key, so forensics becomes a nightmare. Fourth, the credentials get read by the agent itself: an agent that can be prompt-injected into printing its environment variables can hand its own keys to an attacker, which is a class of attack that does not exist for traditional applications.

The production version of secrets handling has short-lived credentials with narrow scopes, issued to the agent at runtime rather than baked into the deployment artifact. When the agent needs to talk to Stripe, it requests an ephemeral credential that lets it create invoices, expires in an hour, and is scoped to the specific customer context the agent is operating in. When the credential expires, the agent requests another one. If the credential leaks, it is dead by the time the attacker tries to use it.

Building this from scratch is a research project. Building it correctly is what platforms like Klique are for: the agent runs against enterprise-governed model endpoints and enterprise-managed downstream credentials, without the developer having to design a credential lifecycle. The builder shortcut is that your agent code stops containing secrets at all. Your agent authenticates to the platform, and the platform authenticates to everything downstream on the agent’s behalf, with the scope, the expiration, and the audit trail already attached.

Deployment: What happens when it stops being “python agent.py”?

The prototype ran on your laptop. Maybe it ran in a container on your laptop. Maybe you deployed it to a Modal endpoint or a Vercel function so you could share the demo. In production, the deployment surface changes in ways that the prototype architecture did not have to model.

The agent has to be reachable from wherever the users are, without being reachable by everyone else. The endpoint has to have authentication attached. The endpoint has to be versioned, so a change to the underlying model or the underlying code does not silently break every caller. The endpoint has to have rate limits, quotas, and circuit breakers, because one caller with a bad prompt template can otherwise consume the entire agent’s budget in an afternoon. The endpoint has to be updatable without breaking existing sessions. The endpoint has to have a rollback path because your first deployment of a real production agent will contain a bug, and you will want to reverse it.

None of this is deep science. It is a set of infrastructure concerns that traditional applications have been solving with API gateways for two decades. What is different for AI agents is the size and shape of the traffic.

For instance, an agent request in a prototype environment that took two seconds and returned two hundred tokens might, once in production, take thirty seconds, return fifty thousand tokens, and cost fifty cents. The rate limits and quotas that made sense for a REST API do not translate. The circuit breakers have to know about token budgets. The version routing has to handle KV cache implications. The gateway has to speak “AI request” natively, not just “HTTP request.”

Klique’s AI Application Gateway is designed for this shape of traffic: managed networking, identity-aware access control, per-endpoint RBAC, autoscaling that responds to real workload patterns, and the ability to route between model providers without the client needing to know which one is serving the call.

The builder benefit is not that you have to use this specific implementation.

It is that “get an agent to production” stops being a bespoke integration project every time and starts being a deployment target the platform already knows about.

Observability: who is watching what the agent actually does?

In the prototype, observability is you looking at print statements. If the agent does something surprising, you notice, because you are the one running it. In production, nobody is watching. That is the point of shipping it. Which means the observability layer around the agent has to notice the surprising things on your behalf.

This means more than mere logging. Agents are non-deterministic in a way traditional applications simply aren’t. The same input can produce different outputs, sometimes because the model is stochastic, sometimes because the retrieval context changed, and sometimes because a downstream tool returned a different value.

When something goes wrong, the debugging surface is the reasoning trace, the tool calls, the intermediate outputs, the token usage per step, and the context that was in the model’s window at each turn. If your observability layer captures only the final response, you have logs but not debugging capacity.

The production version of AI observability has three properties. First, per-invocation traces that capture the full agent execution: prompts, tool calls, intermediate outputs, and final response, with token accounting at each step. Second, per-tenant attribution: when the agent misbehaves, the log tells you which human authorized the run, which agent executed it, and what the agent was allowed to do. Third, alerting on the things that agents do wrong that traditional applications do not do wrong: runaway token consumption, tool call loops, prompt injection attempts, credential exposure, memory poisoning. The OWASP Top 10 for Agentic Applications (ASI Top 10), published in 2026, is the current industry consensus on which failure modes an observability layer should be able to detect.

The good news for builders is that this is a platform problem, not a per-agent problem. You do not want to instrument each agent individually with a bespoke tracing setup. You want a platform where every agent is observed by default, with the traces flowing to a single dashboard, the alerts firing on a single ruleset, and the audit trail queryable from a single interface.

Klique treats agent observability as a platform concern precisely because instrumenting each agent by hand is the pattern that produces the “we do not actually know what our agents did last quarter” problem that most enterprise AI programs are now discovering.

What the compliance review actually asks

If you have not been through an enterprise compliance review for an AI system, the specific questions can be surprising. They are not usually about the model choice or the prompt engineering. They are almost entirely about the five dimensions above.

• “Who is this agent, and how do we know?” (Identity)
• “What data can it access, and can we prove it only accesses that data?” (Data access)
• “Where are the credentials stored, how are they rotated, and what is the blast radius if one leaks?” (Secrets)
• “How is this deployed, how do we roll it back, and what are the failure modes if the endpoint goes down?” (Deployment)
• “What do we log, for how long, and how quickly can we reconstruct what happened if a regulator asks?” (Observability)

If your prototype was built the way most prototypes are built, the answers to these questions are uncomfortable. Not because you did anything wrong. The prototype was optimized for a different question, which was “Does this work?” The compliance review is a different question, which is “Can we defend this?” The gap between the two questions is what has to close before the agent ships.

This is where the OWASP LLM Top 10 and the OWASP ASI Top 10 are useful reading for builders, not because you need to memorize them but because they are the checklist your compliance team is holding when they review your deployment. NIST’s AI Risk Management Framework, the EU AI Act’s Article 14 requirements on human oversight for high-risk systems, CISA and Five Eyes agentic guidance, and MITRE ATLAS are the other frameworks that most enterprise compliance teams are now mapping against. You do not have to be an expert on any of them.

You do have to be building on top of a platform whose architecture already reflects them.

The good news for builders

None of the changes above require you to slow down or to abandon the tools that made the prototype possible. Cursor, Claude Code, Codex, and Aider stay in the workflow. Vibe coding (or agentic engineering, whichever name you prefer) is the productive layer. What changes is what is underneath.

The right platform underneath a production agent removes the individual burden of solving identity, data access, secrets, deployment, and observability separately. You write the agent logic. The platform provides the identity federation, the scoped data access, the credential lifecycle, the deployment surface, and the observability layer.

When the compliance review happens, the answer to each of the five questions is “The platform handles that; here is the audit trail.” Your prototype becomes a production agent without becoming a six-month rewrite.

This is Klique, but it is also an accurate description of what production-quality AI infrastructure looks like in 2026. Whether you use Klique, build the equivalent yourself, or piece together the components across five different vendors, the architectural properties are the same. The productivity gains from AI-assisted development are only sustainable if the infrastructure underneath is ready to receive what the tools are shipping. If it is not, the compliance review is where you find out.

The best time to have this conversation with your platform team was when you started the prototype. The second best time is now, before the demo becomes production traffic.

If you would like to talk through how Klique fits into your team’s path from prototype to production, get in touch.