Notifications
Clear all
Topic starter
06/06/2026 2:17 am
TL;DR: C1's internal platform, Union Station, centralises authentication, infrastructure, and governance for internal tools, AI-powered apps, Slack bots, and employee workflows, with shared deployment paths and full inventory visibility across the company. The deeper issue is not speed alone but whether identity teams can make the governed path the easiest path before shadow apps and unmanaged agentic workflows spread.
NHIMG editorial — based on content published by ConductorOne: Union Station: The Internal Platform Powering C1's Agentic Enterprise Transformation
Questions worth separating out
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.
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.
Q: What breaks when internal app platforms do not manage tool access centrally?
A: Tool sprawl becomes privilege sprawl.
Practitioner guidance
- Map every internal deployment path to an identity owner Inventory where internal tools, Slack bots, automations, and AI apps are currently deployed.
- Bake authentication and authorisation into the platform layer Make the platform handle login, access scope, and runtime policy for every app by default.
- 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.
What's in the full article
ConductorOne's full blog covers the implementation detail this post intentionally leaves for the source:
- How Union Station is structured as an internal self-serve platform for apps, automations, and AI-powered tools
- The deployment and governance patterns the vendor says it uses for onboarding, offboarding, and sensitive operations
- How the platform connects to shared authentication, DNS, managed runtimes, and internal service requests
- The vendor's specific view of how MCP selection will work inside the internal platform
👉 Read ConductorOne's blog on Union Station and agentic enterprise workflows →
Union Station and governed app sprawl: what IAM teams should notice?
Explore further
06/06/2026 3:52 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Union Station shows how governed app sprawl becomes an identity platform
