Namespace Runner Access Levels: Permissive, Limited, Restricted
Namespace profiles let you control how much of the Namespace API a runner can reach, which matters for security-sensitive pipelines.
According to Namespace's runner-configuration docs, profile-based runners support three access levels that govern how much Namespace API access the runner has from inside a job. Choosing the right level reduces blast radius for untrusted or PR workloads. This guide summarizes the documented tiers; confirm current behavior in Namespace's docs.
The three access levels
Per Namespace's docs, the tiers are Permissive (the default, full workspace permissions), Limited (only GitHub Actions features are accessible), and Restricted (no Namespace APIs are reachable from the runner). They apply to profile-based runners.
When to lower the access level
For workflows that run untrusted code (for example pull requests from forks), a Limited or Restricted profile reduces what a compromised job can reach in the Namespace API. Reserve Permissive for trusted, first-party workflows that need full workspace features.
How to set it
- Open the relevant Runner Profile in the Namespace Dashboard.
- Choose the access level that matches the trust level of the workflows using that profile.
- Use a separate, more restricted profile for PR or untrusted workflows.
- Confirm the current tier names and behavior in Namespace's docs, as they may change.
Reliability alongside security
If reliability and per-minute cost are what you are optimizing for, Latchkey is a managed GitHub Actions runner with the same one-line runs-on swap that adds self-healing (transient and mechanical failures are detected, fixed, and retried automatically) at up to 60% lower per-minute cost than GitHub-hosted. You can pilot it on one workflow alongside Namespace and compare.
How to evaluate a managed runner honestly
Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.
- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.