Taming Wild Code: Why Security Teams Need Controls Built Into the Workflow

A sales manager builds an AI-assisted workflow to route leads. It connects to customer records, summarizes inbound requests, and posts updates to a shared channel. Soon it's part of the team's daily routine. Across the same organization, employees are building apps, agents, and automations faster than existing processes can support them.

For security teams, that success raises hard questions. Whose credentials does the workflow use? Which records can it access? Who sees its output? If it starts exposing information it shouldn't, can anyone trace what happened and stop further access?

Wild code takes root when useful builds spread faster than the processes for owning, securing, and maintaining them. It isn't just another name for unapproved software. Employees are creating new capabilities, not merely adopting existing products. A small experiment can become an operational dependency before security knows it exists.

The risk goes beyond vulnerabilities in generated code. Even code that works as intended can run with too much access or expose data to the wrong audience. Permissions may be excessive, sensitive data may leak into model requests or logs, agents may change records without an approval boundary, orphaned workflows may keep running after their creators leave, and investigations may stall because no one can establish which identity ran a workflow or what it touched.

Education, sandboxes, and AI steering committees all have a role, but they aren't enough on their own. Training explains good practice without enforcing it. Sandboxes protect experiments, not their entire future - as Brad Rumph, field CTO at Tines, puts it: "Sandboxes solve the design problem and leave the runtime problem alone." And committees can't review what they can't see.

A more sustainable approach builds controls into the environment itself: what employees can connect to, what their apps and agents can do, and how that work is monitored once it's running. Security teams should define permitted data sources, actions, and access before employees connect business systems - and keep those controls in place after go-live. The approved route also has to be the easiest route, or users will find workarounds.

Investigation and intervention should be part of the design. Keep ownership, execution identities, actions, and changes traceable. Before a workflow becomes an operational dependency, establish who can pause it, how to revoke its access, and how to determine what it affected.

These controls don't eliminate every risk. They reduce reliance on employees remembering every rule and on security discovering every problem after the fact. Built-in governance gives employees room to solve problems while giving security clear boundaries to enforce - and a way to respond when something goes wrong.