Skip to main content
Atlasent/atlasent-action is a GitHub Action that calls /v1-evaluate before your deploy step and fails the job if the action isn’t permitted.

​
Minimal usage

The API key and runtime base URL are read from the ATLASENT_API_KEY and ATLASENT_BASE_URL environment variables — there is no api-key with: input. ATLASENT_BASE_URL should point at the AtlaSent functions base, https://api.atlasent.io/functions/v1 (self-hosted deployments use their own functions base instead); the api-url input can be used instead of/to override the env var. For change-controlled action types such as production.deploy, grant the job permissions: id-token: write so the action can mint a verified GitHub workload identity for the actor. The atlasent-action step fails the job if the decision is deny, hold, or escalate, if permit verification fails, or if the AtlaSent API is unreachable. Gate the deploy step on steps.gate.outputs.verified == 'true', not on decision — verified is only true when the evaluation returned allow and the server confirmed the permit was verified.

​
Execution-boundary mode

For a stronger boundary across jobs, issue the permit in one job without consuming it (mode: evaluate-only), then verify and consume it immediately before the protected step, in a later job:
mode: evaluate-only issues the permit but deliberately leaves it unconsumed (outputs permit-issued=true, verified=false); the later verify-permit: 'true' step re-verifies and consumes it at the real execution boundary. Gate the protected step on that later step’s verified output, never on the first step’s decision. For production.deploy, pass the first step’s execution-hash output unchanged to the verify step’s execution-hash input — it is the runtime-derived binding for the authorized change, and the verify step fails closed without it. Do not compute or substitute this value in the workflow. The action/target/environment inputs must also match the ones used at issue time.

​
Wait-for-approval mode

By default a hold or escalate decision fails the step. Set wait-for-approval: 'true' (default enforce mode only) to pause instead: the step polls for a human resolution in the AtlaSent Console, bounded by max-wait-minutes (default 30).
On approval, the step re-verifies the fresh permit against the same action, target, environment, and execution binding before treating it as allow — an “approved” status alone is never trusted. A denied, expired, or timed-out request fails the step closed. Set the job’s timeout-minutes above max-wait-minutes so the runner does not cut the wait short.
Trajectory verify is not a supported mode. Earlier material referenced trajectory-verify and /v1/trajectory-verify before a server-side endpoint existed. Do not use those inputs or outputs. Use the execution-boundary pattern above for exact-action authorization and verification.

​
Outputs

This is a curated subset of the commonly-used outputs. See action.yml for the complete list of supported inputs and outputs.

​
Fail-closed

The protected step must not execute when the decision is deny, hold, or escalate; when no permit is issued; when permit verification fails; when a permit is expired, revoked, invalid, or already consumed; or when the AtlaSent API is unreachable or authentication fails. No “skip on error” mode exists — that would defeat the point of the gate.