Skip to content

Guardrails for AI app deployment

Guardrails for AI app deployment are controls that a system enforces automatically, so a builder can't skip them. Put each control where a system enforces it, not in a policy document. The controls are company sign-in with multi-factor authentication, default-private sharing, secret scanning and storage, a dependency allow-list, code scanning, data rules, environment separation, spend caps and logging. The enforcement matrix below shows which layer enforces each one: the builder platform, identity, network, pipeline or runtime. If your builder platform can't enforce a control, use a compensating control and write down the gap, as of October 2026.

Who this is for

Platform and security engineers, and IT managers who own the approved builder platforms. You get the enforcement matrix, a no-pipeline version of it, what the exposure scan must check, and what to do when a platform can't enforce something. For the whole platform, see the paved road. Reading time: about 12 minutes.

Where should each control be enforced?

A control that lives only in a policy document is a documented failure pattern: people can't be relied on to remember it, and nothing stops a mistake. Microsoft's guidance for locked-down default environments puts the rule in the platform instead: sharing with everyone is blocked, new connectors are off until reviewed, and an exception contact is shown in the error message. Its sharing limits need the premium managed-environment tier, so check your licence before you plan on them.1 Singapore's government agent rollout pairs a registry of agents with runtime rules such as no file deletion and no external email (reported by news outlets in June 2026; we couldn't open the primary text).2

Fast-moving

As of October 2026. Which layer can enforce a control depends on the platform and on the licence you buy. Recheck each approved tool's admin console when you approve it and at each review date.

The enforcement matrix

"Enforces" means the layer is where the control is switched on and can't be bypassed by a builder. "Backs up" means it adds a second check. A dash means the layer doesn't apply. The pipeline column applies only if you already run pipelines (see C6).

Control Builder platform Identity provider Network Pipeline Runtime Minimum Grows into
Company sign-in and multi-factor Backs up (SSO setting) Enforces Backs up (sign-in proxy) - - SSO and multi-factor on every approved tool Conditional access by device and risk
Default-private sharing Enforces (org sharing limits) Backs up (group-only access) - - - "Anyone with the link" and public publishing turned off Reviewed public-facing pattern, by exception
Secret storage Backs up (platform secrets) - - - Enforces (secrets injected at run time) A secrets manager, or the platform secret store (server-side only) Short-lived credentials, rotation
Secret scanning Backs up (if offered) - - Enforces - Scheduled scan of exported app code and prompts Scan on every change
Dependency control Enforces (platform's package controls) - Backs up (registry proxy) Enforces (lockfile, allow-list) - Use the platform's own packages; review new ones Registry proxy, provenance checks
Code scanning Backs up (built-in checks) - - Enforces - Platform checks plus the technical reviewer's checklist Static analysis on every change
Data rules (deny by default) Enforces (row-level security, table permissions) - - Backs up (tests) - Deny-by-default rules and a negative access test Rules as code, tested on every change
Data-loss rules Enforces (connector policy) - Backs up (DLP proxy) - - Approved connector allow-list, new ones off Per-data-class policies
Environment separation Enforces (separate workspaces) Backs up (separate roles) - Enforces (promotion) - Test and production copies with different access Automated promotion
Spend caps Enforces (budget limits) - - - Backs up (provider limits) A hard cap per tool or key, with alerts Cost by app, model routing
Logging Enforces (audit log on) Backs up (sign-in log) Backs up (access log) - Enforces (app and agent actions) Audit log retained and exportable Central logs, alerts
Agent action limits Backs up Backs up (scoped identity) - - Enforces Scoped credentials; no external email or deletion by default Per-action approvals

Every control needs a named person who configures it and reviews it when a tool changes. A control with no named owner is a control on paper. If the same control sits in a different layer on two tools, record that in a short per-tool sheet so a gap is visible. When you add a tool, extend each control to it before it reaches approval; the usual failure is a new tool that passed review while nobody extended the spend cap or sharing limits to it.

What each risk tier must have at deploy is in the deploy gates. This page covers how to enforce those gates, not which tier needs which.

Runtime guardrails for agents and automations

Some controls can only work while the app runs. For agents and automations (an app that runs on a schedule or chains tool calls), set the limits where the platform can enforce them:

  • no external email or messages unless the app is approved to send them;
  • no deletion, and a cap on how many records a run can change;
  • a cap on the number of recipients per run;
  • scoped credentials, read-only unless the app must write;
  • a spend cap and a stop switch the app owner can use.

These follow the pattern in the Singapore rollout above and in Microsoft's default-environment guidance, where restricted email and connector blocking are platform settings rather than requests to builders.12 The agent-specific controls are on coding agents, and the cost side is on AI spend.

Don't: rely on policy alone

A control that says "builders must not send external email" and has no platform setting behind it fails the first time someone is in a hurry.1

Don't: permit permission-bypass modes by default

Auto-approve and "skip permissions" modes in coding agents remove the check that stops destructive actions (AP8). Turn them off in managed settings where the tool allows it, and see coding agents. Failure patterns lists the incidents.

Supply-chain controls for the default

In the default path you don't run a package proxy, so use what the platform and the reviewers can do:

  • Lockfiles where the platform exposes them: pin dependencies so a rebuild doesn't pull something new.
  • The platform's own package controls, such as an allow-list of libraries, if the builder offers one.
  • A check for invented packages. AI models suggest package names that don't exist, and attackers register them ("slopsquatting"; the figures and the AP9 warning are on dependencies). At Team, the builder checks that each new package exists, has a real project page and history, and is on the platform's list if it has one (dependencies). From Important, the technical reviewer confirms it during the technical check, because Team apps have no technical reviewer.
  • Pinned versions of extensions and MCP servers from a short approved list (AP7). See MCP and agents.

The OpenSSF guide on instructions for AI coding assistants covers the same ground for developers: put security requirements in the assistant's standing instructions, vet libraries, pin versions and run scanners.3

Which controls apply without a platform team?

This is the default path: a bought builder platform, your identity provider and a scheduled exposure scan, with no pipelines.

Guardrail What enforces it, with no pipeline Who checks it
Sign-in Identity provider: SSO and multi-factor required on the builder tenant IT, at approval and at each review
Private by default Builder admin settings: public publishing and link sharing off, apps visible to groups only IT; the scheduled exposure scan confirms (Important and above, and Team apps where IT includes them)
Data rules Row-level security or table permissions in the managed backend, plus a negative test Builder at Team; technical reviewer from Important, using the security checklist
Secrets A secrets manager, or the builder platform's secret store (server-side only) Builder at Team; technical reviewer from Important; the scan searches shipped front-end code
Connectors Builder admin policy: allow-list, new connectors off IT, on request
Environments Separate test and production workspaces with different access (Important and above; Team: changes are tried away from live data) App owner; see go-live checklist
Spend Hard cap in the tool's billing console, alerts to the owner IT, monthly
Exposure External scan of the URL and data endpoints of every app at Important and above, monthly by default, with the active checks below. It's part of the technical check from Important (gate matrix); including Team apps is good practice, because it's the only check that catches a Team app's Floor 2 breach after launch IT (or the technical reviewer it delegates to), recording last_exposure_scan_on and its result in the registry

What the exposure scan must check

The scan finds what the settings missed. It only does that if it asks the backend for data, not just the pages.

What a passive scan can and can't find. A passive or baseline scan, such as OWASP ZAP's baseline mode, crawls the site for about a minute and reads the responses; it "doesn't perform any actual attacks".5 It finds missing security headers, insecure cookies, and pages its crawler can reach without sign-in. It can't find data endpoints the crawler never sees (the backend API the front end calls from its code), tables readable with the public key because the data rules are missing, or one user's records readable by another signed-in user. Escape's 2025 research found the builder exposures the other way: it pulled anonymous keys out of the front-end bundles and queried the backend APIs with them.7

The active checks. Run them only against apps you own, with written approval: read-only requests against production; anything that writes, only against a test copy you're authorized to test.

  1. Secrets in client code. Download the app's front-end bundles and run a secret scanner over them, or search them for key patterns.
  2. Public data endpoints. Query every data endpoint and storage bucket signed out and with only the public key. Any rows returned is a finding.
  3. Missing row-level authorization. Sign in as a lowest-role test account and request another user's record by its ID. Anything returned is a finding.

These are the same tests a builder runs by hand in how to test your app, steps 1, 2, 4 and 5. For the monthly run, use either of two kinds of tool: a commercial external scanner that tests backend APIs and not just pages, or an open-source scanner run in an active mode with the app's API definition (for example ZAP's API scan, which takes OpenAPI, GraphQL or SOAP definitions, or Nuclei with templates for your backend), plus a secret scanner on the bundles.6 The negative access test stays the primary control; the scan is the backstop.

Hypothesis to test

We expect IT can run these checks monthly for every app at Important and above without a platform team, once they're scripted per backend type, and that adding Team apps roughly doubles the effort (Team apps are expected to outnumber the rest). Test it by recording the time each monthly run takes in the first three months, with and without Team apps.

What if your builder platform can't enforce a control?

Check this when you approve a platform. A builder tool that can't keep an app private isn't approved even for Sandbox use (the second of the two floors). For other missing controls, work down this list:

  1. Move the control to another layer. Missing sharing limits can sometimes be handled by identity (group-only access), and missing spend caps by the model provider's budget limits.
  2. Add a compensating control. For example, a weekly scheduled check of the platform's sharing report, with a named person who reads it.
  3. Limit what the platform may hold. Approve it only for data classes where the gap doesn't matter (see approve tools).
  4. Accept the gap in writing. Record it as a decision, with an owner and a review date, using the decision record template. Don't leave a blank.

Some gaps can't be covered by another layer. A hard spend cap needs the tool's own billing control, a "no training on our data" term needs a contract (see approve tools), and an agent's sandbox needs isolation on the machine where it runs.

Hypothesis to test

We expect the approved builder platform to enforce sign-in, private-by-default and deny-by-default data rules at the licence you buy, or compensating controls to suffice (A-038). Test it by checking each of those settings in the admin console before approval, and by seeing what the monthly exposure scan finds in the first three months.

How should exceptions work?

An exception path that takes weeks sends builders to unmanaged tools. Give it one owner, one mailbox or form, a target answer in days, and a recorded reason. There are two kinds of request, and they mustn't blur:

  • A connector or tool request (for example, one extra connector for one app) is a request to change what's approved, not an exception. It's handled under approve tools, and once approved it's on the list for that data class.
  • A gate exception changes when or how a gate is met. It's a bounded exception: the approver named in the RACI, a written reason, an expiry of 90 days or less, and an entry in the app registry. It never applies to the floors or the legal triggers.

Review open exceptions at the quarterly platform review and close the ones nobody needs.

Don't: let exceptions take weeks

We expect a slow exception path to push builders to unmanaged tools and personal accounts (A-002, a hypothesis). Measure the median days to answer and publish it, so a slowdown is visible.

Depends on your circumstances (C6)

Depends on your circumstances (C6)

If you already run a platform team or build pipelines, add these. They aren't the default because most readers can't maintain them.

  • Pipeline checks on every change: secret scanning, static analysis, dependency scanning, and tests that include the negative access test.
  • A registry proxy that only serves approved packages, with provenance checks.
  • Supply-chain levels. SLSA v1.2 (approved; as of October 2026) adds a Source track, with levels up to enforced two-party review, alongside the Build track.4 Aim first for Build level 2 (a hosted build with signed provenance) and Source level 2 (retained history and source provenance); higher levels need controls most worker-built apps can't support.
  • An AI model gateway that holds provider keys, applies spend caps and logs usage across apps. See hosting for when the gateway decision matters.
  • Rules as code for data rules, tested in the pipeline.

Assumptions and evidence

  • A-038 (Low): we expect the builder platform to enforce sign-in, private-by-default and deny-by-default data rules, or compensating controls to suffice; test this by checking admin settings at approval and reading the first quarter of exposure-scan results.
  • Evidence: platform vendor guidance, a news report, a peer-reviewed study of invented packages, vendor research and a standards body. Nothing here is a controlled study of guardrails on worker-built apps. Facts on this page are as of October 2026.

  1. Microsoft Learn, "Secure the default environment" (Power Platform adoption guidance, updated 26 Aug 2026). https://learn.microsoft.com/en-us/power-platform/guidance/adoption/secure-default-environment [vendor], accessed 2026-10-21. ↩↩↩

  2. Malay Mail, "Singapore rolls out AI agent registry as govt expands use of artificial intelligence in public service", 2 Jun 2026 (the page refused our fetch, so this rests on the search summary; the underlying Singapore framework text is unverified). https://www.malaymail.com/amp/news/singapore/2026/06/02/singapore-rolls-out-ai-agent-registry-as-govt-expands-use-of-artificial-intelligence-in-public-service/222229 [news], accessed 2026-10-21. ↩↩

  3. OpenSSF, "Security-Focused Guide for AI Code Assistant Instructions", 1 Aug 2025. https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions [primary], accessed 2026-10-21. ↩

  4. SLSA, "What's new in SLSA v1.2" (the page shows the version as approved but gives no date). https://slsa.dev/spec/v1.2/whats-new [primary], accessed 2026-10-21. ↩

  5. OWASP ZAP, "ZAP - Baseline Scan" (one-minute spider by default, then passive scanning only). https://www.zaproxy.org/docs/docker/baseline-scan/ [primary], accessed 2026-10-21. ↩

  6. OWASP ZAP, "ZAP - API Scan" (imports OpenAPI, SOAP or GraphQL definitions and runs an active scan). https://www.zaproxy.org/docs/docker/api-scan/ [primary], accessed 2026-10-21. ↩

  7. Escape.tech, methodology post on how it found vulnerabilities in apps built with vibe-coding platforms, 29 Oct 2025 (anonymous keys found in front-end bundles, then the backend APIs queried; vendor research). https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/ [vendor], accessed 2026-10-21. ↩