Authorized
Request. A release engineer with standing deploy authority, two approvals recorded, inside the change window.
Result. A permit is issued for this exact repository, commit and environment. The deploy step verifies it and runs.
Walkthrough
Four requests. One gets through.
The same production deploy, requested four ways. This is an illustrative walkthrough of how AtlaSent decides, not live output. To see it on your own change path, schedule an Enterprise call; to run a real evaluation yourself, follow the five-minute developer quickstart.
Illustrative walkthrough — not live output
production.deploy, four ways.
Unauthorized actor
Request. An AI agent holding a valid CI credential, but no delegated authority to deploy to production.
Result. Refused before execution. A credential that can reach production is not authority to change it.
Missing approval
Request. The right engineer, but the second required approval has not been recorded yet.
Result. Held, not failed open. The request waits for the approval the policy requires, then is evaluated again.
Changed after approval
Request. An approved deploy, then the commit is swapped before execution.
Result. Refused at verification. The permit is bound to the approved commit, so different work needs fresh authorization.
Every one of the four, including the refusals, produces a signed, hash-linked evidence record that can be verified offline.
For engineers
What the gate looks like in your pipeline.
One step before the deploy. A refusal fails the step, so the deploy never runs.
# .github/workflows/deploy.yml — the deploy job needs
# permissions: { id-token: write } for the workload identity
- id: atlasent
uses: Atlasent/atlasent-action@v1
env:
ATLASENT_API_KEY: ${{ secrets.ATLASENT_API_KEY }}
with:
action: production.deploy
- name: Deploy
if: steps.atlasent.outputs.verified == 'true' # gate on verified, not decision
run: ./deploy.sh