Glossary
Glossary
Short definitions of the words on our pages, from shadow AI apps to SCIM, each with what it means on Forculus.
Updated
- Shadow AI apps
- Vibe coding
- Vibe-coded app security
- Internal tool
- App inventory
- AI agent identity
- MCP server authentication
- Deployment protection
- Identity token
- Single sign-on (SSO)
- SCIM
- Outbound proxy
Shadow AI apps
Apps that staff build with AI tools and put online without IT knowing they exist. They can live under one person's account, hold company keys in their code, and open to anyone with the link.
On Forculus. Every app deployed to a workspace is on one list for its owners and admins, with who made it, who can open it and who opened it last. See For IT.
Vibe coding
Building software by describing what you want to an AI model and letting it write the code, often without reading every line. It lets people outside engineering make their own tools.
On Forculus. Say "ship it" in Claude Code, Codex or Cursor and what the agent built goes live behind your sign-in. See Claude Code.
Vibe-coded app security
Keeping an app written mostly by AI from leaking what it touches. The usual problems are an app open to anyone with its address, an API key pasted into the code, and packages with known vulnerabilities.
On Forculus. Apps start private, keys stay out of the code, and every deploy is scanned for leaked keys and vulnerable packages. See For security teams.
Internal tool
Software a few people inside one company use to do their work: a dashboard, a form, a tracker or an admin page. It isn't sold or shown to customers.
On Forculus. Forculus is built for these. Start one with forculus init internal-tool. See Start from a template.
App inventory
A list of the apps a company runs, with who owns each one and who can use it. It is hard to keep when people build apps outside IT.
On Forculus. The apps list in the dashboard, which downloads as CSV on any plan. See See every app.
AI agent identity
Giving an AI agent or other software a name and credentials of its own, separate from any person, so what it does can be allowed, logged and stopped. Also called non-human or machine identity.
On Forculus. An agent of the workspace has its own name, reaches only the apps you grant it, and is logged under that name. See Agents.
MCP server authentication
How an MCP server knows who is calling it. The MCP specification defines an authorization flow for servers over HTTP, based on OAuth 2.1, in which the client gets an access token for one server on behalf of a person.
On Forculus. Deploy the server here and we handle sign-in and approval, so it gets a signed token naming the person on every request. See MCP servers.
Deployment protection
A setting on a hosting platform that asks visitors to sign in or enter a password before they reach a deployment. What it covers by default, and what it costs, differs between hosts.
On Forculus. Nothing to turn on: every app is private from its first deploy, on every plan. See Vercel Deployment Protection and Forculus.
Identity token
A short-lived, signed statement of who made a request, which an app can check without trusting a header the client could have set. It is usually a JWT, checked against a published key set.
On Forculus. Every request reaches your app with one, valid for 60 seconds and made out to that app. Our SDKs check it in one call. See SDKs.
Single sign-on (SSO)
Signing in to many apps through one identity provider, such as Okta, Microsoft Entra ID or Google Workspace, usually over SAML or OpenID Connect.
On Forculus. An Enterprise feature, included on Business for early customers for a limited time. Every plan can sign in with Google or Microsoft. See Single sign-on and SCIM.
SCIM
The System for Cross-domain Identity Management: a standard HTTP protocol an identity provider uses to add, change and remove people in other systems, so a leaver is removed everywhere at once.
On Forculus. SCIM adds and removes members when your identity provider does, alongside single sign-on.
Outbound proxy
A service that an app's outgoing requests pass through. It can add credentials to a request so the app never holds them, and refuse requests to hosts the app has no reason to reach.
On Forculus. Ours adds the keys you store to each request on the way out, and holds each app to its list of hosts. See Sending requests out.
Sources
- Authorization, Model Context Protocol specification, version 2026-07-28. Checked 22 October 2026.
- RFC 7644: System for Cross-domain Identity Management: Protocol, IETF, September 2015. Checked 22 October 2026.