Enterprise AI Strategy Isn't a Model Choice. It's an Operating Problem.

Most companies don't fail because they picked the wrong model. They fail because enablement, security, and governance show up late. By then, engineers already have Cursor, Claude, Copilot, and a pile of MCP servers on their machines. Security finds out after something weird hits prod.

Good news: you don't need to invent the whole stack. A lot of the rails are open source. The hard part is assembling them into something engineers will use and security can trust.

What's actually happening

In July 2025, a Replit coding agent wiped a live production database during a code freeze.[1] Over a thousand executive records and nearly as many company records gone. Then it made up fake users and said recovery was impossible. Humans restored it with a normal rollback. Replit's CEO said it shouldn't have been possible. He was right.

In April 2026, reporting around a Cursor agent described something worse in speed: a credential mismatch, a cloud token with too much power, and a production volume plus backups wiped in about nine seconds.[2]

No attacker. Just an agent with standing access and nothing on the path that could stop it.

That's the risk. Agents can shell out, touch secrets, call internal tools, run terraform apply, poke kube, and mutate prod APIs.

1. Outcomes first

Before tooling, force use cases into something operational:

• Ship faster?
• Fewer defects / less rework?
• Lower support cost?
• New product surface?

Owner + metric + risk posture — or don't scale it.

Anthropic has said Teams/Enterprise Claude Code auto mode users ship about 25% more PRs.[3] Velocity is real. That's why controls have to land before autonomy becomes the default.

OSS for this stage

Implementation: start with LiteLLM + Langfuse on one pilot team. If you can't answer "what did it call and what did it cost?", you're not ready to scale.

2. Enablement: make the safe path the easy path

You can't ban your way through this. If the official path is painful, people go around you.

What works:

• Short approved catalog
• Tiers: fine / needs review / not here
• Golden paths already reviewed
• Concrete training
• Respected eng leads using the governed setup

Adobe/Gusto/Garner-style patterns work when the official path is usable — agents draft, humans review where it matters.[3]

OSS for enablement

Implementation: publish a one-pager: "use these three approved surfaces." Wire them through LiteLLM so identity, logging, and model allowlists are central. Everything else is shadow AI until reviewed.

3. Security: treat AI as an execution surface

Human click-through is not a control. Anthropic's own numbers: ~97% of permission prompts approved; in a 1,053-person study humans caught 13.6% of dangerous commands vs 89% for their classifier.[3] Fatigue wins.

High-stakes prod changes still need HITL. Anthropic says that for production infrastructure. Believe them.[3]

OSS for security

Implementation order I'd use:

1. No prod credentials in agent environments. Vault + separate sandboxes. This alone kills a huge class of PocketOS-style wipes.[2]
2. Gateway in front of models (LiteLLM) with auth, model allowlists, basic budget caps.
3. Guardrails on app agents (NeMo or LLM Guard) for injection + PII.
4. MCP proxy for any tool that can mutate systems. Default deny destructive tools.
5. HITL for terraform / kube / DB / secrets / backup APIs — ask before execute.

Be honest with leadership: OSS is strong for app agents and MCP gateways. IDE coding agents (Cursor/Claude Code hooks) are a thinner OSS market today. You may still need commercial control planes there, or strict env isolation so the IDE agent physically cannot reach prod.

4. Governance: interruptible policy + evidence

Replit's freeze lived in chat. It wasn't on the tool path. That's governance theater.[1]

You need inventory, policy, enforcement, HITL, audit, and time-boxed exceptions.

OSS for governance

Implementation: store policy in Git. Deploy via CI. Every deny/ask writes an event with actor, tool, rule id, session id. If you can't reconstruct a freeze violation after the fact, you don't have governance.

5. Platform: shared rails, or every team reinvents risk

In startups, a few one-off agent setups are survivable. In an enterprise, they're how you get five different MCP configs, three ways to handle secrets, and zero shared incident timeline.

I've seen this movie with microservices, data pipelines, and "temporary" cloud accounts. AI will do the same thing unless platform owns the rails.

What "platform" should mean here

• One front door for models — auth, routing, budgets, allowlists
• One path for tools — especially anything that can mutate systems
• One place for traces — prompts, tool calls, cost, failures
• One policy pack model — high / medium / low risk, reviewed in Git
• One secret and environment story — sandbox by default, prod only with HITL

If product teams each invent that, security becomes a scavenger hunt.

Platform stack (OSS)

Build once. Reuse across teams. Four layers.

Ship this as an internal module. Teams bring use cases. They don't each build safety from scratch.

How this maps to the incidents

Replit wasn't only a model failure. There was no hard separation between "chat about the app" and "touch live data." Afterward, the remediation talk included stronger isolation and approval flows — classic platform work.[1]

PocketOS wasn't only "the agent guessed wrong." A broadly privileged token and a destructive API were reachable from a coding session. Platform should make that combination hard by default: scoped tokens, mutate tools behind deny/ask, backups outside the same blast radius.[2]

Implementation reality check

• Don't boil the ocean. Start with LiteLLM + Langfuse + no prod creds in agent envs.
• Add MCP proxy + OPA when teams start wiring tools.
• Treat prompts, skills, and tool configs like services: PR review, versioning, rollback.
• Measure adoption of the platform path. If <50% of AI traffic goes through it, you still have shadow AI — just with better dashboards for the minority.

Platform's job is simple to say and hard to do: make the safe path faster than the unmanaged one. If your golden path needs a ticket and three weeks, people will keep pasting API keys into personal agents.

6. Risk tiers (and which tools attach where)

7. People: agents draft, humans own

Tools don't fix incentive problems. If you only measure PR count, people will bypass controls.

Pair enablement OSS (Continue, Open WebUI, Dify) with clear ownership: humans own production outcomes. Agents accelerate drafts.

8. Measure both ledgers

Practical 90 days with OSS

Where I land

Enterprise AI strategy has three jobs:

1. Help teams adopt useful AI quickly
2. Make dangerous execution hard
3. Keep material actions attributable and interruptible

OSS can cover a lot of that — gateway, traces, evals, PII, guardrails, secrets, policy-as-code, MCP proxies, sandboxes. What it won't do is assemble itself into a path engineers prefer over the unmanaged one.

Ask one question:

If an agent tries to change production during a freeze, what technically stops it — and which OSS component owns that stop?

If the answer is still "we told people not to," you don't have a strategy. You have hope.

Hope is not an engineering control.

OSS tools mentioned

A catalog of every open-source tool cited above, grouped by job. Links go to GitHub unless noted.