# Allowing Forked PRs to access Secrets **URL:** \ **Category:** Ecosystem\ **Created:** [October 18, 2019, 4:58pm UTC](https://discuss.circleci.com/t/allowing-forked-prs-to-access-secrets/32987 "2019-10-18T16:58:24Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![eddiewebb](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/eddiewebb/32/11733_2.png) [@eddiewebb](https://discuss.circleci.com/u/eddiewebb)\ **Post date:** [October 18, 2019, 4:58pm UTC](https://discuss.circleci.com/t/allowing-forked-prs-to-access-secrets/32987/1 "2019-10-18T16:58:24Z")
Based on previous requests like [https://discuss.circleci.com/t/pass-secrets-to-fork-prs-after-approval/16257/2](https://discuss.circleci.com/t/pass-secrets-to-fork-prs-after-approval/16257/2) > **Feature request:** Make it such that (if we so configure it) secrets _can_ be passed to fork PRs, but only after a GitHub collaborator has approved the PR using the GitHub review system. Thus, anyone using this tooling can have a workflow along the lines of: > > - PR is submitted from external contributor. > - Unit tests run and pass on CircleCI > - Someone with commit bit reviews the PR and approves it in GitHub > - Unit and system tests run and pass on CircleCI > - Branch is able to be merged Opening discussion about needs and work-arounds. I see only 2 real solutions to this… 1. Somehow run the pr changes on an internal branch, thus getting access to project settings, including secrets. There are manual ways to do this (change default branch to non-master, merge as an approval). [Bors.tech](https://bors.tech) is a great automated way to accomplish that a pre-test merges on an internal branch. And you can see an [example here](https://github.com/eddiewebb/circleci-queue/pull/37#issuecomment-543804362), 2. [Expose Restricted Contexts to forked PRs](https://ideas.circleci.com/ideas/CCI-I-1202). Since restricted contexts already consider the actor, not the project, this should ensure only approved actors are allowed to run the config with access to secrets. Maintainers could insert manual approval jobs or push to the PR themselves to get builds to pass. Have others found any interesting approaches? Does #2 seem viable?