AI Sprawl Is the New Shadow IT: How We Got Ahead of Ours

Key Takeaways (TL;DR)

• AI agent sprawl is the new shadow IT: easy creation outruns governance, exactly as it did with SaaS, cloud, and API sprawl.
• You can’t govern what you can’t see. Postman surveyed teams and got five different answers; system data revealed 866 agents and apps running from Slack.
• Agents in production are software in production: they carry real risk, real cost, and act on their own, so they need ownership, observability, and controls.
• A cleanup alone doesn’t work. Sprawl returns unless you govern at the moment of creation, not the moment of audit.
• Postman built Astropods so every new agent gets ownership and cost attribution from day one, turning an inventory into a fleet you can actually run.

Ask five people at your company how many AI agents or copilots, reachable from Slack or Teams, are running somewhere in the organization right now.

You will get five different numbers, and all of them will be too low.

We ran this same experiment inside Postman before we had a product story to tell about agent governance. The number that came back was higher than anyone had guessed, and it took a while to believe it.

Shadow IT is back, wearing a new face

The arrival of generative AI over the last couple of years rewarded speed and experimentation. Builders shipped code with AI faster than ever and with great exuberance, and the definition of a builder expanded to anyone with API keys and a coding agent. Anyone with an idea could vibe it into existence and ship it to production. Apps became AI-assisted and then agentic, handing tasks to an LLM, including plenty of tasks that never needed AI in the first place. Agents got wired into real systems, and they ran in production with few guardrails, if any. The people doing it wanted to prove the value fast. Sprints ended, budgets closed, and nobody wanted to be caught still building when that happened. They wanted the job done quicker too, and for a while, that’s what happened.

That phase is closing for three reasons that have nothing to do with AI enthusiasm running out.

1. AI is expensive. AI costs money, and that cost scales with how much you use it, so you can’t just point it at everything and hope it pays for itself. The bill follows usage, so what you approved in January isn’t what you pay in March. Without monitoring spend at the level of the agent itself, you can’t tell which dollars are earning their keep. One agent doing useful work looks identical on the invoice to one stuck in a loop. Once you can see that difference, you double down on what’s working. The rest gets redirected or shut off.
2. Agents in production are software in production. Something you vibe coded in an afternoon and then wired up to real systems and production data carries the same risk as any other code you ship, maybe more, because it acts on its own. Built without guardrails or monitoring, an agent like that stops being a tool and starts being a liability. Nobody decided to hand it that much control, but that’s what a credential and a task queue amount to. Treat it as the complex software it is, or something else will end up running your business for you.
3. We already know how this ends. Unpatched systems turned into breaches. Shadow IT and cloud sprawl kept security teams playing catch-up for years. API sprawl did the same thing to access control. AI does not get a pass just because the code writes itself. That sequel is already running. Most organizations don’t have a clean count of how many credentials are sitting in agent configs right now, or how many systems are quietly wired to them. Look closely and it gets uncomfortable fast.

The organizations that will do well in the next phase are the ones that can see and steer what they have already built. A high agent count mostly tells you people have been busy. When three teams solve the same problem separately, you get one solved problem and two more things to maintain that nobody budgeted for. Seeing the whole set is what lets you decide what to keep.

Nobody did anything wrong here, which is what makes it hard. AI incentivizes invention and experimentation, so we saw marketing picking up tools that solved real problems for themselves, and support ended up with a collection of its own agents to solve theirs. In another part of the org, engineers built something useful over a weekend, but security never heard about any of it. Why? Because as AI experimentation turned into shipped products, there was no moment in the process where security or infra was supposed to hear about it. Each of those choices made sense to the people making them, and together they built up risks the company never agreed to take on.

None of this is new, and anyone who lived through SaaS or cloud will recognize the shape of it. Easy creation outruns governance every time. Some companies catch up on purpose. Others only catch up after an incident, and by then it costs more than governance ever would have. Agents are moving faster than either of those waves, because building one now takes an afternoon.

What we actually needed

We understood that the agents already running provided value to someone, but we needed to know what existed and what each one was doing before we could act on any of it. Getting there let us address the three problems already described: tracking AI spend and investment, treating these agents as production software with proper governance and oversight, and avoiding a repeat of the mistakes from the past decade. This is why Postman built and launched the Astropods agent platform (Astro for short), and why Astro is now the standard platform for building and running agents at Postman.

Astro gives us three things at once.

Visibility: If you can’t see it, you can’t govern it

The hardest part of this endeavor was getting one list everyone believed. We built it from usage records rather than opinion, since opinion is what produced five different answers in the first place. The records showed 866 apps and agents running from Slack, well above what anyone in the room had estimated. Nobody on the team was careless, and we were still off by a lot.

That inventory lives on the front page of Astro now, and every agent the company runs is hosted on Astro.

Observability: knowing an agent exists is not enough

The inventory answers whether something exists. It doesn’t answer whether it matters. A dormant app that nobody opens and an agent making thousands of model calls a day against sensitive systems land on the same list, but they don’t belong there as equals.

The old SaaS playbook, built for software that sat still until someone opened it, doesn’t make that distinction either. It asks static questions, like what’s installed and who owns it. Whether the license is still current is about the most dynamic thing it tracks. An agent may be out there calling models, spending tokens, touching data and making decisions on a schedule nobody is watching, so knowing one exists tells you little about what it’s up to.

So we treat agent behavior as telemetry: who uses each one, how often, at what cost, against which systems. Because agents run on Astro, that data arrives by default instead of being retrofitted agent by agent. Once you have it, the question stops being whether to allow something and becomes what it does and what it is worth.

Control: deciding what stays

Once we had the inventory and could see real use rather than guess at it, the decisions became straightforward and defensible.

To start wrangling our own agent and Slack app sprawl, we first contacted owners to tell them what we were doing and why, and to give them a chance to weigh in, rather than retiring apps unilaterally. Some apps were duplicates, or had been abandoned outright, and got retired. The real agentic use cases and AI-assisted apps needed a new home on Astro. Of the original inventory, roughly 96 percent of those marked “low and no usage” (618 apps) was retired, and the remainder were migrated onto Astro.

Owner outreach at this scale is not a job for a person with a spreadsheet. We scripted it: pull the owner from the app record, send a message with the usage numbers attached, wait, then act on the reply or on the silence.

# One admin API call retires one Slack app.
resp = session.post(
    "https://slack.com/api/admin.apps.uninstall",
    json={"app_id": app_id, "enterprise_id": enterprise_id},
    headers={"Authorization": f"Bearer {token}"},
    timeout=30,
)

if resp.json().get("ok"):
    row["Status"] = "Uninstalled"   # written back to the CSV, so the run resumes if interrupted

=== Summary ===
Uninstalled: 592
Skipped:     26   (kept per outreach status)

Code samples are illustrative and provided as-is, without warranty. Review, test, and adapt them before use, including scoping API tokens to least privilege and reviewing AI-generated changes before deploying.

The 96% makes for an interesting headline, but the number we actually care about is the smaller set of apps and agents that came through with a named owner and a clear purpose, plus a cost you can look up. Every agent in that set now has spend tied to a person and usage tied to a system, with an owner who signed up to answer for both. That’s what turns an inventory into a fleet you can actually run. A big fleet you understand is worth more than a small one you’re only guessing about.

Making it stick

A purge like this is satisfying to run, because the count drops and somebody gets to show leadership a dashboard that says everything’s fine, and a clean story. The sprawl comes back, because nobody changed how agents get created in the first place. Our first inventory covered a fixed window of history, which meant anything created after that window was already invisible again by the time we finished the run.

That realization reframed our entire effort around building a path forward, a system that keeps the count honest instead of one clean sweep that goes stale again. New agents now get created on Astro, so ownership and cost attribution come attached from the first day instead of being reconstructed later, and the inventory stays current because an IT-enforced process routes new agent builds through it.

Migration was the part we expected to be slow (but turned out to be quicker, thanks to AI). Each app needed its codebase reshaped for Astro deployment, and doing that by hand across dozens of repositories wasn’t realistic, so we wrote a Claude skill for it and ran the same conversion every time.

#!/usr/bin/env bash
# migrate-fleet.sh — Batch-migrate a fleet of agents onto Astropods
# using Claude Code's `migrate-to-astropods` skill (headless mode).
set -euo pipefail

# One line per repo you want to migrate.
APPS=(
  "git@github.com:acme/ticket-triage-agent.git"
  "git@github.com:acme/release-note-helper.git"
  "git@github.com:acme/sales-research-agent.git"
  "git@github.com:acme/github-issue-scorer.git"
  "git@github.com:acme/customer-follow-up.git"
)

WORKDIR="$(mktemp -d)"
REPORT="$WORKDIR/migration-report.md"
echo "| App | Files added | ast | Notes |"   > "$REPORT"
echo "|-----|-------------|-----|-------|"   >> "$REPORT"

for repo in "${APPS[@]}"; do
  name="$(basename "$repo" .git)"
  echo "▶ Migrating $name …"
  git clone --depth 1 "$repo" "$WORKDIR/$name" >/dev/null 2>&1
  pushd "$WORKDIR/$name" >/dev/null

  # Hand the repo to Claude Code and let the skill do the port.
  # --permission-mode acceptEdits lets it write astropods.yml / Dockerfile / AGENT.md unattended.
  claude -p "Use the migrate-to-astropods skill to port this project to Astropods. \
Detect the runtime and entry point from the code, add astropods.yml, Dockerfile, \
and AGENT.md, and do not modify any agent logic. Proceed autonomously." \
    --permission-mode acceptEdits \
    --allowedTools "Read,Edit,Write,Bash,Skill" \
    > "$WORKDIR/$name.log" 2>&1

  added="$(git status --porcelain | awk '{print $2}' | paste -sd', ' -)"

  # Verify the container actually builds and services come up.
  if timeout 300 ast project start --detach >/dev/null 2>&1; then
    status="✅"; note="built & started"
    ast project stop >/dev/null 2>&1 || true
  else
    status="❌"; note="see $name.log"
  fi

  echo "| $name | ${added:-–} | $status | $note |" >> "$REPORT"
  popd >/dev/null
done

echo
echo "Fleet migration complete. Summary:"
cat "$REPORT"

Each run ends with a summary like this:

Fleet migration complete. Summary:

| App                  | Files added                         | ast | Notes           |
|----------------------|-------------------------------------|-----|-----------------|
| ticket-triage-agent  | astropods.yml, Dockerfile, AGENT.md | ✅  | built & started |
| release-note-helper  | astropods.yml, Dockerfile, AGENT.md | ✅  | built & started |
| sales-research-agent | astropods.yml, Dockerfile           | ✅  | built & started |
| github-issue-scorer  | astropods.yml, Dockerfile, AGENT.md | ✅  | built & started |
| customer-follow-up   | astropods.yml, Dockerfile, AGENT.md | ✅  | built & started |

Code samples are illustrative and provided as-is, without warranty. Review, test, and adapt them before use, including scoping API tokens to least privilege and reviewing AI-generated changes before deploying.

What separates a company that runs a cleanup from one that has a system comes down to timing: governance at the moment of creation, or governance at the moment of audit.

That timing also decides how the audit itself goes. Many EU AI Act obligations began applying in August 2026, with high-risk requirements phasing in from December 2027. Voluntary frameworks like the NIST AI Risk Management Framework call for documented roles and responsibilities, traceability, and the ability to act on what you find.

What we got wrong

This went better than we expected, but there were some lessons to pass on:

• Some agents cannot be retired by the team doing the retiring. One app came back with an uninstall error because it was protected and managed elsewhere in the organization. Governance work runs into systems you do not control, so the plan needs room to escalate by hand rather than treating every item as scriptable.
• A gap in the process looks exactly like a gap in the policy. A few agents survived the run untouched because the outreach message never went out. When the whole outreach process runs on owner replies, a message nobody sent becomes a silent exception. We added a check for that: unsent outreach flags itself now, instead of quietly passing as resolved.
• Usage data decides less than we assumed. Some owners asked to keep agents the numbers had flagged for retirement, and several more never reached a decision at all. Low usage was a good indicator for knowing who to call. What happened after that depended on the person who actually understood what the agent was for. Now an unresolved case gets escalated to a manager after a set window, instead of sitting on the list indefinitely.

Where to start

Three questions are worth putting to your teams this quarter:

• How many agents are running right now, and how do we know? If the answer comes from a survey rather than system data, it’s wrong.
• Which of those agents can we explain? Who owns it, what is it for, what does it cost, what data does it reach. An agent nobody can explain will be hard to defend when someone asks.
• What happens when someone builds the next one? If the answer involves finding it in the next audit, you have just scheduled the next round of sprawl.

Skip these questions and the costs pile up quietly: more exposure, more duplicated spend, compounding until an audit finds it for you. Ask them, and leadership ends up able to see what AI is doing well enough to let it keep growing.

Go ask five people

The agent count inside Postman has gone up since we did this work, and we’re fine with that, because we can see it now.

Sprawl like this never sets off an alarm, which is what makes it awkward to deal with. You find out when somebody asks who owns a particular agent and the room goes quiet. Every week adds a few more to the pile you’ll have to account for eventually, and the accounting gets harder the longer it sits there.

Go ask five people. If you get five different answers, this is already bigger than anyone at your company thinks, and it’s time to get hold of it.

We’ve been where you are. Our Forward Deployed Engineering team ran this inside Postman first, sideways parts included, and now runs it for customers. Sign up for Astro and do it yourself, or talk to one of our forward-deployed engineers. We’ll help you see what’s actually running and bring it under your control, for good.

Frequently Asked Questions

What is AI agent sprawl?

AI agent sprawl is the uncontrolled proliferation of AI agents, copilots, and AI-assisted apps across an organization, often created faster than security, infra, or finance can track them. Like shadow IT before it, sprawl happens because building an agent now takes an afternoon, and there’s no checkpoint where governance is supposed to hear about it.

Why is AI agent sprawl considered the new shadow IT?

Because it follows the same pattern: easy creation outruns governance. Unpatched systems became breaches, cloud sprawl kept security teams playing catch-up, and API sprawl strained access control. AI agents move even faster and unlike static SaaS, they run on schedules, spend tokens, touch sensitive data, and make decisions on their own.

How many AI agents is my company actually running?

Almost certainly more than anyone estimates. When Postman asked five people, it got five different answers, all too low. The real number, pulled from usage records rather than opinion, was 866. If your count comes from a survey instead of system data, it’s wrong.

How do you govern AI agents effectively?

Start with visibility (an inventory built from usage data, not opinion), add observability (who uses each agent, how often, at what cost, against which systems), then apply control (retire duplicates and abandoned apps, and give every surviving agent a named owner and clear purpose). Most importantly, enforce governance at creation so the inventory never drifts again.

What’s the difference between agent inventory and agent observability?

Inventory answers whether an agent exists. Observability answers whether it matters: a dormant app and an agent making thousands of model calls a day against sensitive systems land on the same list but aren’t equals. Treating agent behavior as telemetry is what lets you decide what to keep.

How do you stop AI agent sprawl from coming back?

A one-time purge goes stale because it doesn’t change how agents get created. The durable fix is governance at the moment of creation: new agents are built on a platform where ownership and cost attribution are attached from day one, so there’s no way to build outside the inventory.

How does Postman help manage AI agent sprawl?

Postman built Astropods, an agent platform where Postman builds and runs its agents. It provides one view of all agents, production-grade controls, and per-team access, with usage and cost telemetry arriving by default. Postman’s Forward Deployed Engineering team ran this process internally first and now runs it for customers.

Slack, Microsoft Teams, Claude, and GitHub are trademarks of their respective owners. Their use here does not imply endorsement.