Union Station shows how governed app sprawl becomes an identity platform

At a glance

What this is: Union Station is C1's internal platform for deploying internal tools and AI-powered apps with shared auth and governance, and its key finding is that making the governed path easy reduces shadow app sprawl.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly have to govern the same platform where humans, service workflows, and AI-powered apps are built and deployed.

👉 Read ConductorOne's blog on Union Station and agentic enterprise workflows

Context

Union Station is an internal deployment platform for internal tools, AI-powered apps, and workflow automations. The identity problem it addresses is straightforward: if teams do not have a sanctioned place to build and ship, they will still build and ship, only outside governance.

The article frames a familiar IAM tension in a modern setting. Shared authentication, managed runtimes, and auditable deployment paths can reduce sprawl, but only if the platform is easy enough that employees choose it instead of personal accounts or unsanctioned infrastructure.

Key questions

Q: How should security teams govern internal app platforms that host both human and AI workflows?

A: Security teams should treat the platform as an identity control plane, not just a hosting layer. That means one deployment path, one inventory, one ownership model, and one policy baseline for human-built tools, service workflows, and AI-powered apps. If the platform is easier than shadow deployment, governance improves because adoption follows friction reduction, not enforcement theatre.

Q: Why do self-serve internal platforms change IAM and NHI governance so much?

A: They move identity decisions upstream into the place where apps are created, deployed, and connected to tools. Instead of reviewing isolated systems after the fact, IAM teams can enforce ownership, logging, and authorisation at the platform layer. That matters because self-service only reduces risk when the sanctioned path is also the simplest path.

Q: What breaks when internal app platforms do not manage tool access centrally?

A: Tool sprawl becomes privilege sprawl. Each app can accumulate its own data access, service connections, and automation paths, which makes inventory incomplete and reviews unreliable. Once the platform cannot tell you which app can reach which tool, governance loses the ability to explain, certify, or revoke access with confidence.

Q: What should organisations do when AI apps and automations are built inside the same platform?

A: They should separate app approval from tool privilege approval and review both together. The platform may make deployment easy, but the access granted to data stores, MCPs, and backend services still needs explicit control. That is especially important when the same workflow can be built by engineers, operators, or other business teams.

Technical breakdown

Shared authentication for internal app deployment

Union Station centralises authentication so internal apps do not each invent their own login and access model. That matters because every separate app path creates a new identity surface: separate credentials, separate authorisation logic, and separate audit evidence. A single platform can standardise how users, services, and automated workflows reach internal tools, while still allowing different permission levels for sensitive operations such as onboarding and offboarding. The technical point is not just convenience. It is control-plane consolidation, where identity, runtime, and deployment policy are linked instead of scattered across one-off builds.

Practical implication: define one deployment identity pattern and make every internal app inherit it.

Managed container runtimes and self-serve access

The platform's self-serve model removes tickets, manual DNS wiring, and ad hoc infrastructure setup from the deployment path. That lowers friction, but it also shifts governance from approval gates to platform rules: what can be requested, who can deploy, what data stores are allowed, and how logging and scanning are enforced. This is where internal platforms either become a governance layer or a convenience layer. If controls are baked into the platform, the team gets inventory, traceability, and repeatable guardrails. If not, self-service simply accelerates sprawl with better packaging.

Practical implication: move security checks into the platform workflow, not after deployment.

MCP selection inside an internal platform

The article's future-state workflow includes selecting which MCPs an app should use, with the platform connecting everything behind the scenes. That creates an identity and authorisation question around tool scope, data reach, and execution boundaries. For AI-powered apps, the platform must decide which tool connections are pre-authorised, which require higher privilege, and how those decisions are logged. In practice, this is where agentic behaviour becomes an access problem, not just an application problem, because tool choice and data access can change the blast radius of each app.

Practical implication: inventory each MCP connection as an access path and review it like a privileged integration.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Governed self-service becomes an identity control only when it is easier than shadow deployment. Union Station's real value is not that it centralises apps, but that it changes user behaviour. When employees can deploy without tickets, DNS work, or bespoke auth setup, the sanctioned path starts to compete with personal accounts and one-off infrastructure. That is the governance outcome IAM teams should care about. The practitioner lesson is that adoption follows friction, so policy only works when the platform absorbs the complexity.

Internal app platforms are now NHI control planes as much as developer tools. Once service workflows, cron jobs, Slack bots, and AI-powered apps live together, the platform is governing non-human identities at scale. Shared runtime, shared authentication, and shared inventory let teams treat these workloads as governed subjects rather than invisible code. That aligns with OWASP-NHI and Zero Trust thinking, where identity is the unit of control and every access path is observable. Practitioners should read this as a shift from app hosting to non-human identity governance.

Agentic enterprise programmes will fail if they separate app delivery from tool access governance. The article's MCP-oriented future shows why. If an internal platform can connect agents to tools behind the scenes, then the security model must follow the tool graph, not just the app catalog. That is where identity blast radius is created: one app may be harmless, but one app plus one privileged MCP connection becomes a governance event. The implication is that deployment policy and runtime authorisation are now one problem.

Standing governance assumptions break when app building becomes universal. Access review processes were designed for a smaller class of known, centralised systems with clearly owned entitlements. That assumption weakens when every team can create an app, an automation, or an AI workflow inside the same platform. The implication is not just more inventory. It is a different operational baseline for entitlement sprawl, ownership, and recertification across human, service, and agentic workloads.

Union Station illustrates the identity market's direction of travel: platform consolidation around governed execution. Security teams no longer just secure identities at login. They increasingly have to secure the place where identities are created, delegated, and used. That expands IAM's reach into internal developer platforms, NHI governance, and AI app delivery. Practitioners should expect more pressure to unify provisioning, policy, and runtime oversight in one control surface.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That visibility gap makes NHI Lifecycle Management Guide the right next resource for teams trying to tie platform inventories to offboarding and rotation.

What this signals

Platform consolidation is becoming an NHI governance strategy, not just a developer-experience choice. When internal tools, bots, and AI apps live behind one managed path, the organisation gains a chance to see what exists and who can reach it. That is the control point many identity teams have been missing, especially when service accounts and workflow identities otherwise disappear into fragmented delivery stacks.

The practical signal is that access reviews will increasingly start from platform inventory, not from cloud-by-cloud discovery. That matters because the gap is not only technical, it is operational: if the platform does not expose ownership, privilege, and tool reach, governance cannot keep pace with self-service delivery.

As self-serve internal platforms expand, identity teams should expect more pressure to connect deployment controls with lifecycle controls. Offboarding, rotation, and privilege cleanup have to follow the same system of record as app creation, or the organisation will keep approving speed while inheriting invisible access.

For practitioners

• Map every internal deployment path to an identity owner Inventory where internal tools, Slack bots, automations, and AI apps are currently deployed. Require a named business or technical owner for each path so shadow builds do not disappear into personal accounts or ad hoc cloud estates.
• Bake authentication and authorisation into the platform layer Make the platform handle login, access scope, and runtime policy for every app by default. The goal is to stop teams from rebuilding auth in each project and to ensure every deployment inherits the same control baseline.
• Treat MCP connections as privileged access paths Review which tools an internal app can reach, what data those tools expose, and whether the connection should be task-scoped or persistent. Each MCP link should be governed like an integration with explicit business justification.
• Move scanning and inventory before release Attach vulnerability scanning, logging, and deployment inventory to the self-serve workflow so controls happen at request time, not after something is already in production and being used by the business.
• Align recertification to the platform catalog Use the platform's inventory as the source of truth for access reviews, offboarding, and privilege cleanup across internal apps and automations. That prevents governance from lagging behind the pace of self-service deployment.

Key takeaways

• Union Station shows that governed self-service can reduce app sprawl only when the sanctioned path is easier than the shadow path.
• Once internal platforms host bots, automations, and AI apps, they become NHI control planes that must expose ownership, inventory, and access scope.
• Platform inventory should feed recertification and offboarding, otherwise internal app growth turns into unmanaged privilege growth.

Key terms

• Internal App Platform: An internal app platform is a shared environment where employees deploy tools, automations, and applications through a standard path. In identity terms, it becomes a control surface for ownership, authentication, logging, and access scope, rather than a simple hosting layer.
• Identity Control Plane: An identity control plane is the layer where access policy, ownership, and lifecycle decisions are applied consistently across systems. For internal platforms, it connects deployment, authorisation, and auditability so that new apps inherit governance instead of creating it from scratch.
• MCP Connection: An MCP connection is a tool path that lets an app or agent interact with external or internal services through a defined protocol. In governance terms, each connection is an access route that can widen blast radius if it is not scoped, owned, and reviewed.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause once it is granted access. The concept applies to humans, service accounts, and AI-powered workflows, but it becomes more dangerous when tool access and runtime execution are combined in one platform.

Deepen your knowledge

Internal app platforms, service identity governance, and AI workflow oversight are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to make self-service deployment compatible with identity control, it is worth exploring.

This post draws on content published by ConductorOne: Union Station: The Internal Platform Powering C1's Agentic Enterprise Transformation. Read the original.