I'm not a software developer. I'm the building inspector watching people pave their own paths through the enterprise. Here's what I'm seeing.

In urban planning, there's a concept called a desire path: the informal trail pedestrians wear into the grass when the sidewalk doesn't go where they actually need to go. It's not vandalism. It's feedback. The planned infrastructure failed to serve the people using it, and they routed around it.

Vibe coding is the desire path of software development.

But I'm not writing this to tell developers their profession is dying. I don't have standing for that. I'm a Director of Information Security. I manage security engineering and IAM teams. I've spent 15 years in cybersecurity and exactly zero of them shipping production applications.

What I do have is a front-row seat to what happens when the desire paths start forming inside an enterprise. And right now, they're everywhere.

The Desire Paths Are Already There

Here's what I'm seeing in my environment and hearing from peers:

A financial analyst discovers they can use an AI coding assistant to build a Python script that automates a report they've been manually compiling every Monday for three years. It works. It runs on their laptop. Nobody in IT knows it exists.

A compliance officer uses Claude to generate a small web app that tracks regulatory deadlines. It pulls from a shared spreadsheet. It sends Slack notifications. It took them an afternoon. The official request to IT for this tool has been in the backlog for 14 months.

A project manager builds an internal dashboard by describing what they want to an LLM. It's not beautiful. It doesn't follow the design system. But it works, their team uses it, and it solved a problem that nobody else was going to solve for them.

These are desire paths.

And here's the uncomfortable truth: these people aren't wrong. They needed something. The planned infrastructure — the IT backlog, the dev team's sprint priorities, the "submit a Jira ticket and wait" process — didn't serve them. So they walked across the grass.

The Security Leader's Problem

As a security person, my instinct is obvious: this is terrifying. Ungoverned code running on laptops. API keys hardcoded in scripts. Data flowing to third-party AI services with no DLP, no audit trail, no access controls. Shadow IT, but now it's shadow development.

The fence-building response is also obvious: block the AI tools, lock down the endpoints, send a policy memo. The digital equivalent of KEEP OFF THE GRASS signs.

But I've been in security long enough to know that prohibition doesn't work when the underlying need is legitimate. You don't stop desire paths by putting up fences. You just make people walk through the mud next to the fence.

The question isn't "how do I stop this?"

The question is:

How do I pave these paths properly?

What a Paved Desire Path Looks Like

If citizen developers are going to build things — and they are, whether you like it or not — security and engineering teams need to build the infrastructure that makes it safe.

Not safe as in "we reviewed every line of code."

Safe as in "the paths have drainage, lighting, and load-bearing foundations."

Here's the architecture.

1. The AI Gateway: Your Sidewalk

Instead of letting every citizen developer hit OpenAI, Anthropic, or Google directly with their own API keys, you put a gateway in front of everything.

Citizen Developer → AI Gateway → [Local Models | Cloud Providers]
                        ↓
                   Audit Log
                   Policy Engine
                   Cost Controls

In my home lab, this is a service called Forge. Every AI request from every tool, agent, and script routes through it. In a 30-day window, that's 300K+ requests across 30+ models. Every single one is logged. Every cloud fallback is auditable at a dedicated endpoint.

The numbers tell the story: $0.79 in actual cloud spend over 30 days, because the gateway routes to local models first and only falls back to cloud providers when necessary.

But the cost savings aren't the point.

The auditability is the point.

When a regulator asks, "What data are your employees sending to AI services?", you need an answer.

An enterprise version of this is an MCP proxy layer. MCP gives you a standardized interface between AI tools and the services they interact with. Put a proxy in front of it, and you control what every citizen-built tool can actually do.

2. The Guardrails: Your Drainage and Curbs

A paved desire path still needs drainage so it doesn't flood. In the citizen developer context, guardrails are the constraints that prevent well-intentioned people from accidentally causing incidents.

Concrete examples:

Data classification enforcement. The gateway inspects outbound requests. If someone's Python script is trying to send customer PII to a cloud model, the request gets blocked before it leaves the network. The citizen developer doesn't need to know about data classification policies. The infrastructure handles it.

Credential management. No citizen developer should ever have a raw API key. The gateway handles authentication. The developer gets a single internal endpoint. If a key needs to be rotated, it happens once at the gateway, not in 47 scripts on 47 laptops.

Scope limitation. An MCP proxy can restrict which tools a citizen-built application can invoke. Your compliance officer's deadline tracker can read from the shared spreadsheet and send Slack notifications. It cannot access the HR system, modify financial records, or provision cloud resources. The path goes where it needs to go and nowhere else.

# Example: MCP proxy policy for a citizen developer tool
policy:
  name: compliance-deadline-tracker
  allowed_tools:
    - google_sheets:read
    - slack:post_message
  blocked_tools:
    - "*:write"          # No writes to any data source
    - "*:delete"         # No deletions
    - "hr_system:*"      # No HR system access at all
  data_rules:
    - block_pii_outbound: true
    - max_tokens_per_request: 4096
  audit:
    log_all_requests: true
    alert_on_block: true

3. The CI/CD Pipeline: Your Building Code

This is where the city planning analogy lands hardest. A desire path that gets paved still has to meet building codes.

For citizen developers, this means:

A defined deployment path. The tool doesn't run on someone's laptop forever. There's a simple process: push it to a repo, it goes through automated scanning — SAST, dependency checks, secrets detection — and it deploys to a managed environment. The citizen developer doesn't need to understand CI/CD. They need a button that says "make this official."

Automated security scanning. Every citizen-built tool gets the same baseline checks that production code gets. Not a full security review — that doesn't scale — but automated detection of the things that cause most incidents: hardcoded secrets, known-vulnerable dependencies, SQL injection patterns, unvalidated inputs.

Environment isolation. Citizen developer tools run in sandboxed environments with limited network access, no production database credentials, and resource caps. If the tool breaks, it breaks in its sandbox. It doesn't take down the ERP system.

4. Maintenance and Ownership: Your Public Works Department

Here's the part every enterprise learns the hard way: paving the path is only the beginning.

The compliance officer who built the regulatory tracker changes roles. The financial analyst who automated the Monday report leaves the company. Six months later, nobody knows who owns the tool, what depends on it, or whether it's still making correct decisions.

This is where desire paths become technical debt corridors.

A governed citizen development platform needs more than deployment pipelines and security scanning. It needs lifecycle management. Every deployed tool should have:

• a recorded owner,
• a business purpose,
• dependency metadata,
• access scope documentation,
• and an expiration or review date.

Not because bureaucracy is fun, but because abandoned automation is one of the most dangerous forms of enterprise risk. A broken dashboard is visible. A silently incorrect dashboard can influence business decisions for months before anyone notices.

That means periodic re-certification:

• Does the tool still need the access it was granted?
• Is anyone still using it?
• Are the underlying models or APIs behaving differently now?
• Has the source data changed format?
• Does the automation still align with current policy and process?

In city planning terms, this is the public works department. Roads crack. Drainage fails. Traffic patterns change. Some paths need widening because they became critical infrastructure. Others should be closed because the need disappeared.

The same thing happens with citizen-built software. Some tools will prove valuable enough to formalize into fully supported applications. Others should expire automatically unless someone actively renews ownership and validates their continued use.

If you don't build maintenance into the system from the beginning, today's paved path becomes tomorrow's forgotten infrastructure problem.

5. The Skill Libraries: Your Signage and Lighting

Smart cities don't just pave desire paths. They add lighting, signage, and benches. They make the path better than the grass was.

For citizen developers, this means pre-built, vetted capabilities they can use instead of building from scratch:

• Pre-approved integrations: vetted connectors to internal systems, such as read-only Salesforce access, Slack posting, or Jira ticket creation.
• Template repositories: starter projects with security best practices already baked in: environment variable management, logging, error handling, input validation.
• Curated model access: purpose-specific model configurations for summarization, data extraction, code generation, and other common patterns.

The Role That Emerges

Here's the part software developers should actually pay attention to.

The city planners didn't disappear when cities started paving desire paths. The profession matured. The job shifted from "design where people should walk" to "design systems that accommodate where people do walk."

That's what's happening in software development.

The highest-leverage work isn't writing the compliance deadline tracker. It's building the platform that lets the compliance officer build it safely.

It's the gateway, the proxy layer, the policy engine, the scanning pipeline, the sandboxed runtime, the skill libraries, and the lifecycle controls.

The enduring engineering advantage shifts upward into platforms, governance, orchestration, and operational architecture.

What I'm Actually Doing About It

I'm not writing this from theory. I'm the security leader who has to make a decision: fence or sidewalk?

Here's my approach:

1. Acknowledge the desire paths exist. The shadow AI tools are already in your environment. Pretending otherwise is negligence, not strategy.
2. Instrument before you govern. Before writing policies, understand what's actually happening. Where are the API calls going? What data is flowing? What tools are people building?
3. Build the governed path. Stand up the gateway, the proxy layer, the scanning pipeline. Make the official path easier than the unofficial one.
4. Make the right thing the easy thing. Every security control that adds friction to the citizen developer's workflow is a control they'll route around.
5. Audit continuously, review periodically. Automated scanning catches the baseline. Periodic human review catches the architectural issues. Neither alone is sufficient.

The Uncomfortable Conclusion

The software development industry spent decades building beautiful, winding paths through meticulously planned courtyards: frameworks, design patterns, architectural review boards, sprint ceremonies, code review processes.

Then someone handed everyone an AI assistant and they cut straight across the grass.

That's not a failure of the people walking.

That's feedback about the path.

The question for security leaders isn't whether to allow it. It's already happening. The question is whether you're the one who paves the path with proper drainage, or the one standing next to a KEEP OFF THE GRASS sign watching everyone walk through the mud.

I know which one I'm choosing.