A new ‘must-have’ layer in your stack
Employees are building apps with AI. Who actually owns them?
Non-technical people, the finance folks, the ops person, whoever runs your new employee onboarding, are building software right now that IT has never seen, doesn’t control, and the company doesn’t actually own.
Claude Code, Cursor, Codex, and a dozen other coding agents took custom software from “hire an engineer” down to “describe what you need.” The tools are already sitting on your employees’ laptops. A few are free. A few cost twenty bucks a month. None of them asked IT for permission to install.
People want to file this under shadow IT, and I get why, but it’s a different animal and the old fixes don’t touch it. When someone signs up for Notion behind your back, you’ve got options. Your SSO provider sees it. You can shadow the account, migrate the data, kill the domain. When someone builds a custom inventory tracker over a weekend, none of that exists. The code lives somewhere. Their laptop, maybe. A personal Vercel account. Some vendor you’ve never heard of. Nothing to call, nothing to audit, nothing to revoke.
And the stuff they’re building is good. Genuinely useful, and the company already leans on it. So what do you do with that?
Why it’s working
The people who know what needs to be built are finally the ones building it.
For thirty years, custom software ran through a chain of translation. The person with the problem described it to a project manager, who wrote requirements, who handed them to a developer who’d never once sat at the desk the tool was for. Months later something shipped, and usually it was wrong in the way that’s hardest to fix. It hit every stated requirement and missed the actual need. Half of what IT built never got used, because by the time it shipped the person who asked had moved on, or the process had changed.
The coding agents broke that chain. Take a finance manager who’s run the same manual reconciliation for five years. She can build the tool she’s always wanted in a weekend. She knows every edge case, she knows which columns matter and which are noise, she knows why the whole thing blows up on the last day of the month. An outside engineer would need weeks of interviews just to get close. She already has all of it in her head, and now she can act on it directly.
And it isn’t only her. Sales ops can wire a CRM export to a filter to a Slack alert without waiting on sprint capacity. An HR team can build onboarding that matches how they actually run the process, not how some packaged product assumed they would. Nobody’s implementing a $50,000-a-year platform to get a lightweight tracker that talks to the three systems their team already uses.
The productivity signal is real. It’s anecdotal at the individual level, sure, but I see it consistently enough across companies that I don’t think it’s noise. These tools are bespoke in a way packaged software never manages, because the person who built it is the person using it. No features to navigate around, no eighteen-month rollout before you can rename a field.
The velocity is the other half of it. When the process changes next quarter, the person who built the tool just changes the tool. That used to be a ticket, a sprint, a workaround. Now it’s an afternoon.
If you try to shut this down, you’ll lose. The tools are cheap and everywhere, and they’re most compelling to exactly the employees you least want to lose, the ones who see a problem and go fix it. Ban them and you get resentment plus the same behavior, now hidden. Trying to prevent it is the wrong goal. The right one is making sure whatever they build lands somewhere you can see and own it.
What IT isn’t seeing
None of these apps get a security review. None have a data policy. And once the person who built one walks out the door, none of them have an owner.
Start with data. Coding agents are built to be helpful, which is exactly the problem. Give one database credentials and it connects. Ask it for an endpoint and it’ll happily accept user input without ever wondering whether that input should be validated. It’ll pull in a third-party service because the service is useful and its job is to make things work, not to audit the data flow. None of this is malicious. All of it is a surface.
Employees don’t think of themselves as developers, so they don’t think about data the way developers eventually, painfully, learn to. They point an app at the production customer database because that’s where the data is and standing up a read replica is annoying. They run a customer record through some enrichment API because the agent suggested it and it saved three hours. They drop a file upload in a public S3 bucket because that’s the pattern the agent generated and nobody told it not to. PII ends up in places nobody meant it to go, through services nobody reviewed, with no trail to follow after the fact.
This isn’t theoretical. The regulations don’t care that it was an accident. GDPR, CCPA, HIPAA all have rules about where personal data can live and who’s allowed to touch it, and an employee-built app that quietly routes customer emails through an unreviewed API is a breach-notification event waiting to happen. The company owns that liability whether the employee meant it or not.
Then there’s orphaning. The app works. People depend on it. The person who built it leaves. Nobody else knows how it works, where it lives, what it’s wired to, or what credentials it’s using. Two months later it breaks. Ops calls IT. IT can’t find the codebase. Maybe it’s on a personal GitHub. Maybe the database password is hard-coded in an env file on a server nobody knew existed. Maybe the hosting was on a personal Vercel account that quietly lapsed when the employee’s credit card stopped getting charged. I’m not describing a worst case here. This is just the normal life cycle of an app that wasn’t built on shared infrastructure.
Cost is its own thing. AI apps call models on every interaction. A few hundred calls per user per day, across a forty-person department, turns into thousands of dollars a month, billed to a personal card or buried in an expense report, invisible until someone submits it or the card maxes out. No central visibility means no way to forecast, budget, or govern AI spend at all.
And every one of these apps is an island. Its own login, usually a hand-rolled form with no MFA. Its own data model, its own vendor accounts, its own API keys stored wherever the agent felt like storing them. You can’t inventory them, can’t consolidate them. The sprawl that took years to build up with SaaS takes weeks with AI-built apps, and unlike SaaS there’s no vendor catalog to check, no SSO to query, nothing to detect in a browser. They’re invisible until one of them breaks.
Underneath all of it is ownership. When people build on their own infrastructure, their accounts, their credentials, their hosting, you have no legal or technical claim on any of it. The app belongs to the person, not the company. The data pipelines it spun up belong to whoever’s account the credentials sit in. You can’t fix that with a memo. It’s structural, so the only fixes are structural too.
What governance actually requires here
The SaaS playbook is useless here. Every move in the standard shadow-IT kit assumes there’s a vendor on the other end to negotiate with. You block the domain, revoke the license, migrate the data, sign an enterprise agreement. None of that applies when the “product” is code someone wrote over a weekend. No domain, no license, nobody to call.
The review-everything approach doesn’t scale either. You can tell people to submit every app for IT review before it ships. In practice you get one of two outcomes. Either a bottleneck that kills the productivity you were trying to protect, or a policy people nod along to while they keep deploying on the side. Governance that runs on voluntary compliance isn’t governance. It’s hope.
What actually works is owning the infrastructure before the app gets built.
If every employee-built app runs on infrastructure the company manages, a shared database pool, identity through your IDP, hosting IT controls, then governance is built into the structure instead of bolted on afterward as procedure. The app is on your stack from the first line of code. You’re not hunting it down later or migrating it or asking nicely, because it was never anywhere else.
Employees get a platform to build on. Database connections come from provisioned credentials instead of personal accounts. Authentication runs through your identity provider, so every user has MFA, every session is logged, and every access event ties back to a real person in your directory. Hosting sits on infrastructure IT controls. When you set someone up on the platform, you decide up front which data sources their apps can reach, which models they can call, and what they can spend in a month. Those parameters get enforced by the infrastructure, not by a policy document.
And it puts zero friction on the coding agent itself, which to me is the whole point. If someone likes Claude Code, they keep using Claude Code. Cursor, same. The only thing that changes is that the app lands on the company’s infrastructure when it’s done, under the company’s access controls, visible to IT from day one. The agent has no idea. The employee barely notices. IT finally gets the visibility it never had.
You don’t get that from an auditing tool or a SaaS-discovery platform, and you definitely don’t get it from policy. You get it by making the governed path the easy path. Once company-managed infrastructure is the default target for every agent in the building, governance stops being a control you enforce and starts being something you just get.
The risks that don’t go away on their own
The number of employee-built apps in your environment is going to grow no matter what you do. The tools keep getting better and faster and cheaper, and the people using them keep getting more capable. Someone who couldn’t ship anything six months ago is shipping things people rely on today. That pace is accelerating, and honestly, I didn’t predict it would move this fast.
Every month you go without a governed layer is another month of apps piling up on personal accounts. The catalog grows. The dependencies get deeper. People start leaning on tools IT doesn’t know exist, running on credentials that belong to someone who might give notice next week. Wait long enough and the migration problem gets huge. Act now and you’ve got a manageable inventory to bring onto real infrastructure. Wait two years and you’ve got a genuinely hard problem, maybe with a compliance audit or a data breach in front of it.
The organizations handling this well aren’t the ones who found clever ways to lock AI tools down. They’re the ones who looked at the productivity gain, decided it was real and worth keeping, and built the layer that lets them keep it without giving up control.
So the question isn’t whether your people are building software with AI agents. They are. It’s whether that software ends up belonging to them or to you.
How Remy works
This is the model Remy implements. It gives any coding agent a shared foundation to build on, everything from the database and authentication to SSO, hosting, CDN, and custom domains. Employees keep whatever agent they already like. The agent’s output just lands on Remy instead of on someone’s laptop.
The infrastructure goes deeper than the basics. File storage is isolated, so user uploads stay off the app’s main domain and can’t turn into a same-origin security problem. Images resize on demand across devices without a separate service. Video gets transcoded with poster frames and captions on every upload. Transactional email ships with the domain authentication records already configured, including the sender reputation that decides whether your notifications hit the inbox or the spam folder. Analytics, frontend error reporting, and performance monitoring are built in, so when someone reports a page that froze on their exact device in their exact session, there’s a stack trace and a timing breakdown sitting there waiting for you. Rate limiting and abuse protection run at the infrastructure layer, so nobody can weaponize an app to drain your inference budget or flood some external service. Custom domains and SSL are included. There are over a thousand pre-authenticated integrations, covering CRMs, Slack, accounting systems, data warehouses, and HR platforms, that any app can reach without the employee setting up a separate account. Access to 200+ AI model providers is built in, billed at provider rates and routed through the platform so IT sees every call, every model, and every dollar. The whole thing is SOC 2 Type 1 and Type 2 certified and GDPR-compliant. None of it needs a separate vendor contract. It’s just there, part of what every app compiles against.
Governance in practice
When IT provisions someone on Remy, they decide which data sources that person’s apps can connect to, which AI models they can call, and what they can spend in a month. A finance analyst building a reporting tool can get the finance warehouse but not the HR system. A contractor can be capped to public data only. An engineering team can have wider model access than, say, marketing.
These aren’t honor-system settings. They’re enforced at the infrastructure level. An app can’t reach a data source that wasn’t approved for that user, and it can’t call a model outside the allowed set. When spend gets near the ceiling, the platform flags it before it turns into a surprise. The app can try whatever it wants; the infrastructure decides what actually happens.
Everything gets logged. Who built which app, what data it touched, which models it called, when, and at what cost, from the day the app was created. Compliance can pull the full data-access history for any app in the environment. Security can see every external API call any app has ever made. If something goes wrong, there’s a complete record of what touched what.
A PII detector runs on every app and flags sensitive data heading somewhere it shouldn’t before it becomes a compliance event, not after the breach notification goes out. You get the warning with enough time to actually do something about it.
There’s also a live dashboard showing IT every app on the platform, who owns it, what it’s connected to, what it’s costing, and whether anything looks off. A SaaS catalog tool can’t show you that, because it can only see what employees bought. Remy can show you because the infrastructure is managed.
Offboarding and continuity
When someone leaves, their apps stay put. The code is on managed infrastructure. The spec is there. The data connections are there. The access controls are there. Nobody’s chasing down credentials or a personal GitHub account, and nobody’s reverse-engineering what an app does from a codebase no one else has ever opened.
Whoever picks it up next inherits a running, documented system with a plain-English description of what it does and why. They don’t have to guess. They read the spec, see the design decisions, and keep going from a known state.
Every app on the platform stays auditable and under IT’s control for its whole life, not just while it’s active. The ones you have today are still auditable five years from now, and it doesn’t matter at all who originally built them.
That’s what ownership looks like when it’s structural instead of procedural. Procedural ownership needs people to follow the right steps. Structural ownership means you get the outcome regardless of what any one person does.
ols are already sitting on your employees’ laptops. A few are free. A few cost twenty bucks a month. None of them asked IT for permission to install.
People want to file this under shadow IT, and I get why, but it’s a different animal and the old fixes don’t touch it. When someone signs up for Notion behind your back, you’ve got options. Your SSO provider sees it. You can shadow the account, migrate the data, kill the domain. When someone builds a custom inventory tracker over a weekend, none of that exists. The code lives somewhere. Their laptop, maybe. A personal Vercel account. Some vendor you’ve never heard of. Nothing to call, nothing to audit, nothing to revoke.
And the stuff they’re building is good. Genuinely useful, and the company already leans on it. So what do you do with that?
Why it’s working
The people who know what needs to be built are finally the ones building it.
For thirty years, custom software ran through a chain of translation. The person with the problem described it to a project manager, who wrote requirements, who handed them to a developer who’d never once sat at the desk the tool was for. Months later something shipped, and usually it was wrong in the way that’s hardest to fix. It hit every stated requirement and missed the actual need. Half of what IT built never got used, because by the time it shipped the person who asked had moved on, or the process had changed.
The coding agents broke that chain. Take a finance manager who’s run the same manual reconciliation for five years. She can build the tool she’s always wanted in a weekend. She knows every edge case, she knows which columns matter and which are noise, she knows why the whole thing blows up on the last day of the month. An outside engineer would need weeks of interviews just to get close. She already has all of it in her head, and now she can act on it directly.
And it isn’t only her. Sales ops can wire a CRM export to a filter to a Slack alert without waiting on sprint capacity. An HR team can build onboarding that matches how they actually run the process, not how some packaged product assumed they would. Nobody’s implementing a $50,000-a-year platform to get a lightweight tracker that talks to the three systems their team already uses.
The productivity signal is real. It’s anecdotal at the individual level, sure, but I see it consistently enough across companies that I don’t think it’s noise. These tools are bespoke in a way packaged software never manages, because the person who built it is the person using it. No features to navigate around, no eighteen-month rollout before you can rename a field.
The velocity is the other half of it. When the process changes next quarter, the person who built the tool just changes the tool. That used to be a ticket, a sprint, a workaround. Now it’s an afternoon.
If you try to shut this down, you’ll lose. The tools are cheap and everywhere, and they’re most compelling to exactly the employees you least want to lose, the ones who see a problem and go fix it. Ban them and you get resentment plus the same behavior, now hidden. Trying to prevent it is the wrong goal. The right one is making sure whatever they build lands somewhere you can see and own it.
What IT isn’t seeing
None of these apps get a security review. None have a data policy. And once the person who built one walks out the door, none of them have an owner.
Start with data. Coding agents are built to be helpful, which is exactly the problem. Give one database credentials and it connects. Ask it for an endpoint and it’ll happily accept user input without ever wondering whether that input should be validated. It’ll pull in a third-party service because the service is useful and its job is to make things work, not to audit the data flow. None of this is malicious. All of it is a surface.
Employees don’t think of themselves as developers, so they don’t think about data the way developers eventually, painfully, learn to. They point an app at the production customer database because that’s where the data is and standing up a read replica is annoying. They run a customer record through some enrichment API because the agent suggested it and it saved three hours. They drop a file upload in a public S3 bucket because that’s the pattern the agent generated and nobody told it not to. PII ends up in places nobody meant it to go, through services nobody reviewed, with no trail to follow after the fact.
This isn’t theoretical. The regulations don’t care that it was an accident. GDPR, CCPA, HIPAA all have rules about where personal data can live and who’s allowed to touch it, and an employee-built app that quietly routes customer emails through an unreviewed API is a breach-notification event waiting to happen. The company owns that liability whether the employee meant it or not.
Then there’s orphaning. The app works. People depend on it. The person who built it leaves. Nobody else knows how it works, where it lives, what it’s wired to, or what credentials it’s using. Two months later it breaks. Ops calls IT. IT can’t find the codebase. Maybe it’s on a personal GitHub. Maybe the database password is hard-coded in an env file on a server nobody knew existed. Maybe the hosting was on a personal Vercel account that quietly lapsed when the employee’s credit card stopped getting charged. I’m not describing a worst case here. This is just the normal life cycle of an app that wasn’t built on shared infrastructure.
Cost is its own thing. AI apps call models on every interaction. A few hundred calls per user per day, across a forty-person department, turns into thousands of dollars a month, billed to a personal card or buried in an expense report, invisible until someone submits it or the card maxes out. No central visibility means no way to forecast, budget, or govern AI spend at all.
And every one of these apps is an island. Its own login, usually a hand-rolled form with no MFA. Its own data model, its own vendor accounts, its own API keys stored wherever the agent felt like storing them. You can’t inventory them, can’t consolidate them. The sprawl that took years to build up with SaaS takes weeks with AI-built apps, and unlike SaaS there’s no vendor catalog to check, no SSO to query, nothing to detect in a browser. They’re invisible until one of them breaks.
Underneath all of it is ownership. When people build on their own infrastructure, their accounts, their credentials, their hosting, you have no legal or technical claim on any of it. The app belongs to the person, not the company. The data pipelines it spun up belong to whoever’s account the credentials sit in. You can’t fix that with a memo. It’s structural, so the only fixes are structural too.
What governance actually requires here
The SaaS playbook is useless here. Every move in the standard shadow-IT kit assumes there’s a vendor on the other end to negotiate with. You block the domain, revoke the license, migrate the data, sign an enterprise agreement. None of that applies when the “product” is code someone wrote over a weekend. No domain, no license, nobody to call.
The review-everything approach doesn’t scale either. You can tell people to submit every app for IT review before it ships. In practice you get one of two outcomes. Either a bottleneck that kills the productivity you were trying to protect, or a policy people nod along to while they keep deploying on the side. Governance that runs on voluntary compliance isn’t governance. It’s hope.
What actually works is owning the infrastructure before the app gets built.
If every employee-built app runs on infrastructure the company manages, a shared database pool, identity through your IDP, hosting IT controls, then governance is built into the structure instead of bolted on afterward as procedure. The app is on your stack from the first line of code. You’re not hunting it down later or migrating it or asking nicely, because it was never anywhere else.
Employees get a platform to build on. Database connections come from provisioned credentials instead of personal accounts. Authentication runs through your identity provider, so every user has MFA, every session is logged, and every access event ties back to a real person in your directory. Hosting sits on infrastructure IT controls. When you set someone up on the platform, you decide up front which data sources their apps can reach, which models they can call, and what they can spend in a month. Those parameters get enforced by the infrastructure, not by a policy document.
And it puts zero friction on the coding agent itself, which to me is the whole point. If someone likes Claude Code, they keep using Claude Code. Cursor, same. The only thing that changes is that the app lands on the company’s infrastructure when it’s done, under the company’s access controls, visible to IT from day one. The agent has no idea. The employee barely notices. IT finally gets the visibility it never had.
You don’t get that from an auditing tool or a SaaS-discovery platform, and you definitely don’t get it from policy. You get it by making the governed path the easy path. Once company-managed infrastructure is the default target for every agent in the building, governance stops being a control you enforce and starts being something you just get.
The risks that don’t go away on their own
The number of employee-built apps in your environment is going to grow no matter what you do. The tools keep getting better and faster and cheaper, and the people using them keep getting more capable. Someone who couldn’t ship anything six months ago is shipping things people rely on today. That pace is accelerating, and honestly, I didn’t predict it would move this fast.
Every month you go without a governed layer is another month of apps piling up on personal accounts. The catalog grows. The dependencies get deeper. People start leaning on tools IT doesn’t know exist, running on credentials that belong to someone who might give notice next week. Wait long enough and the migration problem gets huge. Act now and you’ve got a manageable inventory to bring onto real infrastructure. Wait two years and you’ve got a genuinely hard problem, maybe with a compliance audit or a data breach in front of it.
The organizations handling this well aren’t the ones who found clever ways to lock AI tools down. They’re the ones who looked at the productivity gain, decided it was real and worth keeping, and built the layer that lets them keep it without giving up control.
So the question isn’t whether your people are building software with AI agents. They are. It’s whether that software ends up belonging to them or to you.
How Remy works
This is the model Remy implements. It gives any coding agent a shared foundation to build on, everything from the database and authentication to SSO, hosting, CDN, and custom domains. Employees keep whatever agent they already like. The agent’s output just lands on Remy instead of on someone’s laptop.
The infrastructure goes deeper than the basics. File storage is isolated, so user uploads stay off the app’s main domain and can’t turn into a same-origin security problem. Images resize on demand across devices without a separate service. Video gets transcoded with poster frames and captions on every upload. Transactional email ships with the domain authentication records already configured, including the sender reputation that decides whether your notifications hit the inbox or the spam folder. Analytics, frontend error reporting, and performance monitoring are built in, so when someone reports a page that froze on their exact device in their exact session, there’s a stack trace and a timing breakdown sitting there waiting for you. Rate limiting and abuse protection run at the infrastructure layer, so nobody can weaponize an app to drain your inference budget or flood some external service. Custom domains and SSL are included. There are over a thousand pre-authenticated integrations, covering CRMs, Slack, accounting systems, data warehouses, and HR platforms, that any app can reach without the employee setting up a separate account. Access to 200+ AI model providers is built in, billed at provider rates and routed through the platform so IT sees every call, every model, and every dollar. The whole thing is SOC 2 Type 1 and Type 2 certified and GDPR-compliant. None of it needs a separate vendor contract. It’s just there, part of what every app compiles against.
Governance in practice
When IT provisions someone on Remy, they decide which data sources that person’s apps can connect to, which AI models they can call, and what they can spend in a month. A finance analyst building a reporting tool can get the finance warehouse but not the HR system. A contractor can be capped to public data only. An engineering team can have wider model access than, say, marketing.
These aren’t honor-system settings. They’re enforced at the infrastructure level. An app can’t reach a data source that wasn’t approved for that user, and it can’t call a model outside the allowed set. When spend gets near the ceiling, the platform flags it before it turns into a surprise. The app can try whatever it wants; the infrastructure decides what actually happens.
Everything gets logged. Who built which app, what data it touched, which models it called, when, and at what cost, from the day the app was created. Compliance can pull the full data-access history for any app in the environment. Security can see every external API call any app has ever made. If something goes wrong, there’s a complete record of what touched what.
A PII detector runs on every app and flags sensitive data heading somewhere it shouldn’t before it becomes a compliance event, not after the breach notification goes out. You get the warning with enough time to actually do something about it.
There’s also a live dashboard showing IT every app on the platform, who owns it, what it’s connected to, what it’s costing, and whether anything looks off. A SaaS catalog tool can’t show you that, because it can only see what employees bought. Remy can show you because the infrastructure is managed.
Offboarding and continuity
When someone leaves, their apps stay put. The code is on managed infrastructure. The spec is there. The data connections are there. The access controls are there. Nobody’s chasing down credentials or a personal GitHub account, and nobody’s reverse-engineering what an app does from a codebase no one else has ever opened.
Whoever picks it up next inherits a running, documented system with a plain-English description of what it does and why. They don’t have to guess. They read the spec, see the design decisions, and keep going from a known state.
Every app on the platform stays auditable and under IT’s control for its whole life, not just while it’s active. The ones you have today are still auditable five years from now, and it doesn’t matter at all who originally built them.
That’s what ownership looks like when it’s structural instead of procedural. Procedural ownership needs people to follow the right steps. Structural ownership means you get the outcome regardless of what any one person does.
Well written and timely, Dmitry! Thank you.