Security is a discipline built on fundamentals that do not change. Discover what you have. Review what you find. Monitor what you deploy. Prove that your controls are working. These four principles have governed every mature security program for the last two decades, and they will govern the next two.
What is changing, faster than most security teams have registered, is the surface those fundamentals have to cover.
Every week, across every organization that uses AI-assisted development tools, a new population of functional, production-connected applications is being created by people who have never thought about a threat model. These are not rogue actors but your operations manager, your finance analyst, your sales team lead. They opened Lovable or Replit or Windsurf, described a problem, and deployed a solution. The application has a URL, it connects to your data, and it exists entirely outside the scope of every security program you have built. But only kind of.. Lovable was approved? But maybe just not to replace salesforce?
This is 2nd party risk (think of it like mini vendors): the gap between the two categories your security program was designed to handle, and it is growing faster than most organizations have recognized.
The ground is shifting
The traditional model is clean and has served the industry well. First-party risk covers software your engineers build and ship through a governed development lifecycle. Third-party risk covers software that vendors build and you subscribe to, managed through contracts, questionnaires, and audit reports. (dont get me started I know that questionnaires does not equal security but bear with me on this one) The entire architecture of modern security sits on top of this distinction, and for a long time it held, because the ability to build and deploy software was a specialist skill. Non-engineers could adopt SaaS tools in shadow IT fashion, but they could not create net-new applications connected to production infrastructure. Building software required engineering, and engineering operated inside a governance boundary.
That assumption is no longer valid.
The AI-assisted development category has collapsed the barrier between “person who can describe a problem” and “person who can deploy a solution.” Tools like Lovable, Replit, and Windsurf have turned natural language into deployed applications, and the governance boundary that once kept non-engineers on the SaaS subscription side of the line has effectively dissolved. Every employee is now a potential application developer, and most of them have no idea what that means from a security perspective. And it also means that your security team has a whole lot more on its plate to manage when Carl from accounting has become inspired to build his own rillet and recently youtubed his way on how to connect all of his apps to his new rillet via MCP, skills and agents.
Not shadow IT. Not internal tooling. Something new.
The instinct when encountering 2nd party risk is to reach for an existing frame, and shadow IT is the closest analogy. But it does not fit. Shadow IT historically meant an employee using an unsanctioned SaaS tool, a personal Dropbox or a consumer app holding corporate data, where the risk was data leaving your environment through an unreviewed external service. The response was to find it, block it or sanction it, and move on.
Second party assets are not shadow SaaS. They are shadow products, and the distinction matters enormously. The employee did not subscribe to something external. They built something that now lives in your environment, connected to your data, operating under your regulatory obligations, with no vendor to audit and no off-boarding motion to execute against. The thing they created is an asset, and the only path to managing it is to treat it as one.
Internal tooling is also the wrong frame, and understanding why clarifies what makes this category genuinely different. Internal tooling is built by software engineers inside a governed process, one that includes tickets, sprints, code reviews, security reviews, and deployment pipelines with gates. Someone owns it, someone is accountable for it, and the security program has a surface to attach to. Second party applications skip the entire chain. The builder is a business user with domain expertise armed with security training they did a year ago and there is no repository to scan and no pipeline to gate, and there is no owner recorded in any system your security team can query. The risk profile is not internal tooling of lower quality. It is a structurally different class of asset with a structurally different governance gap.
The real problem: minions without masters
Here is the mechanism that makes this a category-level concern rather than a collection of individual risks.
AI-assisted development tools are designed for rapid iteration, designed to lower friction, designed so that one person can spin up a working application in an afternoon and update it the next morning. This is genuinely useful, and it is also a proliferation engine. Every quarter, the number of these applications in your environment grows, not linearly but faster, because each tool that proves useful gets shared, duplicated, and extended. Your organization does not have one AI-generated application connected to production data. It has dozens, and it will have hundreds.
Each one was created by a specific person for a specific purpose, connected to specific credentials, accessing specific data. And then that person leaves, or moves to a different team, or simply forgets the application exists. The application does not leave with them. The credentials do not expire. The database connection stays open and the URL stays live, with no offboarding checklist to capture it because it was never in any system, and no access review to surface it because there is no asset record. It simply continues to exist, connected and unmonitored, owned by no one, until something goes wrong.
Multiply this dynamic across the pace of creation and the normal rate of employee turnover, and what you have is not a shadow IT problem. It is an ecosystem of orphaned agents, each one a live connection to production data, each one outside the reach of any security control you have. The surface is not stable. It is growing, and most of what is growing is invisible to the people responsible for securing it.
Why the structural risks compound
The vulnerability classes in these applications are not the standard list with more instances. The risk profile is different because the person who built the application made no conscious security decisions at any point in the process, and the default choices that AI development tools make are optimized for speed rather than security posture.
Credentials are hardcoded because there is no secrets management integration in a typical Lovable or Replit project (although by the time this is written I am sure that will not be the case!). The path of least resistance is to paste the database connection string directly into the application, often using admin credentials because those are the ones the employee had available, and that string will still be in the codebase after the employee leaves, potentially committed to a version-controlled repository on a platform your security team has never reviewed.
Access is overprivileged because least privilege is not an instinct that comes naturally to non-engineers. The reporting dashboard built to pull monthly summaries ends up with write access to the entire customer table because nobody thought to scope the credentials differently. Authentication is absent because tools built outside engineering governance are routinely deployed with no login requirement, on the assumption that only the team would ever find a particular URL, an assumption that fails in predictable and well-documented ways.
The AI platform itself introduces a third-party dimension that your TPVM program needs to cover, but covering it only gets you partway there. Reviewing a vendor’s SOC 2 tells you something meaningful about the platform. It tells you nothing about what your analyst described when she built the expense reconciliation tool, what data was processed during testing, or what credentials ended up in the generated code. The vendor review is necessary and not sufficient.
The fundamentals still work. Apply them.
The answer is not to prohibit AI-assisted development. The productivity gains are real, the business will adopt these tools regardless of what security says, and trying to prevent employees from building things is a constraint that will be routed around. The answer is to apply the fundamentals your program already knows to a new class of asset, consistently and at scale.
Discover. You cannot govern what you cannot see, and the discovery motion for 2nd party assets looks different from traditional asset discovery. It means monitoring for new subdomains associated with AI development platforms, new OAuth application registrations against corporate identity providers, new database service accounts provisioned outside the standard request process, and new API keys with naming patterns consistent with automated generation. The principle is identical to every other discovery effort. The signals are new, but if you are still using a spreadsheet to list out your inventory (yes confluence is a spreadsheet and so is notion tables)
Review. Every application connected to production data needs a minimum security review covering authentication, credential storage, data access scoping, and logging. This does not require recreating the full SDLC. It requires a lightweight checkpoint (or, dare I say it AI automation that does this against the risk tolerance to provide an overview - come with the axes security folks, I am waiting) that creates an asset record and confirms that basic hygiene decisions were made consciously rather than not at all. The goal is not to slow down the people building these tools but to ensure that the security program has a surface to attach to when something needs attention.
Monitor. An application with a URL and a database connection belongs in your asset inventory, your vulnerability management cycle, and your access review program. It should generate logs and those logs should go somewhere with eyes on them. There is nothing exotic about the monitoring.
Prove. You must be able to prove accountability and oversight when a customer or regulator, or who knows
The surface keeps moving
The AI-assisted development category is not a trend that will stabilize at some manageable level. Every improvement in these tools expands the population of people who can deploy production-connected applications, and the pace of that expansion is accelerating. The rate of application creation will increase, and the rate of orphaned, unmonitored assets will increase with it unless security programs extend their scope to match.
Organizations that adapt their existing fundamentals to cover this asset class now will be significantly better positioned than those waiting for an incident to make the argument for them. The fundamentals are sound. The programs that succeed will be the ones that recognize the ground has shifted and adjust their coverage accordingly, bringing the same discipline to 2nd party assets that they already apply to everything else.
Discover. Review. Monitor. Prove.
The surface is new. The work is not. Get yourself some better automation and purpose build AI monitoring and go to town.