Shadow AI apps need identity controls before they hit Slack

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Runlayer's blog post: Agent-built internal apps can become shadow AI when they are shared faster than security can inventory them and when access is tied to the builder rather than the business owner.

Why it matters: IAM, NHI, and IGA teams need to treat internal AI-built tools as governed identities with shareability, access scope, approval, and offboarding requirements, not as harmless prototypes.

Context

The governance gap here is not just software sprawl, but identity sprawl around software that can be built and published outside normal engineering gates. When a business user can generate a live tool in minutes, the organisation needs a way to know who owns it, who can open it, and which permissions it inherits before it becomes another hidden access path.

The practical issue is that these tools behave more like governed internal applications than throwaway prototypes. They can read business systems, hold state, and expose links that circulate through collaboration channels, which means non-human identity governance and lifecycle control become part of application governance, not a separate conversation.

Key questions

Q: How should teams govern internal apps that can be built and shared quickly?

A: Teams should make governance part of the build path, not an afterthought. That means every internal app should carry a recorded owner, approved sign-in method, explicit permissions, and a revocable credential source before it is shared. The goal is to prevent each new app from becoming an unmanaged access island.

Q: Why do shared links create risk for internal tools?

A: Shared links create risk because they can bypass normal authentication and authorisation for an internal tool. If the link is guessable, forwarded, or left active after the intended use, anyone holding it may gain access to the underlying data or workflow. Use expiring tokens, authenticated sessions, and access checks tied to the user or service account.

Q: How can connector-based apps avoid secret sprawl?

A: Connector-based apps avoid secret sprawl by using one controlled integration identity, not copied credentials in each workflow or tenant. Store the connector secret in a vault, scope it to the minimum API actions, rotate it on schedule, and revoke unused instances. Where possible, replace shared master keys with per-connection tokens or delegated OAuth grants.

Q: What should security teams review before an internal app goes live?

A: Security teams should review who owns the app, what data it can reach, which groups or roles it inherits, and whether any privileged access is granted by default. They should also check authentication method, logging, external integrations, and joiner-mover-leaver handling for the people and service accounts behind it.

Technical breakdown

Why agent-built apps turn into identity-bearing assets

An internal app built by an agent is not just a page with text. Once it has a backend, it can store user input, call connected systems, and serve different content to different viewers based on identity. That makes it an identity-bearing asset: access is defined by company sign-in, viewer permissions, shared links, and the owner who approves changes. The security problem is that creation is easy, but governance is often external to the creation flow. The result is a tool that behaves like production software without passing through the controls that usually define production software.

Practical implication: Treat every agent-built app as a governed internal application with an owner, an access policy, and an audit trail from the first version.

Why connector-based access changes the risk model

The architecture matters because the app does not need embedded credentials if it reaches data through managed connectors. That removes one class of secret exposure, but it does not remove the governance burden. The important question becomes which identity the connector uses, whether the app runs with the viewer's access, and whether a shared tool can become a path into systems that users should not reach indirectly. In other words, the app is only as safe as the permission model behind the connector chain. See the NHI Authentication Guide.

Practical implication: Map every connector-backed action to the exact permissions it inherits and block indirect privilege amplification through shared internal tools.

Why approval gates matter more than the build step

The build itself is not the control point. The control point is whether a changed action can run before an owner reviews what it does, which systems it touches, and whose access it uses. If app updates deploy instantly, the permission model becomes unstable and the audit log trails after the change instead of constraining it. This is the same governance pattern seen in other fast-moving identity systems: the moment of issuance or approval matters more than the moment of discovery.

Practical implication: Require owner approval for any new or modified action before it can execute against business systems.

Threat narrative

Attacker objective: The objective is to turn an easy-to-create internal app into an unmanaged route to business data and actions without central oversight.

1. Entry happens when a business user or agent creates an internal tool outside the normal application pipeline and publishes it at a shareable link. The app appears harmless at first because the link is private until shared.
2. Credential exposure is avoided in the vendor model, but the real risk shifts to inherited access and connector scope. If permissions are too broad, the app can reach data and actions beyond what the creator should have assembled manually.
3. Impact follows when the link spreads across collaboration channels and the organisation loses track of ownership, sharing scope, and version history. At that point, the app becomes a shadow access surface rather than a managed internal tool.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now an access governance problem, not only a discovery problem. When business users can publish working tools without engineering help, inventory alone is too late. The organisation has to govern who can share the tool, which systems it can touch, and how ownership follows the account rather than the person who happened to create it.

Stable links create stable risk when the backend changes underneath them. A link that keeps working while the app is revised in place makes version history part of the control surface. That means approvals, change tracking, and offboarding need to apply to the app object itself, not just to the person who built it.

Connector-mediated access is the right design only when permissions are truly inherited, not amplified. If each viewer's own access controls what the app can do, the tool behaves like a governed interface; if a shared password or master key slips back in, it becomes an indirect privilege escalation path. The lesson is to measure app governance by the permissions model behind the connector chain, not by the visual polish of the page.

Ephemeral app creation breaks the assumption that review comes before exposure. Traditional application governance assumes a tool exists long enough to be registered, reviewed, and then shared. That assumption fails when a business user can create, publish, and circulate a live app in one sitting. The implication is not just faster review, but a different control model for software that appears before the governance process can catch up.

From our research library:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Identity-aware app governance will become a standard part of shadow AI control. The next control gap is not whether employees can build internal tools, but whether those tools are registered, permissioned, and retired with the same discipline as sanctioned applications. Programmes that only monitor code repositories will miss the faster growth path created by agent-built apps.

Owner-bound approval is the practical boundary between harmless prototypes and governed software. Once a business user can publish a live tool, every subsequent change to actions, connectors, or sharing rules needs to be treated as a control event. That pushes identity teams toward runtime governance, not just intake governance.

Linking build speed to access control is the only way to keep users on the approved path. If the sanctioned route is slower than the unsanctioned one, people will route around it. The winning model makes secure sharing, inherited permissions, and auditability the default path for internal app creation.

For practitioners

• Inventory agent-built internal apps centrally Create a single register for every artifact and app, including owner, shared audience, version history, and the systems each tool can reach.
• Bind app access to viewer identity Require company sign-in for every internal tool and make each action execute with the viewer's own permissions rather than a shared credential.
• Gate every action change before execution Hold modified actions for owner review until the new version has been checked against the connected systems and the access path it will use.
• Retire old projects and revoke their access paths When moving an internal tool onto a governed platform, delete the legacy project and remove any keys or shares that kept the old version alive.
• Treat collaboration shares as access events Track when a link is posted into Slack, teams, or role-based groups so sharing becomes part of the audit trail rather than an informal distribution method.

Key takeaways

• Agent-built internal apps can become shadow AI when they are shared faster than governance can register and review them.
• The main security issue is not only secret storage, but ownership drift, inherited permissions, and stale links that keep access alive.
• A usable control model makes approval, audit, offboarding, and connector scope part of the app lifecycle from the start.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs · NHI Authentication Guide · API Key Management Guide · Security Requirements and Abuse Cases Guide

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Stable Link: A stable link is a persistent URL or reference that continues to point to the same resource over time. In IT systems it is used for bookmarks, integrations, and sharing, and it may stay valid even when content changes, so access controls and link secrecy matter when the target is sensitive.
• Connector-Scoped Access: Connector-scoped access is access limited to what a specific integration connector can do. It confines credentials or permissions to one data source, API, or workflow, so the connector cannot act broadly across systems. The scope is usually enforced through least privilege, token boundaries, and per-connector secrets.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.