Anyone at your company can build software now. A sales lead asks an agent for a pipeline dashboard, has it working by lunch, and pushes it to a hosting service so the team can use it. A week later the link is in four Slack channels, the app holds an API key that can read the entire CRM, and IT has no idea it exists.
Nobody meant any harm. The tools made building easy and left every security decision to whoever clicked deploy. For Security & IT, these apps are the newest kind of shadow AI.
In short, an artifact is anything an agent makes (a report, a deck, a prototype), published at a link that never changes. An app is an artifact with a backend, so it can read live data from your business systems and save what people type into it. Both require company sign-in and stay private until you share them. Apps hold no API keys. They reach your systems through Runlayer's MCP connectors with each viewer's own permissions, and Runlayer logs every call.
What an artifact is
Ask a Runlayer agent for a weekly launch brief, a QBR deck, or a churn dashboard, and it publishes the result as an artifact. You get a link. When the numbers change, you ask for an update and the agent revises the same page and keeps every earlier version, so the link someone pinned in Slack last month still shows the current brief.
You share an artifact the way you share anything else in Runlayer, with people, groups, teams, or roles. Opening the link requires signing in to your organization.
What an app adds
Some tools have to save things or pull live data. An intake form needs somewhere to keep submissions, and a device dashboard has to read from your laptop management and endpoint security tools.
An app is an artifact that can do that. You describe the tool in plain language, and the agent builds the page plus a short list of named actions behind it, like "list my devices" or "log a competitor mention." Actions can write to the app's own database and call the business systems you've already connected to Runlayer. You don't set up a project or a deploy pipeline, and nobody pays a hosting bill per app.
Building one, start to finish
- Describe what you need in a sentence or two, for example "a page that lists my team's open renewals from Salesforce, with a box to log next steps." You don't choose a framework or a host.
- The agent writes the page, the actions behind it, and the tables the app needs, and it tries each action before handing anything back.
- The app's owner reviews every action in the Admin view, which shows the connectors it calls and whose access it uses. Nothing runs before that approval.
- You share the link with the people, groups, or roles who need it. They sign in with the company account they already have, and each of them sees their own data.
Changes work the same way. Ask the agent for a new column or a filter and it updates the app at the same link. A changed action goes back to the owner for approval, and the last approved version keeps serving until then, so nobody redeploys anything or sends around a new URL.
How it compares to the usual vibecoded app
Our internal app policy has a diagram of the two paths, redrawn below. The app in the middle can be identical on both. The differences are in sign-in, keys, permissions, releases, and logging.
A typical vibecoded app lives at a public URL, sometimes behind a shared password that keeps working after people leave the company. A Runlayer app requires company sign-in and starts out shared with nobody, and when someone is offboarded, their access goes with their account.
To read Salesforce or Snowflake, a vibecoded app keeps a master API key in its settings, and those keys rarely get rotated. A Runlayer app has no keys in it. Its actions call MCP connectors that Runlayer already manages, so the app has nothing to leak.
Anyone who gets past a shared password sees everything the master key can reach. On Runlayer, each action runs with the viewer's own access by default, so nobody gets more through an app than their admins already gave them.
A vibecoded app ships whatever was pushed last. On Runlayer, the owner approves each new version of an action before it runs.
Every call an app makes goes through your Runlayer policies and into the audit log, next to the rest of your agent and MCP activity. When Security asks what an app touched and for whom, they can look it up.
MCP is the backend
MCP connectors are already how Runlayer agents reach Salesforce, Linear, Okta, or a data warehouse, with identity, policy, and audit attached. Apps use the same connectors, so a new internal tool inherits the permissions your admins already set and doesn't open a new route to your data.
Credentials never live in the app either. The person building it never handles a key, so there's no key to paste into the wrong place.
What Security & IT gets
Most security teams find out about a vibecoded app after something goes wrong, like a key in a public repo or a link that turns up in search results. Artifacts and Apps leave nothing outside Runlayer to go find.
- One place to see every artifact and app, who owns it, who it's shared with, and its version history.
- The policies that already govern your agents and MCP servers, applied to every call an app makes.
- An audit entry for each call: which app, which action, which connector, and on whose behalf.
- Offboarding with no extra steps, since app access leaves with the person's account.
- No keys to rotate, because the apps never held any.
That's why a Runlayer-by-default policy can hold. A rule against hosting company data on public platforms only works if the approved route is at least as easy as the one it replaces, because people route around anything slower. For us, building on Runlayer is now the quicker route.
How we run it internally
Our policy fits on one page and has four rules: don't host company data on public platforms, use Runlayer by default, tell Security & IT when Runlayer can't support something, and move whatever is already live.
The page ends with one prompt. You paste it into your coding agent next to an existing app, it rebuilds the app on Runlayer, and then you delete the old project and rotate its keys.
One of the first apps built this way is our IT Command Center. It reads from laptop management, endpoint security, and Okta without a single API key in it. Everyone who opens it sees only their own devices, and an agent keeps it up to date.
Artifacts already carry a lot of our daily work. Engineers get a page every day listing each product change that shipped, with screenshots. Sales and marketing pass around primers and launch briefs as links instead of attachments that go stale. I run my own review queue from an app: it shows me one decision at a time, saves each answer to the app's database, and hands the follow-up work to an agent.
Questions we hear
Do I need to know how to code? No. You describe the tool and check what the agent built. Engineers who want to can read each action's code in the Admin view.
Which systems can an app reach? Any business system your admins have connected to Runlayer as an MCP connector, with only the access each viewer already has.
Can people outside the company open an app? Not by default. Every link asks for company sign-in, and your admins decide whether anything can be shared outside the organization.
What about apps we already host somewhere else? Move them with the prompt at the bottom of our policy, then delete the old project and rotate its keys.
Does this replace our engineering team's software? No. Apps are for internal tools such as dashboards, trackers, intake forms, and review queues. Customer-facing products still belong in your codebase and go through your release process.
Getting started
Your teams are going to keep building their own tools. Runlayer lets them do it on a golden path where the secure choice is also the quickest one, with AI enablement, security, and control in one platform. Builders go from a sentence to a working link in one conversation, and Security gets sign-in, scoped permissions, approvals, and an audit trail without anyone setting them up.
Artifacts are available in Runlayer today. Apps are in preview, so ask your Runlayer team about early access. AngelList, Gusto, and Lemonade are already using Runlayer. Book a demo to see Artifacts and Apps.
