Decision guide

More people can build software. Give them a foundation to build on.

Turn AI policy into approved tools, practical safeguards, and a roadmap that helps your employees keep building.

AI enablement 8 min read Reviewed

The practical takeaway

Give ambitious employees approved tools, appropriate access, and a supported place to build. Start with one team or application, make the gaps visible, and turn them into manageable projects with clear owners and outcomes.

For: Business, IT, security, finance, and AI program leaders

You have an AI policy. Do you have control?

“Of course we have an AI policy. Everyone has a policy.”

We hear some version of that in conversations with technology leaders. Often, it comes with a nervous laugh. There is a lot wrapped up in that response: a fast-moving technology, expectations from the business, and people already finding their own ways to use it.

Once the laughter fades, there is a serious question worth asking:

How confident are you that the way AI is actually being used across your organization is within the bounds of that policy?

The next part of the conversation is understanding what supports that confidence. Which tools are in use? Where is company information going? What are employees building? Who can see the access those applications have and the costs they generate?

Those are consequential questions. The answers can affect customer relationships, valuable research, financial exposure, and the organization’s ability to grow with confidence. For the people accountable, they can also affect the trust they have spent a career earning.

That deserves a conversation where leaders can be candid about what they know, what they have verified, and where they need help.

A policy needs a practical path

AI has lowered the technical barrier to building software. An employee who understands a repetitive task can create a useful tool, share it with colleagues, and quickly find that others want it connected to business systems.

That initiative is worth supporting. As a prototype becomes part of how the business operates, decisions about access, information, support, and spending need to catch up.

A policy helps establish expectations. Employees also need approved tools, an appropriate environment, clear ownership, and a workable process for getting help and moving applications forward.

When those pieces are missing, the organization can be left with a dangerous gap between what leadership believes is happening and what employees can actually do. A published policy does not establish that sensitive information is staying in approved systems or that every new application has appropriate permissions.

For a leader trying to organize all of this, the size of the task can feel overwhelming. A useful response starts by making the unknowns visible and turning them into decisions and projects the business can manage.

Recent events show why the foundation matters

Several recent reports illustrate the pressure on the systems, credentials, and services businesses depend on.

PHP2Shell exposed weaknesses underneath applications. AI-assisted research helped turn complex PHP memory-management flaws into working exploits. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow remote code execution without authentication. Because they affect the underlying PHP runtime, an application can inherit exposure from the software beneath it. [1]

Linux research demonstrated the scale of AI-assisted exploitation. On November 4, OpenAI reported a research pipeline that produced working exploits associated with 948 distinct local privilege escalation vulnerabilities. These findings involved elevating an existing low-privilege foothold to root access. They were demonstrated in a controlled research environment, with candidate patches generated for review. [2]

ARTEX showed AI agents participating in real intrusions. CrowdStrike’s October 29 report described human-directed AI agents pursuing multiple attack paths across organizations. It reported activity targeting more than 200 organizations and confirmed post-exploitation activity at nine. Agents helped investigate systems, pursue credentials, and adapt when an approach failed. [3]

LLMjacking made the financial exposure tangible. GTIG and Mandiant’s November 2 report described criminals hijacking enterprise AI access and monetizing stolen capacity. Investigators observed unauthorized consumption charges exceeding $100,000 in a day and reaching $1 million at some organizations before access was revoked. These are reported charges, not a determination of final losses after billing adjustments. In some incidents, attackers enabled LLM services that were not active when the environment was compromised. [4]

These reports cover vulnerability research, active intrusions, and resource theft. Our assessment is that businesses need to account for AI’s effect on both sides of the equation: who can build and connect systems, and how attackers find and use weaknesses in those systems.

Give employees a supported place to build

As more people create applications and automations, the organization needs a repeatable way to answer a few practical questions.

Where should the work happen? Which identities and credentials should it use? What information can it access? What actions can it take? Who owns its operation and cost?

An approved environment brings those decisions into the work itself. Depending on the use case, that can include company-managed accounts, protected secrets, appropriate data permissions, separation between development and production, activity logs, consumption controls, and a clear route for review and release.

The safeguards should fit the application. A tool that summarizes approved reference material presents different decisions from an agent that changes customer records or initiates transactions. Employees need to understand how to move from one level of responsibility to another.

The consequences of getting those decisions wrong can extend beyond an unexpected technology bill. Customer information, internal research, and commercially sensitive material may be exposed. Recovery work, potential regulatory exposure, and damage to customer trust can follow.

An example of supported development

Consider a procurement employee building an application to compare supplier proposals. This is an illustrative scenario.

The first version helps organize pricing and summarize contract terms. It shows enough value that the employee wants to connect a shared document library and invite colleagues.

A supported approach gives that employee an approved workspace and sample proposals to develop against. Before real documents are connected, the appropriate owner decides what the application may access and how that information may be handled. Credentials are managed outside the code, access is limited to the work required, and usage is visible to the people responsible for the service.

Before wider release, the team checks that the comparisons are reliable, confirms who can use the application, establishes an owner, and agrees on support and spending expectations. A person remains responsible for reviewing the commercial decisions the tool informs.

The next employee with a similar idea can reuse much of that foundation. The organization gains a clearer path from a good idea to something it can support.

Make the work manageable

For technology leaders, AI adoption crosses teams that already have full workloads. A useful roadmap makes the decisions and responsibilities specific enough to act on.

Start with a defined part of the business. Choose a team, workflow, or application. Establish what is in use, what it connects to, and who owns it. Record what is known and where visibility is incomplete.

Address urgent gaps and define the foundation. Prioritize exposed credentials, inappropriate access, unclear ownership, or uncontrolled consumption. Identify which existing platforms and controls can support an approved approach, and where specialist help is needed.

Use one representative workload to put the approach into practice. Agree on the business outcome, data requirements, technical responsibilities, and criteria for release. Test the review process as well as the application.

Expand with a repeatable operating model. Reuse suitable patterns, make exceptions visible, and review access, ownership, cost, and performance as use grows.

Urgent remediation and a carefully scoped pilot can move in parallel. Each project should have a clear owner, an intended result, and a way to establish whether it is ready to move forward.

Six questions for the next internal conversation

Six questions for supported AI development
QuestionEvidence to bring
What exists?Known applications, automations, models, accounts, and intended uses
Who owns it?Business sponsor, technical owner, support responsibilities, and handover plan
What can it access?Data sources, permissions, connected services, and sharing arrangements
What can it do?Read and write permissions, actions it may take, and required approvals
What can it spend?Consumption records, quotas, spending controls, alerts, and escalation owner
Who responds when something changes?Logs, review responsibilities, incident contacts, and a way to revoke access

An unanswered question gives the next project a purpose. It helps turn a broad concern about AI into work a team can own.

Where GlobalLinc helps

GlobalLinc works alongside your internal team and existing providers to understand the environment, organize the decisions, and bring the right specialists into the work.

We can help connect current AI use with policy, identity, data access, cloud architecture, security, and cost. From there, we help define the approved approach and a phased roadmap with clear responsibilities for technical delivery and ongoing operation.

Your employees’ initiative can become a business advantage. Give it a foundation the organization understands and can support.

Have a team already building, an application ready for its next step, or a policy that needs practical support? Let’s talk through where to start.

Sources and further reading

Research reviewed November 5, 2026. The reports below provide the security context. The roadmap and working questions are GlobalLinc’s practical recommendations; the procurement example is illustrative.

  1. Google Cloud, Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619. Published October 21, 2026; updated October 23, 2026.
  2. OpenAI, A thousand fewer paths to root. November 4, 2026.
  3. CrowdStrike, VAPOR PANDA Uses AI-Driven ARTEX to Scale a Global Espionage Campaign. October 29, 2026.
  4. Google Threat Intelligence Group and Mandiant, The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources. November 2, 2026.

A practical next step

What is the next decision you need to make?

An AI policy, a production workload, a cloud architecture question, or a technology renewal. Start with the priority in front of you.

Let’s talk it through