Union Station shows how governed app sprawl becomes an identity platform

At a glance

What this is: NHI Mgmt Group's analysis, drawing on C1.ai's blog post: Internal platform unifies deployment and governance for company apps, and making the governed path easiest reduces shadow sprawl and unmanaged accounts.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly have to govern internal apps, bots, and automation as identity-bearing workloads, not as ad hoc side projects.

👉 Read C1.ai's post on Union Station and governed app sprawl

Context

Governed app sprawl is the security gap that appears when internal teams build tools, bots, and automations outside a controlled deployment path. In practice, the problem is not whether people will build software, but whether identity, authentication, and governance are attached to it from the start.

C1.ai's Union Station is presented as a single internal platform for internal tools, Slack bots, AI-powered apps, cron jobs, onboarding and offboarding workflows, and full applications. The article's core point is that governance becomes practical when deployment is easier through the sanctioned platform than through personal accounts or one-off infrastructure.

That framing matters for IAM and NHI programmes because the subject is no longer just user access to applications. It is also how internal app builders, service workflows, and AI-powered utilities inherit authentication, RBAC, inventory, and control from the platform they run on.

Key questions

Q: How should security teams handle internal apps that people will build anyway?

A: Treat the internal platform as the required identity boundary for those apps. If builders can bypass it, you lose ownership, authentication, and offboarding before the tool becomes visible. The better approach is to make the sanctioned path faster than the workaround so security and developer productivity move together.

Q: Why do shadow AI apps create identity governance risk?

A: Shadow AI creates risk because the application can be adopted outside approved procurement and still move sensitive data. That means identity teams need to know who is using the tool, whether the use is authorised, and whether the session should be blocked, monitored, or reviewed.

Q: What breaks when internal automations are not registered in a governed platform?

A: Inventory breaks first, then accountability. Teams may still use the tool, but security cannot reliably answer who owns it, what permissions it has, or how to retire it. That is how a convenience script turns into unmanaged identity sprawl.

Q: How should IAM teams evaluate modern IGA platforms?

A: IAM teams should evaluate IGA platforms on governance coverage, evidence quality, and how well they handle different identity types. The key test is whether the platform can support consistent decisions across human access, machine identities, and delegated workflows without creating separate control models for each one.

Technical breakdown

How governed deployment changes the identity boundary

A governed internal platform shifts identity control from each individual project to a shared deployment layer. Instead of every team wiring up DNS, authentication, infrastructure, and approvals separately, the platform becomes the place where those controls are applied consistently. That reduces the chance that an internal tool starts life in a personal account with no inventory, no clear owner, and no offboarding path. The architectural point is not just convenience. It is that deployment, identity, and governance become inseparable at creation time rather than being bolted on later.

Practical implication: treat the platform as the enforcement point for identity and ownership, not as a convenience layer after the fact.

Why RBAC matters for internal automations and agentic apps

Union Station explicitly places sensitive workflows such as employee offboarding behind RBAC. That matters because internal tools and AI-powered apps often touch privileged actions even when they look lightweight to the developer. RBAC limits who can trigger or modify those workflows, but it only works if the platform is the mandatory path for deployment and operation. In that model, access decisions are attached to the app and the workflow itself, not left to individual developers or their personal infrastructure choices.

Practical implication: bind sensitive internal workflows to RBAC at the platform layer so privileged actions cannot drift into unmanaged accounts.

How inventory and governance hooks reduce shadow app risk

The article stresses that bringing apps into the platform creates a full inventory and a place to add security scanning, vulnerability management, and governance hooks. That changes the control model from reactive discovery to managed registration. If a tool runs in a personal account, security teams usually see the impact before they see the asset. If it runs inside the platform, they can track what exists, who owns it, and what checks are attached. That is the difference between knowing about an internal app estate and merely suspecting one exists.

Practical implication: require registration inside the platform so inventory, scanning, and governance attach at deployment, not after discovery.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.

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

NHI Mgmt Group analysis

Governed app sprawl is an identity governance problem, not a developer convenience problem. The article shows that internal tools, Slack bots, and AI-powered apps become security assets the moment they touch authentication, ownership, or privileged workflow. When those assets are created outside a governed platform, identity teams lose visibility before they lose control. The practitioner lesson is that app sprawl and identity sprawl are now the same problem.

The sanctioned path becomes the control plane when it is easier than the workaround. C1.ai's central argument is that people will build and deploy anyway, so security has to make the governed route more usable than personal accounts or one-off cloud environments. That is a programme design issue, not a policy issue. The practical conclusion is that adoption follows friction, and governance fails where friction pushes builders away from the platform.

Platform-attached RBAC turns internal automations into governable identities. Sensitive actions such as offboarding are far easier to manage when the app, the workflow, and the permissions all inherit from one deployment surface. That does not eliminate risk, but it creates an auditable ownership chain that ad hoc scripts and shadow apps cannot provide. For IAM and IGA teams, the implication is to govern the platform, not chase each tool after it appears.

Union Station illustrates a named concept: governed app sprawl. This is the point at which the organisation stops treating internal apps as isolated experiments and starts treating them as inventory-bearing identity workloads. The security value comes from making the sanctioned path the default path, so ownership, authentication, and offboarding exist before the app spreads. Practitioners should use this model to align internal platform design with identity governance from day one.

Agentic enterprise adoption changes the scope of identity oversight. Once AI-powered apps, Slack bots, and internal automations become normal business tools, IAM teams have to govern their lifecycle the same way they govern other non-human access. That means deployment, approval, ownership, and revocation cannot be separate conversations. The implication is that identity governance must move upstream into the application platform itself.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

What this signals

Governed app sprawl becomes manageable when the platform owns the identity boundary. Internal apps do not need to be perfect to be governable, but they do need a single place where ownership, authentication, and offboarding are enforced before broad use. That is the difference between an estate you can manage and one you can only discover after the fact.

App sprawl and NHI sprawl now converge in the same programme discussion. Once internal tools, bots, and AI-powered utilities are treated as business assets, the governance question shifts from whether they exist to whether they inherit lifecycle controls from the platform. IAM teams should expect application platforms to become part of the identity control surface, not a separate engineering concern.

For practitioners

• Define a single sanctioned deployment path Make the internal platform the default place where teams create apps, bots, and automations, so authentication, ownership, and infrastructure are attached from day one.
• Require RBAC for sensitive workflows Place privileged internal operations such as offboarding, vendor reviews, and other business-critical automations behind role-based access control in the platform.
• Attach inventory to deployment Do not allow internal tools to exist without registration, owner assignment, and a visible deployment record that security can audit later.
• Add security hooks at creation time Build scanning, vulnerability management, and governance checks into the deployment flow so control starts before the app is widely used.
• Eliminate personal-account workarounds Remove incentives to build in isolated cloud accounts by making the governed route faster, clearer, and easier to use than the shadow path.

Key takeaways

• The article's core security lesson is that internal app sprawl becomes an identity problem as soon as tools, bots, and automations carry real business authority.
• A governed platform reduces shadow-account risk by making authentication, ownership, and offboarding part of the default deployment path.
• IAM and IGA teams should evaluate internal platforms as control points, because the most effective governance happens before the app escapes into personal infrastructure.

Key terms

• Governed App Sprawl: The growth of internal applications, bots, and automations under a single control model instead of scattered one-off deployments. It matters because the platform becomes the place where ownership, access, and lifecycle controls are attached, which is far easier to govern than chasing apps after they spread.
• Sanctioned Path: The approved route for building and running internal software so teams do not fall back to personal accounts or unmanaged cloud environments. In identity terms, it is the path where authentication, authorization, and offboarding are built in at creation time rather than added later.
• Platform-Attached RBAC: Role-based access control enforced by the deployment platform rather than by each individual app team. This is especially useful for internal workflows with sensitive actions, because the privilege model follows the platform’s ownership and lifecycle controls instead of drifting into ad hoc permissions.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

• How Union Station handles self-serve deployment for internal tools, AI-powered apps, and Slack bots
• The way shared authentication, infrastructure, and governance are wired into the platform
• Examples of the internal workflows already running on Union Station, including onboarding, offboarding, and vendor reviews
• How the team is thinking about request flows, managed runtimes, and MCP-driven app setup

👉 The full C1.ai blog covers the platform workflow, internal app examples, and the governance model behind Union Station.

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.