diff --git a/fern/security-and-privacy/api-keys.mdx b/fern/security-and-privacy/api-keys.mdx
index 35d7a4990..51d27bc58 100644
--- a/fern/security-and-privacy/api-keys.mdx
+++ b/fern/security-and-privacy/api-keys.mdx
@@ -17,13 +17,15 @@ If you're setting up API access with an AI coding assistant, the [setup-api-key
 
 ## How it works
 
-Every API key belongs to one Vapi organization. Choose the key type based on where your application runs, then limit the key to the origins and assistants that need access.
+Every API key belongs to one Vapi organization. Choose the key type based on where your application runs, then limit a public key to the origins and assistants that need access.
 
 | Key type | Use it for | Where to store it |
 | --- | --- | --- |
 | Public API key | Client-side Vapi SDKs and web integrations | Client-side application configuration |
 | Private API key | Vapi REST API, server SDKs, and server-side integrations | Server-side secret manager or environment variable |
 
+Only public keys support allowed origins and allowed assistants. A private key can access everything in your organization, so store it server-side and delete it if it is exposed.
+
 ## Prerequisites
 
 - A [Vapi account](https://dashboard.vapi.ai/)
@@ -53,10 +55,18 @@ Every API key belongs to one Vapi organization. Choose the key type based on whe
   </Step>
 
   <Step title="Restrict access">
-    For a public key, enter the URLs that may use the key in **Allowed Origins**. In **Allowed Assistants**, select the assistants the key may access. Enable **Transient Assistant** only when the application needs to create calls with [transient assistants](/assistants/concepts/transient-vs-permanent-configurations).
+    For a public key, enter the origins that may use the key in **Allowed Origins**. In **Allowed Assistants**, select the assistants the key may access. Enable **Transient Assistant** only when the application needs to create calls with [transient assistants](/assistants/concepts/transient-vs-permanent-configurations).
 
     For example, add `https://app.example.com` for a production web application.
 
+    Allowed origins follow these rules:
+
+    - Enter each origin as a scheme, host, and optional port. Any path is ignored.
+    - The scheme, host, and port must match the `Origin` header the browser sends.
+    - Use `*` in place of one whole subdomain label, one dot-separated part of the host. For example, `https://*.example.com` matches `https://app.example.com` but not `https://example.com` or `https://a.b.example.com`.
+    - Partial wildcards, such as `https://myapp-*.example.com`, never match.
+    - If you set no allowed origins, the key works from any origin.
+
     <Frame caption="Configure the public key name and access restrictions.">
       <img src="../static/images/security-and-privacy/api-keys/new-public-api-key-sidebar.png" alt="Complete New Public API Key form with the expanded Dashboard sidebar, name, allowed origins, allowed assistants, and transient assistant settings" />
     </Frame>
@@ -93,6 +103,8 @@ Replace `YOUR_PUBLIC_API_KEY` and `YOUR_ASSISTANT_ID` with values from your Vapi
 
 <Note>
 Public API keys are visible in client-side code. Restrict them to the required origins and assistants. For short-lived or user-specific access, use [JWT authentication](/customization/jwt-authentication).
+
+Restricting a public key to specific assistants does not stop callers from sending `assistantOverrides` for those assistants. Do not rely on a public key to protect the system prompt or server settings of an allowed assistant.
 </Note>
 
 ## Test a private API key