Identity
Who or what is making the change: a person, a pipeline or an agent, resolved as distinct identities.
Production Change Protection
AtlaSent stops risky changes to production unless someone approved them, and gives you proof for your auditor.
For organizations that need production deploys, infrastructure and configuration changes to run only when the exact change is authorized, and need to know which change paths are protected and which are not.
- RequestedA deploy of one commit to production.
- HeldWaits until someone with authority approves it.
- ApprovedApproved for that repository, commit and environment.
- RunsOnly that commit deploys.
A different commit needs approval again.
The problem
Access to production is not permission to change it.
A CI credential, an admin role or an AI agent holding a token can push a change to production. The approval usually lives somewhere else: a ticket, a pull-request review, a chat thread. At the moment the change executes, nothing checks that the change actually running is the one that was approved, by people allowed to approve it.
What goes wrong
A self-approved change. A commit swapped after review. A hotfix pushed around the pipeline. A deploy from a path nobody knew was open.
The action boundary
Put the decision where the change executes.
AtlaSent runs as a step in the deploy path, before the change. If the exact change is authorized, the step passes. If not, it fails with the reason, and the deploy never runs. GitHub Actions is supported today; other change routes are scoped per engagement. A connected route is not an enforcing one until acceptance proves it on that exact path.
Organizational requirements
Required approvals, independent review and separation of duties: the requester cannot approve their own change.
Material binding
The decision is bound to the repository, commit, environment and target. Changed work needs a new decision.
Coverage truth
Know which paths are protected, and which are not.
A gated pipeline does not help if the same change can reach production another way. For every protected change, AtlaSent reports each known execution path as Complete, Partial, Unknown or Not configured. Alternate routes such as a console deploy, direct provider access or a change platform are listed, and a path we cannot see stays Unknown.
Unknown is not green
Coverage is never inferred from a connected integration. An unknown route is shown as unknown, so you can decide whether to close it rather than assume it is closed.
Refusal
The wrong change fails closed, with the reason.
Self-approved
Request. The engineer who wrote the change is the only approver.
Result. Refused. Separation of duties requires an independent reviewer.
Missing approval
Request. The right engineer, but the required approval is not recorded yet.
Result. Held, not failed open. It waits for the approval your rules require.
Unverified actor
Request. A pipeline credential with no verified identity behind it.
Result. Refused before execution. A credential that can reach production is not permission to change it.
Changed after approval
Request. An approved deploy, then the commit is swapped.
Result. Refused at verification. The permit is bound to the approved commit.
Permit
Only the approved change can run.
When the change is authorized, AtlaSent issues a short-lived, single-use permit bound to that exact change. The deploy step verifies it immediately before execution. A replayed permit, an expired one, or one presented for a different commit or environment does not verify.
Gate on verified, not on decision
An allow decision is not proof the change ran. The permit is consumed at the execution boundary, and the pipeline proceeds only when verification succeeds.
Execution and effect proof
Four records, never merged into one.
Decision
Allow, refuse or hold, with the reason and the requirements it was measured against.
Permit verification
The short-lived, single-use permit is checked where the action executes. A different action does not verify.
Execution
Recorded when the execution is actually observed or reported, never inferred from the decision.
Effect
The downstream result is kept separate and marked verified only where it has been verified.
Records are signed and hash-linked, and exports can be verified offline with a source-open verifier, without trusting AtlaSent’s servers.
For engineers
Gate the deploy in your pipeline.
The deploy runs only after the exact repository, commit and environment are approved. Change the commit and it needs approval again.
# .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.shAtlaSent Enterprise
Protect your first production change path.
Authority Launch puts one production change path under protection with your team: identities, requirements, a proven refusal, a proven valid run, and a separately authorized production activation. Then expand into an annual Enterprise agreement.