1. Start a pentest
First, choose the production hostname you want to test and submit it for approval. This example checks for an exact hostname, such asapi.example.com. Submit that hostname separately if you already have a wildcard target.
Install the SDK and tsx, which runs the TypeScript script:
2. Give the agent more context
You can customize tCell before starting the run. For this example, ask it to investigate access between accounts and give it constraints for testing production. Replace the agent lookup above with this configuration:agent.run() stays the same.
3. Follow the run and collect results
A pentest can take time. Iterate over the run to print activity as it happens, so someone viewing the CI logs can follow its progress:run.wait() resolves when testing completes and throws if the run fails or stops. Once it resolves, retrieve the vulnerabilities:
4. Make the results a CI check
This example fails the check when it finds a critical vulnerability. It saves all vulnerabilities to a JSON file so your team can review the results, including issues below that threshold. Add the filesystem import at the top of the script, then save the results after retrieving them:main() and handles errors separately:
It also saves
run.json as soon as the run starts. That file contains the run ID, target, and triggering deployment’s commit, which you can use to find the run later.
5. Run after a production deployment
With the script in place, connect it to GitHub Actions. Add these values under your repository’s Settings → Secrets and variables → Actions:
The workflow listens for deployment status updates and starts its job when the deployment succeeds in
production:
production if it uses a different environment name.
After checking out your default branch and installing dependencies, the workflow passes the configured values to the script:
pentest-results/ as an artifact, including when critical vulnerabilities fail the check. Your team can download it from the workflow execution or review the vulnerabilities and evidence in Antigen.
If deployment itself runs in GitHub Actions, you can instead add the pentest job after your deployment job with needs: deploy. Adapt the condition to that workflow and pass the deployed commit as DEPLOYMENT_SHA. Events created using a workflow’s GITHUB_TOKEN generally do not trigger another workflow. See Triggering a workflow.
6. Limit testing to once every 24 hours
Your team may deploy several times a day. Before installing dependencies or starting a pentest, the workflow checks whether its Run pentest step has already started in the last 24 hours. GitHub keeps that history, so the check can read earlier executions and their job steps. It includes previous attempts of rerun workflows. Once it finds a recent pentest attempt, it returns early:cooldown. Later steps use its result to decide whether to proceed:
Complete files
Save these files in your repository and commit them withpackage.json and package-lock.json to your default branch.
scripts/pentest.ts
scripts/pentest.ts
.github/workflows/pentest.yml
.github/workflows/pentest.yml
run.json identifies what triggered testing.
If CI is cancelled or times out, the agent can continue working. Use the run ID in the logs or artifact to retrieve or stop it.