Yes — to a point. In Prefect Cloud 3.x, the main ways to prevent “just anyone” from deploying or writing via the API are: 1. Workspace roles / RBAC 2. Service accounts with scoped workspace access 3. Object ACLs for specific deployments/work pools (Enterprise) 4. IP allowlisting (Enterprise) 5. Private connectivity via PrivateLink (Enterprise) What you cannot currently do is create an API key that is limited to only certain endpoints, hosts, or individual deployments unless you use higher-level controls like ACLs. Recommended baseline approach - Give humans Viewer or Runner roles unless they truly need write access - Give CI/CD its own service account and API key - Only assign Developer or Owner to the small set of users/services that should deploy - If you’re on Enterprise, add: - deployment/work-pool ACLs - IP allowlisting - optionally PrivateLink What controls deployment/write access? 1) Workspace roles Users and service accounts only get write access if their workspace role allows it. In practice: - Viewer → read only - Runner → can trigger runs, but not create/edit deployments - Developer → can create/edit/delete deployments - Owner → full workspace admin - Worker → intended for workers So if your concern is “who can deploy?”, the biggest control is: do not give Developer/Owner broadly. Docs: - Manage roles 2) Service accounts For automation, use service accounts instead of personal user API keys. That lets you: - isolate CI/CD access - revoke or rotate keys without impacting a person - give one pipeline access to one workspace, not everything a user has Docs: - Service accounts - API keys 3) Can API keys be limited to only certain actions? Generally, no — not in the fine-grained sense people often want. A Prefect API key effectively inherits the permissions of the user or service account in that workspace. So: - no per-endpoint allow/deny - no “deploy-only” key - no “read-only except X” key - no native restriction to only certain hosts making requests If you need more granularity, use: - custom roles (Enterprise) - object ACLs (Enterprise) 4) Object ACLs for specific deployments/work pools If you want only certain users/service accounts to access a particular deployment or work pool, Prefect supports object-level ACLs in Enterprise. That’s the closest thing to “this account can deploy here, but not elsewhere”. Docs: - Object ACLs Can I lock the API to certain hosts or IPs? Yes, but this is an Enterprise feature. 5) IP allowlisting Prefect Cloud supports IP allowlisting, which restricts access to the UI/API to specific IPs or CIDR ranges. That means you can allow only: - your office/VPN - your CI runners - your NAT gateway IPs Docs: - Secure access by IP address 6) PrivateLink If you need network-level lockdown beyond public internet access, Enterprise also supports AWS PrivateLink. Docs: - Secure access over PrivateLink Short answer to your exact questions “How do I prevent just anyone from deploying to Prefect or having write access via the API?” - Restrict workspace roles - Use service accounts for automation - Avoid giving *Developer*/*Owner* broadly - Use ACLs for sensitive deployments/work pools if on Enterprise “Can I lock down the API to certain hosts, IPs, or accounts?” - Accounts? Yes — via users, service accounts, roles, and ACLs - IPs/hosts? Yes, via IP allowlisting (Enterprise)

- Specific hostnames calling the API? Not as a standalone app-layer rule; Prefect’s network control is IP-based, not “hostname allowlist” Practical setup I’d recommend If you want a secure production posture: - Humans: - most users = Viewer or Runner - very few users = Developer - Automation: - one service account per CI/CD system - API keys with expiration + rotation - Enterprise extras: - ACLs on prod deployments/work pools - IP allowlisting for CI/VPN egress IPs - audit logs enabled Docs: - Audit logs If you want, I can also help you design a least-privilege access model for: - Cloud Standard/Pro vs Enterprise, or - dev/staging/prod workspaces with CI/CD deployment separation.

Yes, that makes sense. Short answer: not at the service-account/API-key level by host. Prefect Cloud does not currently support a rule like:

service account srv-acct may only use its API key from host X

What you can do is enforce this at the network boundary for the whole workspace/account: - IP allowlisting (Enterprise) — only requests from approved IPs/CIDRs can reach the Prefect API/UI - PrivateLink (Enterprise) — keep access on private AWS networking So if: - your trusted host

X

has a fixed egress IP, and - that IP is on the allowlist, and - a developer’s laptop is not on the allowlist, then a stolen key used from the laptop would fail. But that protection is not per service account — it applies to access to Prefect Cloud more broadly. Docs: - IP allowlisting - PrivateLink - Service accounts Important limitation If someone steals the key and can run from the allowed host/network (or from another machine behind the same NAT/egress IP), Prefect itself will not distinguish that usage by hostname. So for your exact security goal, the realistic pattern is: 1. Put deployments behind a dedicated CI/runner host or network 2. Store the API key only there in a secret manager 3. Restrict Prefect Cloud access with IP allowlisting 4. Use a dedicated service account with minimum required workspace role 5. Rotate keys regularly 6. Watch audit logs for unexpected usage Docs: - API keys - Audit logs If you are not on Enterprise, then Prefect Cloud does not have a native “host/IP restriction” control for this. In that case, your best protection is operational: - don’t distribute the key - keep it only in CI/infra secret storage - use separate service accounts per environment/workspace - keep permissions minimal If you want, I can sketch the best available architecture for: - non-Enterprise Prefect Cloud, or - Enterprise with IP allowlisting