zuplo 6.73.19 → 6.73.20

package/docs/articles/local-development-troubleshooting.mdx

@@ -45,6 +45,16 @@ certificates, you can add the following script:
 }
 ```
 
+## mTLS client certificates don't load
+
+On `managed-dedicated` and `self-hosted` projects, `zuplo dev` loads client
+certificates from `.zuplo-local/mtls/<cert-name>/tls.crt` and `tls.key`, or from
+the directory passed to `--mtls-certs`. If the startup output reports no loaded
+certificates, check the warnings listed in
+[Local certificates fail to load](./securing-backend-mtls.mdx#local-certificates-fail-to-load).
+
+Local mTLS isn't available on `managed-edge` projects.
+
 ## "unknown format ... ignored" warnings
 
 When the development server prints warnings like

package/docs/articles/securing-backend-mtls.mdx

@@ -71,7 +71,7 @@ project. You can upload multiple certificates, each with a unique name.
 zuplo mtls-certificate create \
   --cert cert.pem \
   --key key.pem \
-  --name my-backend-cert \
+  --name my_backend_cert \
   --account your-account \
   --project your-project \
   --environment-type development \
@@ -113,7 +113,7 @@ import { ZuploContext, ZuploRequest } from "@zuplo/runtime";
 export default async function (request: ZuploRequest, context: ZuploContext) {
   const response = await fetch("https://secure-backend.example.com/api", {
     zuplo: {
-      mtlsCertificate: "my-backend-cert",
+      mtlsCertificate: "my_backend_cert",
     },
   });
 
@@ -132,7 +132,7 @@ that make outbound requests:
   "module": "$import(@zuplo/runtime)",
   "options": {
     "baseUrl": "https://secure-backend.example.com",
-    "mtlsCertificate": "my-backend-cert"
+    "mtlsCertificate": "my_backend_cert"
   }
 }
 ```
@@ -145,13 +145,13 @@ For better flexibility across environments, store the certificate name as an
 **Production environment:**
 
 ```text
-BACKEND_MTLS_CERT=my-backend-prod-cert
+BACKEND_MTLS_CERT=my_backend_prod_cert
 ```
 
 **Staging environment:**
 
 ```text
-BACKEND_MTLS_CERT=my-backend-staging-cert
+BACKEND_MTLS_CERT=my_backend_staging_cert
 ```
 
 Then reference it in your code:
@@ -195,13 +195,43 @@ zuplo mtls-certificate list \
   --project your-project
 ```
 
+Each entry includes the certificate ID, which the other commands take as
+`--cert-id`.
+
+### Inspecting a Certificate
+
+To see the subject, issuer, validity dates, and enabled environment types for
+one certificate:
+
+```bash
+zuplo mtls-certificate describe \
+  --cert-id cert_abc123 \
+  --account your-account \
+  --project your-project
+```
+
+### Changing Environment Types
+
+To change which environment types can use a certificate, pass the complete set
+of environment types you want enabled — the command replaces the existing set
+rather than adding to it:
+
+```bash
+zuplo mtls-certificate update \
+  --cert-id cert_abc123 \
+  --environment-type preview \
+  --environment-type production \
+  --account your-account \
+  --project your-project
+```
+
 ### Deleting Certificates
 
 To remove a certificate:
 
 ```bash
 zuplo mtls-certificate delete \
-  --cert-id my-cert-id \
+  --cert-id cert_abc123 \
   --account your-account \
   --project your-project
 ```
@@ -238,19 +268,112 @@ you rotate the certificate.
 
 ## Local Development
 
-:::warning
+`zuplo dev` can present client certificates to your backend, so the same
+`mtlsCertificate` code path you deploy also works on your machine. Support
+depends on your project type, set by
+[`projectType`](../programmable-api/zuplo-json.mdx#projecttype) in
+`zuplo.jsonc`:
+
+| `projectType`                      | Local mTLS support                                       |
+| ---------------------------------- | -------------------------------------------------------- |
+| `managed-dedicated`, `self-hosted` | Supported — certificates load from your local filesystem |
+| `managed-edge`                     | Not supported                                            |
+
+If `zuplo.jsonc` has no `projectType` field, run [`zuplo link`](../cli/link.mdx)
+— it looks up the linked project and writes the matching type into the file.
+Without that field, local development falls back to `managed-edge` and skips
+mTLS, even when the project deploys to a dedicated environment.
+
+On `managed-edge` projects, mTLS only works in deployed environments. Test mTLS
+routes in a preview environment, point local runs at a backend endpoint that
+doesn't require client certificates, or branch on
+[`environment`](./environment-variables.mdx) to skip mTLS locally.
+
+Certificates never leave your machine — the CLI reads them from disk and passes
+them to the local runtime. It doesn't upload them to Zuplo or read the
+certificates you uploaded with `zuplo mtls-certificate create`.
+
+### Add certificates to your project
+
+Place each certificate in its own subdirectory of `.zuplo-local/mtls`, named
+after the certificate. The layout matches the one used for deployments:
+
+```text
+my-project/
+├── .zuplo-local/
+│   └── mtls/
+│       └── my_backend_cert/
+│           ├── tls.crt
+│           └── tls.key
+├── config/
+├── modules/
+└── zuplo.jsonc
+```
+
+The subdirectory name is the name your code references, so use the same name as
+the certificate you uploaded to Zuplo. Then
+`fetch(url, { zuplo: { mtlsCertificate: "my_backend_cert" } })` resolves locally
+and in deployed environments without a code change.
+
+Both files must be PEM-encoded, and `tls.key` must be unencrypted — the same
+requirements as an uploaded certificate.
 
-mTLS bindings aren't currently available in local development environments. Your
-code using mTLS will only work when deployed to Zuplo's edge infrastructure.
+:::caution{title="Keep private keys out of Git"}
+
+`.zuplo-local/` holds unencrypted private keys. Projects created with
+`create-zuplo-api` gitignore it already. For older projects, add `.zuplo-local/`
+to your `.gitignore` — `zuplo dev` prints a warning at startup when it isn't
+covered.
 
 :::
 
-For local development, consider:
+Start the server as usual:
 
-- Using conditional logic to bypass mTLS when running locally
-- Setting up a separate backend endpoint that doesn't require mTLS for
-  development
-- Testing mTLS functionality in a preview environment
+```bash
+npx zuplo dev
+```
+
+At startup the CLI reports what it loaded:
+
+```text
+Loaded 1 local mTLS client certificate(s) from /path/to/my-project/.zuplo-local/mtls: my_backend_cert. Reference by name via the mtlsCertificate option.
+```
+
+### Load certificates from another directory
+
+To keep certificates outside the project — a shared team directory, or a path
+your secret manager writes to — pass `--mtls-certs`:
+
+```bash
+npx zuplo dev --mtls-certs ~/certs/zuplo-uat
+```
+
+The flag expects the same `<dir>/<cert-name>/tls.crt` layout and wins over
+`.zuplo-local/mtls`. Unlike auto-detection, it fails fast: if the directory
+doesn't exist or holds no valid certificate, the server doesn't start.
+`--mtls-certificates-dir` is an alias for the same flag.
+
+The CLI only looks in these two places, in order:
+
+1. The directory passed to `--mtls-certs`
+2. `<project>/.zuplo-local/mtls`
+
+There is no fallback to a directory in your home folder, because client
+certificates are scoped to a specific gateway.
+
+### Choose the right certificate for local runs
+
+The certificate you load locally is presented to whatever backend your route
+calls. Use a certificate issued for a development or staging backend, and keep
+production certificates off developer machines.
+
+:::danger
+
+Loading a production client certificate locally lets any code on your machine
+authenticate to your production backend as the gateway. Treat these files like
+any other production credential.
+
+:::
 
 ## Troubleshooting
 
@@ -333,6 +456,31 @@ If requests fail to connect:
   preview, production)
 - Check that your backend's CA certificate is properly configured
 
+### Local Certificates Fail to Load
+
+If `zuplo dev` starts without reporting a loaded certificate, check the startup
+output for one of these warnings:
+
+- **"Local mTLS client certificates are only supported for managed-dedicated
+  projects"** — the project resolves to `managed-edge`. If `zuplo.jsonc` has no
+  `projectType` field, run [`zuplo link`](../cli/link.mdx) to add it and start
+  the server again. If the field says `managed-edge`, local mTLS isn't
+  available; see [Local Development](#local-development).
+- **"Ignoring mTLS certificate directory … because it is missing `tls.key`"** —
+  a subdirectory has only one of the two files. Add the missing file — each
+  certificate directory needs both `tls.crt` and `tls.key`.
+- **"Ignoring `--mtls-certs`: … are set in `.env` or `.env.zuplo`"** — a
+  previous manual setup left `__ZUPLO_MTLS_CLIENT_CERT_NAMES` or
+  `__ZUPLO_MTLS_CLIENT_CERT_BASE_DIR` in an env file. Those values take
+  precedence in the local runtime. Remove them from `.env` and `.env.zuplo` to
+  use `--mtls-certs` or `.zuplo-local/mtls`.
+- **"Found local mTLS certificates directory … but it does not contain any valid
+  certificate entries"** — the certificates are loose files rather than in a
+  `<cert-name>/` subdirectory.
+
+If no warning appears at all, confirm the directory is `.zuplo-local/mtls` (not
+`.zuplo/mtls`) at the project root, next to `zuplo.jsonc`.
+
 ### Runtime Errors
 
 If you see errors about missing certificates:

package/docs/cli/dev.mdx

@@ -116,6 +116,44 @@ sidebar_label: dev
   usage="$0 dev [options]"
 >
 
+## Local mTLS client certificates
+
+On `managed-dedicated` and `self-hosted` projects, `zuplo dev` presents client
+certificates to your backend, so routes that set `mtlsCertificate` work locally
+without a code change.
+
+Put each certificate in its own subdirectory of `.zuplo-local/mtls`, named after
+the certificate:
+
+```text
+.zuplo-local/mtls/my_backend_cert/tls.crt
+.zuplo-local/mtls/my_backend_cert/tls.key
+```
+
+`zuplo dev` finds that directory automatically and logs the certificates it
+loaded. To read certificates from somewhere else, pass `--mtls-certs`:
+
+```bash
+npx zuplo dev --mtls-certs ~/certs/zuplo-uat
+```
+
+The flag takes precedence over `.zuplo-local/mtls` and fails fast when the
+directory is missing or holds no valid certificate.
+
+`.zuplo-local/` contains unencrypted private keys. Projects created with
+`create-zuplo-api` gitignore it already; for older projects, add
+`.zuplo-local/` to your `.gitignore`. `zuplo dev` warns at startup when it
+isn't covered.
+
+The project type comes from `projectType` in `zuplo.jsonc`. If that field is
+missing, run [`zuplo link`](./link.mdx) to have the CLI detect and write it —
+otherwise local development falls back to `managed-edge` and skips mTLS.
+
+On `managed-edge` projects, local mTLS isn't available and `--mtls-certs` is
+ignored with a warning. For the full workflow, including certificate
+requirements and troubleshooting, see
+[Gateway to Origin mTLS Authentication](../articles/securing-backend-mtls.mdx#local-development).
+
 </CliCommand>
 
 ## Global options
@@ -124,3 +162,9 @@ The following global options are available for all commands:
 
 - [`--help`](./global-options.mdx#help)
 - [`--api-key`](./global-options.mdx#api-key)
+
+## Additional resources
+
+- [Local Development Troubleshooting](../articles/local-development-troubleshooting.mdx)
+- [Testing your API](../articles/testing.mdx)
+- [Gateway to Origin mTLS Authentication](../articles/securing-backend-mtls.mdx)

package/docs/cli/dev.partial.mdx

@@ -0,0 +1,47 @@
+---
+additional-resources:
+  - name: Local Development Troubleshooting
+    href: ../articles/local-development-troubleshooting.mdx
+  - name: Testing your API
+    href: ../articles/testing.mdx
+  - name: Gateway to Origin mTLS Authentication
+    href: ../articles/securing-backend-mtls.mdx
+---
+
+## Local mTLS client certificates
+
+On `managed-dedicated` and `self-hosted` projects, `zuplo dev` presents client
+certificates to your backend, so routes that set `mtlsCertificate` work locally
+without a code change.
+
+Put each certificate in its own subdirectory of `.zuplo-local/mtls`, named after
+the certificate:
+
+```text
+.zuplo-local/mtls/my_backend_cert/tls.crt
+.zuplo-local/mtls/my_backend_cert/tls.key
+```
+
+`zuplo dev` finds that directory automatically and logs the certificates it
+loaded. To read certificates from somewhere else, pass `--mtls-certs`:
+
+```bash
+npx zuplo dev --mtls-certs ~/certs/zuplo-uat
+```
+
+The flag takes precedence over `.zuplo-local/mtls` and fails fast when the
+directory is missing or holds no valid certificate.
+
+`.zuplo-local/` contains unencrypted private keys. Projects created with
+`create-zuplo-api` gitignore it already; for older projects, add
+`.zuplo-local/` to your `.gitignore`. `zuplo dev` warns at startup when it
+isn't covered.
+
+The project type comes from `projectType` in `zuplo.jsonc`. If that field is
+missing, run [`zuplo link`](./link.mdx) to have the CLI detect and write it —
+otherwise local development falls back to `managed-edge` and skips mTLS.
+
+On `managed-edge` projects, local mTLS isn't available and `--mtls-certs` is
+ignored with a warning. For the full workflow, including certificate
+requirements and troubleshooting, see
+[Gateway to Origin mTLS Authentication](../articles/securing-backend-mtls.mdx#local-development).

package/docs/dev-portal/zudoku/configuration/authentication-azure-ad.md

@@ -72,9 +72,9 @@ to integrate Azure AD with your Dev Portal documentation site.
    export default {
      // ... other configuration
      authentication: {
-       type: "openid",
+       type: "entra",
        clientId: "<your-application-client-id>",
-       issuer: "https://login.microsoftonline.com/<your-tenant-id>/v2.0",
+       tenantId: "<your-tenant-id>",
        scopes: ["openid", "profile", "email"], // Optional: customize scopes
      },
      // ... other configuration
@@ -91,20 +91,21 @@ For single tenant (organization-only access):
 
 ```typescript
 authentication: {
-  type: "openid",
+  type: "entra",
   clientId: "<your-application-client-id>",
-  issuer: "https://login.microsoftonline.com/<your-tenant-id>/v2.0",
+  tenantId: "<your-tenant-id>",
   scopes: ["openid", "profile", "email"],
 }
 ```
 
-For multitenant (any Azure AD organization):
+For multitenant (any Azure AD organization), use `tenantId: "common"` or `"organizations"` — this is
+also the default if `tenantId` is omitted:
 
 ```typescript
 authentication: {
-  type: "openid",
+  type: "entra",
   clientId: "<your-application-client-id>",
-  issuer: "https://login.microsoftonline.com/common/v2.0",
+  tenantId: "common",
   scopes: ["openid", "profile", "email"],
 }
 ```
@@ -115,9 +116,9 @@ Request additional Microsoft Graph API scopes:
 
 ```typescript
 authentication: {
-  type: "openid",
+  type: "entra",
   clientId: "<your-application-client-id>",
-  issuer: "https://login.microsoftonline.com/<your-tenant-id>/v2.0",
+  tenantId: "<your-tenant-id>",
   scopes: [
     "openid",
     "profile",
@@ -136,7 +137,7 @@ Protect specific documentation routes using the `protectedRoutes` configuration:
 {
   // ... other configuration
   authentication: {
-    type: "openid",
+    type: "entra",
     // ... Azure AD config
   },
   protectedRoutes: [
@@ -217,16 +218,17 @@ Azure AD provides rich user profile data through OpenID Connect:
 2. **Redirect URI Mismatch**: The redirect URI must exactly match one configured in Azure AD,
    including protocol and path.
 
-3. **Tenant Access Issues**: For single-tenant apps, ensure users are from the correct tenant. For
-   multi-tenant, verify the issuer URL uses "common" or "organizations".
+3. **Tenant Access Issues**: For single-tenant apps, ensure users are from the correct tenant and
+   `tenantId` is set to that tenant's GUID. For multi-tenant, use `tenantId: "common"` or
+   `"organizations"`.
 
 4. **Missing User Information**: Check that required API permissions are granted and admin consent
    is provided if needed.
 
-5. **Token Validation Errors**: Ensure your issuer URL is correct and includes the `/v2.0` endpoint
-   for the Microsoft identity platform.
+5. **Token Validation Errors**: Ensure your `tenantId` is correct. If you use a CIAM tenant
+   (`*.ciamlogin.com`), set the `issuer` option to override the default issuer instead.
 
-6. **Authentication Not Working**: Verify your issuer URL and client ID are correct, and that your
+6. **Authentication Not Working**: Verify your `tenantId` and client ID are correct, and that your
    app registration is configured as a Single-page application (SPA) with the correct redirect URIs.
 
 ## Security Best Practices

package/docs/dev-portal/zudoku/configuration/authentication.md

@@ -15,8 +15,8 @@ authentication provider you use.
 
 ## Authentication Providers
 
-Dev Portal supports Clerk, Auth0, Supabase, Firebase, Azure B2C, and any OpenID Connect provider
-(including Okta, Keycloak, Authentik, and PingFederate).
+Dev Portal supports Clerk, Auth0, Supabase, Firebase, Microsoft Entra ID, Azure B2C, and any OpenID
+Connect provider (including Okta, Keycloak, Authentik, and PingFederate).
 
 Not seeing your authentication provider? [Let us know](https://github.com/zuplo/zudoku/issues)
 
@@ -99,6 +99,26 @@ providing your own array of scopes.
 For provider-specific guides (Okta, Keycloak, etc.), see the
 [OpenID Connect setup page](./authentication-openid.md).
 
+### Microsoft Entra ID
+
+For Microsoft Entra ID (formerly Azure AD), you will need the `clientId` from your app registration
+and your `tenantId`.
+
+```typescript
+{
+  // ...
+  authentication: {
+    type: "entra",
+    clientId: "<your-application-client-id>",
+    tenantId: "<your-tenant-id>", // Or "common" for multitenant. Defaults to "common".
+  },
+  // ...
+}
+```
+
+For full setup instructions, see the
+[Azure AD / Entra ID setup guide](./authentication-azure-ad.md).
+
 ### Firebase
 
 For Firebase authentication, you will need your Firebase project configuration. You can find this in

package/docs/policies/_index.md

@@ -83,7 +83,7 @@
 | request-validation-inbound | Request Validation | Validates incoming requests against your OpenAPI specification. Checks query parameters, path parameters, headers, and request body to ensure they match the defined schema before processing. | api-gateway |
 | require-origin-inbound | Require Origin | Sets an allow-list for an origin header | api-gateway |
 | require-user-claims-inbound | Require User Claims | Authorizes requests by validating claims on the authenticated user (`request.user`) against a configurable rule of `and`/`or` combinators and per-claim `eq`, `in`, and `startsWith` checks. Run it after any authentication policy that populates `request.user` — a JWT auth policy, API key auth, mTLS, and so on — to allow only specific callers (service accounts, OAuth clients, tenants, groups) without writing custom code.  Every check fails closed: a missing or non-primitive claim never matches, comparisons are strict and type-sensitive, and requests without an authenticated user receive a 401 response. Denied requests receive a 403 response that does not echo claim values or expected values; the failing checks are written to the request log instead.  Validation of the options runs lazily inside the policy constructor, which the runtime caches per policy name. Misconfigured options therefore fail on first use with a customer-facing `ConfigurationError` instead of failing at module load. | api-gateway |
-| secret-masking-outbound | Secret Masking | Masks common secrets like Zuplo API keys, GitHub tokens, or SSH private key in the response body. | api-gateway |
+| secret-masking-outbound | Secret Masking (deprecated) | Masks common secrets like Zuplo API keys, GitHub tokens, or SSH private key in the response body. | api-gateway |
 | semantic-cache-inbound | Semantic Cache | Respond to matched incoming requests with semantically cached content  The Semantic Cache Inbound policy caches responses based on semantic similarity of cache keys rather than exact matches. This allows for more flexible caching where similar requests can return cached responses even if the cache key is not exactly the same.  The policy uses Large Language Model (LLM) embeddings to determine semantic similarity between cache keys based on a configurable similarity tolerance.  Options: - semanticTolerance: The semantic similarity threshold for semantic cache matches (0-1, default: 0.2). Values closer to 0 require higher similarity. Can be overridden by custom functions. - expirationSecondsTtl: The timeout of the cache in seconds (default: 3600, 1 hour). Can be overridden by custom functions. - namespace: Optional namespace to isolate cache entries (default: "default"). Useful for multi-tenant scenarios or different cache contexts. - cacheBy: Determines how cache keys are generated: 'function' for custom logic or 'propertyPath' to extract from JSON body. | ai-gateway |
 | set-body-inbound | Set Body | Sets the body of the request in the inbound pipeline - make sure to convert a GET/HEAD request to another method when using this policy. | api-gateway |
 | set-headers-outbound | Set Headers | Adds or sets headers on the on the outgoing response. | api-gateway |

package/docs/policies/secret-masking-outbound/doc.md

@@ -39,3 +39,56 @@ Apply this policy to outbound requests in your route configuration:
 - Zuplo API keys (i.e. `zpka_xxx`)
 - GitHub Tokens and Personal Access Tokens (i.e. `ghp_xxx`)
 - Private key blocks (i.e. `BEGIN PRIVATE KEY` and `END PRIVATE KEY`)
+
+## Migrating to Data Loss Prevention
+
+The [Data Loss Prevention](/docs/policies/data-loss-prevention-outbound) policy
+supersedes this one. Its `secret-zuplo`, `secret-github`, and
+`secret-private-key` recognizers use the same patterns this policy does, so
+selecting them reproduces the current behavior exactly:
+
+```json
+{
+  "policies": [
+    {
+      "name": "dlp-outbound",
+      "policyType": "data-loss-prevention-outbound",
+      "handler": {
+        "export": "DataLossPreventionOutboundPolicy",
+        "module": "$import(@zuplo/runtime)",
+        "options": {
+          "action": "mask",
+          "entities": ["secret-zuplo", "secret-github", "secret-private-key"],
+          "mask": "<SECRET MASKED>",
+          "customPatterns": [
+            { "name": "key-value-pair", "pattern": "\\b(\\w+)=\\w+\\b" }
+          ]
+        }
+      }
+    }
+  ]
+}
+```
+
+Option mapping:
+
+- `mask` becomes `mask`, which only applies when `action` is `mask`.
+- `additionalPatterns` becomes `customPatterns`, where each entry takes a `name`
+  and a `pattern` plus optional `confidence` and `context` words.
+
+Two behavior differences to be aware of when you migrate:
+
+- Drop `entities` entirely to enable the whole built-in catalog — 60+
+  recognizers covering PII, payment and bank identifiers, national IDs, and API
+  keys for dozens of vendors — rather than only the three secret types this
+  policy handles.
+- Data Loss Prevention only inspects text content types (JSON, XML,
+  form-encoded, `text/*`) and passes binary bodies through untouched, whereas
+  this policy reads every response body as text. Set `contentTypes` to override
+  the allow-list.
+
+Use `action` to do more than mask: `block` replaces the response with a `422`
+that lists only the detected entity names, and `log` records a warning and
+returns the response unchanged. Pair it with
+[Data Loss Prevention - Inbound](/docs/policies/data-loss-prevention-inbound) to
+scan incoming requests as well.

package/docs/policies/secret-masking-outbound/intro.md

@@ -1,3 +1,10 @@
+> **Deprecated:** Use the
+> [Data Loss Prevention](/docs/policies/data-loss-prevention-outbound) policy
+> instead. It detects everything this policy does plus 60+ more entity types,
+> and can block or log a response rather than only masking it. This policy will
+> continue to work but will be removed in a future version of Zuplo. See
+> [Migrating to Data Loss Prevention](#migrating-to-data-loss-prevention) below.
+
 The Secret Masking policy searches for and masks common secrets and replaces
 them with a placeholder. Secrets that are automatically masked include:
 

package/docs/policies/secret-masking-outbound/schema.json

@@ -3,7 +3,7 @@
   "$id": "https://cdn.zuplo.com/policies/runtime/schemas/secret-masking-outbound.json",
   "type": "object",
   "title": "Secret Masking",
-  "isDeprecated": false,
+  "isDeprecated": true,
   "isPaidAddOn": false,
   "isEnterprise": false,
   "isInternal": false,
@@ -12,7 +12,7 @@
   "requiresAI": false,
   "products": ["api-gateway"],
   "description": "Masks common secrets like Zuplo API keys, GitHub tokens, or SSH private key in the response body.",
-  "deprecatedMessage": "",
+  "deprecatedMessage": "Use the [Data Loss Prevention](https://zuplo.com/docs/policies/data-loss-prevention-outbound) policy instead. It detects the same Zuplo API keys, GitHub tokens, and private key blocks via its `secret-zuplo`, `secret-github`, and `secret-private-key` recognizers, plus 60+ more built-in entities, and can block or log a response rather than only masking it. This policy will continue to work but will be removed in a future version of Zuplo.",
   "required": ["handler"],
   "properties": {
     "handler": {
@@ -31,19 +31,20 @@
         "options": {
           "title": "SecretMaskingOutboundPolicyOptions",
           "type": "object",
-          "description": "The options for the secret masking policy.",
+          "description": "The options for the secret masking policy. Deprecated - use the Data Loss Prevention outbound policy instead.",
           "additionalProperties": false,
           "required": [],
+          "deprecated": true,
           "properties": {
             "mask": {
               "type": "string",
-              "description": "The string to replace detected secrets with.",
+              "description": "The string to replace detected secrets with. Equivalent to the Data Loss Prevention policy's `mask` option.",
               "examples": ["[REDACTED]"],
               "default": "[REDACTED]"
             },
             "additionalPatterns": {
               "type": "array",
-              "description": "Extra regex patterns for secrets to mask.",
+              "description": "Extra regex patterns for secrets to mask. Replaced by the Data Loss Prevention policy's `customPatterns` option, which also accepts a name, confidence, and context words per pattern.",
               "items": {
                 "type": "string"
               }

package/docs/programmable-api/zuplo-json.mdx

@@ -64,6 +64,14 @@ deployed. This configuration defaults to `managed-edge`.
 }
 ```
 
+When the field is absent, [`zuplo link`](../cli/link.mdx) looks up the linked
+project and writes the matching `projectType` into your `zuplo.jsonc`, so the
+local runtime matches the deployed one. The CLI only adds the field — it never
+changes a `projectType` you already set, and it leaves your comments and
+formatting intact. If it can't confirm the type (for example, when it can't
+reach the Zuplo API), it leaves the file alone and local development falls back
+to `managed-edge`.
+
 ## `allowDuplicateRoutes`
 
 Allow duplicate routes (same method and path) to be defined. This isn't

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "6.73.19",
+  "version": "6.73.20",
   "type": "module",
   "description": "The programmable API Gateway",
   "author": "Zuplo, Inc.",
@@ -19,9 +19,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "6.73.19",
-    "@zuplo/core": "6.73.19",
-    "@zuplo/runtime": "6.73.19",
+    "@zuplo/cli": "6.73.20",
+    "@zuplo/core": "6.73.20",
+    "@zuplo/runtime": "6.73.20",
     "@zuplo/test": "1.4.0"
   }
 }