diff --git a/docs/usage/gitlab-bot-security.md b/docs/usage/gitlab-bot-security.md
index 6934c716ada363cc12d9819562c0e948c4cc3dc6..f44ad1bf7a3d02a3234bad4e5f5f2e4499b36169 100644
--- a/docs/usage/gitlab-bot-security.md
+++ b/docs/usage/gitlab-bot-security.md
@@ -10,8 +10,8 @@ You should understand GitLab's security model, before deciding to run a "bot" se
 
 ## `CI_JOB_TOKEN` permissions
 
-The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html), jobs are now run with the permissions of the user account which _triggered_ the pipeline.
-For security reasons the token was limited to read-only permissions and a limited set of API endpoints, but it’s been extended to allow [write access to the GitLab Package Registry](https://docs.gitlab.com/ee/api/README.html#gitlab-ci-job-token).
+The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/), jobs are now run with the permissions of the user account which _triggered_ the pipeline.
+For security reasons the token was limited to read-only permissions and a limited set of API endpoints, but it’s been extended to allow [write access to the GitLab Package Registry](https://docs.gitlab.com/ee/api/index.html#gitlab-ci-job-token).
 Any pipeline triggered by a user account thus has permissions to read any repository which that account has access to as well as publish packages to them.
 
 With the current GitLab CI permissions model, you should avoid committing to any project which you don’t trust completely, because that project could maliciously steal repository data, publish fake releases, or spam releases.