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. The workflow saves time, reduces manual work, and soon becomes part of the team’s daily routine. Across the same organization, employees are building useful apps, agents, and automations faster than existing processes can support them.
If you work in security, that success introduces a new set of questions. Whose credentials does the workflow use? Which records can it access? Who can see its output? If it starts exposing information it shouldn’t, can you 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 simply another name for unapproved software. Employees are creating new capabilities, not just 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 operate with too much access or expose data to the wrong audience:
- Excessive permissions. A workflow needs a small set of records but runs with credentials that can read or modify far more.
- Sensitive data exposure. An employee connects an agent to information it doesn’t need, or makes its output available too broadly. Sensitive information can also end up in model requests or logs.
- Unintended actions. An agent can change records or permissions without an approval boundary appropriate to the action.
- Orphaned access. A useful workflow keeps running after its creator changes roles or leaves, with no clear owner reviewing its permissions.
- Investigation gaps. When something goes wrong, security can’t readily establish which identity ran the workflow, what it accessed, or what changed.
Employee education, sandboxes, and AI steering committees are a good start, but they aren’t enough to control wild code on their own. 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.
Why the usual fixes fall short
Education, sandboxes, and steering committees all have a role. The mistake is expecting them to govern software they may never encounter, or control what happens after it starts running. A policy describes what should happen. Security also needs controls that constrain what can happen, evidence of what did happen, and a way to intervene.
1. Education explains good practice, but can’t enforce it
An AI policy can explain what’s allowed. Training can introduce good practices. Neither guarantees that someone building a reporting workflow will recognize the moment they cross into handling sensitive data or operating production software.
As AI brings more employees into building software, organizations have an opportunity to make practices like least privilege, secrets management, and separating test environments from production more accessible. Policies can set expectations, but employees also need practical guidance and built-in safeguards to apply them in everyday work.
Even employees who recognize a risk still face deadlines and pressure to move faster. If the approved route is slow or confusing, knowing the rules doesn’t make following them easier.
Education helps people make better decisions. It shouldn’t be the only thing preventing an unsafe connection or an unauthorized action.
2. Sandboxes protect experiments, not their entire future
An isolated environment is useful for testing prompts, models, and generated code. But a prototype’s value often depends on eventually reaching real business systems and data.
Once a prototype connects to live business systems, it needs controls that extend beyond the test environment. Permissions, monitoring, and change reviews have to remain in place throughout its working life, not just during the experiment. A successful test doesn’t establish which data the production workflow should access or which actions it should be allowed to take.
As Brad Rumph, field CTO at Tines, puts it: “Sandboxes solve the design problem and leave the runtime problem alone.”
A successful experiment still needs a governed path into operation. Without that path, isolation postpones the hard questions rather than resolving them.
3. Committees can’t review what they can’t see
Steering committees can set direction, establish accountability, and make decisions about high-risk use cases. But their review cycles don’t always match the speed at which employees can create and deploy software.
A committee might prohibit one risky practice while employees discover another way to achieve the same result. Oversight can also concentrate on engineering, where established controls already exist, while overlooking builds in finance, HR, or operations.
The limitation isn’t the quality of the committee. It’s a model that depends on each build becoming visible before it becomes useful. An approval process can’t be the only way security discovers new paths to sensitive data and privileged actions.
Put security controls where the work happens
The alternative is to build controls into the environment employees use to create, run, and maintain their work.
Rather than asking everyone to independently assemble a secure operating model, security teams define shared boundaries with IT and system owners, apply them consistently throughout the lifecycle, and update them as business needs and risks change.
Three principles make this practical.
1. Govern before deployment, and keep governing afterward
Define permitted data sources, actions, and access before employees connect business systems. Keep those controls in place when the workflow goes live.
Permissions should reflect what a workflow needs to do, not everything its creator can access. Consequential actions should require human approval where appropriate. A prompt telling an agent what not to do is not an access control.
Keep creation, execution, and monitoring connected. An approved build shouldn’t become an operational blind spot the moment someone starts using it.
2. Make the approved route the easiest route
Employees need more than a list of restrictions. Give them an environment that lets them solve real problems quickly.
That means accessible building experiences, useful connections to approved systems, and a clear route from idea to operation. Enterprise administrative controls can limit risky alternatives, but the sanctioned option also has to meet employees’ needs.
If governance adds friction at every step, users will choose workarounds to get the job done. Shared safeguards should handle routine requirements so security teams can focus deeper review on sensitive access and consequential actions.
AI can help create an application or agent. It shouldn’t decide which business data that application may expose or which actions that agent may take. Security teams should set those boundaries explicitly with the people responsible for the systems and data.
3. Make investigation and intervention part of the design Security
needs to understand what a workflow did, not just what it was intended to do.
Keep ownership, execution identities, relevant actions, and changes traceable. Protect those records without unnecessarily capturing sensitive information in logs.
Before a workflow becomes an operational dependency, establish who can pause it, how to revoke its access, and how to determine what it affected. Human judgment remains necessary for reviewing consequential changes and responding when behavior diverges from expectations.
What this looks like in practice
A governed environment should make important security questions answerable without a separate investigation:
- Accountable ownership. Who owns the workflow, and which identity does it run as?
- Controlled access. What can it read, change, and send elsewhere? Which actions require approval, and where is that enforced?
- Protected execution. Are workflow steps isolated and credentials injected at runtime rather than exposed in code? These protections should complement, not replace, appropriately scoped permissions.
- Traceable activity. Can security establish what ran, what it accessed, and what changed?
- Clear intervention. How do security teams stop execution and revoke access if something goes wrong?
These controls don’t eliminate every risk. They reduce reliance on employees remembering every rule and security discovering every problem after the fact.
Keep control as more people build
Employees will keep finding valuable ways to build with AI. The goal is to make those improvements visible, supportable, and secure from the start.
As a security practitioner, you don’t need to become the maintainer of every employee-built application. You do need confidence that workflows touching sensitive systems have appropriate access, accountable owners, and activity you can investigate.
Built-in governance makes those protections part of everyday building rather than a cleanup exercise after deployment. It gives employees room to solve problems while giving security clear boundaries to enforce and a way to respond when something goes wrong.
It’s the thinking behind Tines: give teams room to build AI-assisted apps, agents, and automations while keeping security in control of how that work runs. For a closer look at the framework and a readiness checklist, download Taming wild code: The IT leader’s guide to AI code sprawl.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.