Runtime governance is the answer to uncontrolled employee-built AI
Employees are rapidly creating AI-assisted applications, agents and automations that connect to customer records, summarize incoming requests and publish updates to shared channels. Tines describes this spread of useful, employee-built software as “wild code”: work that becomes operationally important faster than organizations can assign ownership, security controls and maintenance responsibilities.
The concern is broader than vulnerabilities in generated code. A workflow may function exactly as designed while using credentials with more access than it needs, exposing its output to an overly wide audience, sending sensitive information to model requests or logs, or continuing to operate after its creator has changed roles or left the company.
Why familiar governance measures are insufficient
Policies, employee education, sandboxes and AI steering committees all have a role, but Tines argues that none can independently govern software that remains undiscovered or constrain its behaviour after deployment. Policies set expectations; technical controls determine what a workflow can actually connect to, read, change and transmit.
Training cannot ensure that every employee will recognize when a useful reporting workflow begins handling sensitive data or becomes production software. Deadlines and a difficult approval path can also encourage workarounds, even where employees understand the stated rules. The article calls for practical guidance and built-in safeguards around least privilege, secrets management and separation of test and production environments.
Sandboxes help teams test prompts, models and generated code, but successful prototypes often need access to live systems and business data. Brad Rumph, field CTO at Tines, says that “Sandboxes solve the design problem and leave the runtime problem alone.” Permissions, monitoring and change reviews therefore need to continue when an experiment becomes a working service.
Steering committees can establish accountability for high-risk use cases, yet their review cycles may not match the speed at which employees build and deploy new tools. They can also focus on engineering while missing applications created in finance, HR or operations. An approval process alone cannot be the sole discovery mechanism for new paths to privileged actions and sensitive data.
Controls should follow the workflow into production
Tines recommends defining permitted data sources, actions and access before a workflow connects to business systems, then preserving those controls throughout its lifecycle. Permissions should reflect the work the workflow must perform rather than all of the access held by its creator. Prompts are not access controls, and consequential actions may require human approval.
A governed environment should retain accountable ownership, execution identities, relevant actions and changes in records that security can investigate. It should also establish how a team can pause a workflow, revoke its access and identify what it affected. Logs need protection as well, without unnecessarily collecting sensitive information.
Making the secure route workable
The approved route must be usable, not simply restrictive. Tines calls for accessible building tools, useful connections to approved systems and a clear path from an idea to an operational workflow. Shared safeguards can address routine needs while security teams direct deeper review towards sensitive access and consequential actions.
For businesses, the practical implication is to treat employee-built AI workflows as runtime assets: assign an owner, scope their identities and permissions, make activity traceable, and define intervention procedures before they become dependencies on critical systems.