# What is shadow AI, and what it looks like in software development

> Shadow AI is AI use without IT or security approval. In software, it is code built with AI outside your review and deploy pipeline.

- URL: https://letsship.ai/blog/shadow-ai-in-software-development
- Author: Önder Ceylan
- Published: 2026-10-15

Shadow AI is the use of AI tools without the approval or oversight of an organization's IT or security teams. In software development, it is code and apps that people build with AI outside the review, test and deploy pipeline that engineering controls. Security pages treat shadow AI as a data-leak problem, and they answer with discovery and blocks. OWASP's guidance for AI-assisted development gives a different answer for code: offer a sanctioned path, and review everything that comes through it.

SHIP's [governed prototyping](https://letsship.ai/platform/governed-prototyping) is one such path. Its controls run today: every build runs in a sandbox, gets a review against your rules and deploys only through your pipeline. The workspace where people outside engineering describe and change prototypes is in early access.

## Define shadow AI

The two pages that rank first for the term define it in almost the same words. IBM's [What is shadow AI?](https://www.ibm.com/think/topics/shadow-ai) says:

> "Shadow AI is the unsanctioned use of any artificial intelligence (AI) tool or application by employees or end users without the formal approval or oversight of the information technology (IT) department."

[Palo Alto Networks](https://www.paloaltonetworks.com/cyberpedia/what-is-shadow-ai) adds AI agents and the security team. Its definition covers AI tools, systems and agents that people use without the approval or involvement of IT or security teams.

Both pages put shadow AI inside shadow IT. IBM describes shadow IT as any software, hardware or information technology that people use without the approval, knowledge or oversight of IT. Shadow AI is the AI part of that, and IBM gives it its own concerns about data, model output and decisions.

Both pages also write for a security team. Their examples are AI tools that receive company data, and the risks they list are data leaks, compliance and reputation.

## Find the shadow AI in your software

In a software company, shadow AI also produces software. A prototype, an internal tool or a small app can come out of an AI tool. It can then run for weeks before anyone in engineering reads its code. Nothing about it passes through the repository, the CI pipeline or a code review.

Palo Alto Networks gives a developer example: a small internal chatbot over customer data, built through a model API. In its words, "The project never enters the security backlog because it doesn't require infrastructure changes."

OWASP makes the same point for every tool that touches work. Its [DevSecOps Guideline](https://owasp.github.io/DevSecOpsGuideline/3-Governance/3-4-AI-Governance-and-Risk/) says that "Unapproved tools used for work data are shadow IT". The [OWASP SAMM guidance for AI-assisted development](https://owaspsamm.org/docs/guides/ai-assisted-development/) lists the ways data leaves an organization through AI. The last one on its list is "unapproved AI tools used outside the organization's control (shadow AI)".

## Name the risks in code built with AI

Code built outside the pipeline skips the checks that the pipeline exists for. The two OWASP guides name four of those checks for AI-assisted development:

* SAMM says to give AI tools no access to the build system, its secrets or the keys that sign your builds.
* SAMM also says: "Treat changes to pipeline definitions as security-sensitive: they require human review, also when proposed by an AI tool."
* The DevSecOps Guideline warns that models invent package names that do not exist. An attacker who registers one of those names gets code into your supply chain.
* The same guideline says that no AI-generated code is exempt from code review, security scans or tests.

SAMM also names the general problem: "When the rate of change grows faster than the organization's ability to verify it, risk accumulates silently". Shadow AI adds changes that nobody counts, so nobody sees the gap.

The DevSecOps Guideline puts the accountability in one line: "AI assists, but humans remain accountable for what is merged and shipped". Code that never goes through a merge has nobody accountable for it.

## Expect a ban to move the work out of view

A ban on AI tools does not remove the reason people use them. Palo Alto Networks lists the belief that a ban stops shadow AI among its myths. It says that blocked users move to more obscure, unmanaged tools that are harder to track. IBM reaches a similar view: "It might not be feasible to eliminate all instances of shadow AI."

SAMM's advice: "Offer sanctioned, well-configured AI tools to development teams early in the roadmap to reduce the use of unsanctioned tools". IBM lists sandbox environments among its guardrails too. For people outside engineering who build prototypes, the same logic points to a sanctioned path that ends in engineering's review.

## Give people a sanctioned path to the merge

A sanctioned path for AI-built software needs five controls. Each one answers an OWASP point above, and each one runs in SHIP today:

| Control                           | What SHIP does                                                                                                                                     | Docs                                                       |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Keep keys away from the AI        | Each build runs in an isolated sandbox. The container gets a placeholder, and SHIP adds the real key outside it, so the agent cannot read the key. | [LLM credentials](https://letsship.ai/docs/getting-started/llm-credentials)   |
| Review against your rules         | The Reviewer and QA read their instructions from `main`, so a pull request cannot change the rules for its own review.                             | [Agent prompts](https://letsship.ai/docs/configuration/agent-prompts)         |
| Protect the pipeline              | SHIP checks every change before the commit exists and blocks a change under `.github/workflows/` that nobody asked for.                            | [Connect GitHub](https://letsship.ai/docs/getting-started/connect-github)     |
| Deploy only through your pipeline | Your delivery pipeline deploys each preview with its own secrets. SHIP holds no credential for your cloud account.                                 | [Deployments](https://letsship.ai/docs/configuration/deployments)             |
| Merge only with merge rights      | Every prototype ends as a pull request. Auto-merge is off unless you turn it on for a project or a mission.                                        | [Human in the loop](https://letsship.ai/docs/configuration/human-in-the-loop) |

The DevSecOps Guideline also asks for human approval, an audit trail and a kill switch for agents. Checkpoints hold a mission after the plan, after CI or after the review until an engineer resumes it. Stop ends a mission at any point, and the pull request stays open. SHIP stores the full session, prompt, token usage and cost of every agent run before the agent reports back ([How SHIP works](https://letsship.ai/docs)).

With this `ship.yml`, every mission pauses after the plan and after the review until an engineer resumes it:

```yaml title="ship.yml"
agents:
  planner:
    checkpoint: true
  reviewer:
    checkpoint: true
```

Spend has a limit as well. A mission stops at $5 by default, and it pauses at 2 credits or 6 agent-hours until a member of your organization approves more. The same line of stages is what an [AI software factory](https://letsship.ai/blog/what-is-an-ai-software-factory) runs, with the merge kept for a person. To hand SHIP a prototype that already exists, see [AI prototype to production](https://letsship.ai/blog/ai-prototype-to-production).

## Check what runs today

SHIP's governed prototyping is in early access, but the controls in the table are live. A teammate can assign an issue to SHIP in Linear, or comment `@SHIP` on a GitHub issue from an account with write access. The prototype comes back as a pull request ([hand-off options](https://letsship.ai/docs/getting-started/ways-of-working)).

A teammate who writes a spec can send it with `ship delegate plan`. An AI assistant connected to SHIP's [MCP server](https://letsship.ai/docs/mcp) can file missions and follow them too.

Early access opens a workspace where people outside engineering describe a prototype and change it, with no tracker or terminal. Every prototype from that workspace will go through the same review, tests and pipeline as engineering's own work.

## Questions

### What is shadow AI?

Shadow AI is the use of AI tools without the approval or oversight of an organization's IT or security teams. IBM and Palo Alto Networks both define it this way, and both name data leaks and compliance among its risks.

### What is the difference between shadow AI and shadow IT?

Shadow IT is any software, hardware or service that people use without the approval of IT. Shadow AI is the part of shadow IT that involves AI tools. IBM adds that it brings its own concerns about data, model output and decisions.

### What are the risks of shadow AI in software development?

The main risks are code that skips review, secrets that reach an AI tool, unapproved CI changes and package names that a model invented. OWASP's guidance for AI-assisted development covers each one and says that no AI-generated code is exempt from code review.

### Does a ban on AI tools stop shadow AI?

No. Palo Alto Networks lists that belief among its myths about shadow AI, because blocked users move to tools that are harder to track. IBM also says that it might not be feasible to remove all shadow AI.

### How do you give people a sanctioned way to build with AI?

Give them a path that ends in your own review. In SHIP, every build runs in an isolated sandbox without your keys. The Reviewer checks it against rules from your main branch, your pipeline deploys it, and a person with merge rights merges it.

### Is SHIP's governed prototyping available today?

Partly. The controls run today. A teammate can hand an issue to SHIP from Linear or GitHub Issues and get the prototype back as a pull request. A workspace where people outside engineering describe and change prototypes is in early access.