Security Teams Struggle to Tame 'Wild Code' from Rogue AI Development

“Sandboxes solve the design problem and leave the runtime problem alone.” — Brad Rumph, field CTO at Tines

A sales manager’s experiment illustrates how "wild code" spreads

The report opens with a concrete example: a sales manager builds an AI‑assisted workflow that connects to customer records, summarizes inbound requests, and posts updates to a shared channel. The workflow delivers value quickly, saves time, and becomes part of daily routine. Across the same organization, other employees begin creating apps, agents, and automations at a pace existing processes do not anticipate — the phenomenon the report calls "wild code."

Excessive permissions, data exposure, and orphaned access: the core technical risks

Wild code is not just unapproved software; it is new capability created by employees that can become an operational dependency before security knows it exists. The report lists five concrete failure modes that security teams must confront:

• Excessive permissions: workflows running with credentials that can read or modify far more than they need.
• Sensitive data exposure: agents connected to information they don't need, outputs shared too broadly, or sensitive data ending up in model requests or logs.
• Unintended actions: agents changing records or permissions without an appropriate approval boundary.
• Orphaned access: workflows continuing to run after their creator moves roles or leaves, with no accountable owner reviewing permissions.
• Investigation gaps: when something goes wrong, security cannot readily determine which identity ran the workflow, what it accessed, or what changed.

Why education, sandboxes, and steering committees are necessary but insufficient

The report cautions that familiar mitigations create important but incomplete protections. Education and AI policy can explain good practice, but they do not enforce behavior; employees under deadline pressure may follow faster workarounds rather than slow governance paths. Sandboxes protect experiments, not the subsequent runtime: a successful prototype will typically need to access live business systems and requires permissions, monitoring, and change reviews that persist into production. And steering committees, while useful for direction and accountability, cannot review what they cannot see; their cycles may not match the speed at which employees create and deploy useful builds.

As Brad Rumph puts it, sandboxes answer design questions but leave operational controls unaddressed — a gap the report argues must be closed by building governance into the environment where employees create and run their work.

Govern before deployment: three practical principles for built‑in controls

The report prescribes putting controls where the work happens, and it lays out three interlocking principles:

• Govern before deployment, and keep governing afterward: define permitted data sources, actions, and access before employees connect systems, and retain those controls when workflows go live. Permissions should reflect the workflow’s needs, and consequential actions should require human approval enforced by systems rather than prompts.
• Make the approved route the easiest route: provide accessible building experiences, useful connections to approved systems, and a clear path from idea to operation so sanctioned options meet users’ needs and discourage risky workarounds.
• Make investigation and intervention part of design: ensure ownership, execution identities, relevant actions, and changes are traceable; protect logs from unnecessary exposure; and establish who can pause a workflow, revoke access, and determine what it affected.

Accountable ownership, controlled access, protected execution, and traceability in practice

Putting those principles into practice means making specific questions answerable without ad hoc investigation. A governed environment should show:

• Accountable ownership: who owns the workflow and which identity it runs as.
• Controlled access: what the workflow can read, change, and send, and which actions require enforced approval.
• Protected execution: steps isolated and credentials injected at runtime rather than embedded in code, complemented by appropriately scoped permissions.
• Traceable activity and clear intervention: the ability to establish what ran, what it accessed, what changed, and how security can stop execution and revoke access.

What this means for technologists and security teams, IT and system owners, and employees

• Technologists and security teams: must shift from policing after the fact to defining shared boundaries, applying consistent lifecycle controls, and ensuring monitoring and intervention mechanisms remain connected to live workflows.
• IT and system owners: need to collaborate with security to set explicit boundaries for which business data and actions are permitted, and to make those sanctioned connections practical and accessible.
• Employees building automations: should expect an approved, usable route from prototype to production that embeds least privilege, secrets management, and runtime protections so doing the right thing is also the fastest thing.

Built‑in governance does not eliminate every risk, but the report argues it reduces reliance on memory and discovery — making employee-driven innovation visible, supportable, and secure from the start. It frames this approach as 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, the report points readers to the downloadable guide "Taming wild code: The IT leader’s guide to AI code sprawl."

Original story