CircleCI Context Restricted by Security Group - Fix Access
A workflow references a restricted context, but the actor running the pipeline is not in the security group allowed to use it. The job is blocked (or runs without the secrets) because context restrictions gate who can read the values.
What this error means
The job is not authorized for the restricted context, or it runs but the context’s env vars are empty. This commonly hits fork PRs, scheduled pipelines, or users outside the allowed group - the secrets are intentionally withheld.
Context 'aws-prod' is restricted to security group 'deployers';
the current user is not a member.
Workflow not authorized to use this context.Common causes
Actor not in the context’s security group
A restricted context only releases its secrets to members of an allowed group. A pipeline triggered by a non-member cannot use it.
Fork PR or scheduled run
Fork pull requests and scheduled pipelines run with restricted identities; by design they cannot access restricted contexts that hold deploy secrets.
Group exists but the project/user mapping is wrong
The security group may not include the team or service identity actually running the workflow, so access is denied even though the context exists.
How to fix it
Scope deploy jobs to an authorized branch/actor
Gate the context-using job so it only runs in a trusted context (e.g. the default branch), not on forks.
workflows:
deploy:
jobs:
- publish:
context: [aws-prod]
filters:
branches:
only: mainFix group membership or split the context
- Add the team/identity running the workflow to the context’s security group in Org Settings → Contexts.
- Keep restricted (deploy) secrets out of workflows that must run on forks.
- Use a separate, unrestricted context for non-sensitive values.
How to prevent it
- Restrict deploy contexts to a security group and run them only on trusted branches.
- Never depend on restricted contexts in fork-PR or scheduled workflows.
- Keep group membership aligned with who actually triggers deploys.