Questions buyers ask first.
What AtlaSent does, how it fits next to the tools you already own, and what happens next. If your question is not here, ask it on a call.
The basics
What does AtlaSent actually do?
AtlaSent checks a consequential action in the moment before it runs and answers one question: has your organization authorized this exact action, by this actor, right now?
A production deploy, an access grant, a payment, a data export or an AI agent’s tool call goes to AtlaSent first. The answer is allow, hold for the person your rules require, or refuse. When it is allowed, only that exact action can go ahead. Change the commit, the target or the amount and it needs a new decision. Every decision, including every refusal, leaves a signed record of what was decided and why.
For production changes, in one line: AtlaSent stops risky changes to production unless someone approved them, and gives you proof for your auditor.
What counts as a consequential action?
An action that is hard or impossible to take back, or that your organization would have to explain afterwards: shipping code to production, changing infrastructure, granting admin access, moving money, releasing customer or patient data, sending to a live audience, or an AI agent calling a tool that changes a real system.
Reading data, drafting and preparing work usually are not. Software and AI can prepare the work freely; AtlaSent controls the action at the point it executes. The Action Catalog lists the actions we start from.
What does a held action look like, start to finish?
- Requested. An AI agent, a pipeline or a person asks to run an action, for example deploying one commit to production.
- Held. AtlaSent evaluates it against your rules before anything runs. Your rules say this action needs an approver, so it is held. Nothing runs while it waits.
- Approved. The person with authority approves that exact action. Where your rules require separation of duties, the requester cannot approve their own request.
- Permitted. AtlaSent issues a short-lived, single-use permit bound to that action. The system that executes it verifies the permit immediately before running.
- Runs and is recorded. Only that action runs, and its execution is recorded when it is actually observed. If the request changed in between, the permit does not verify and it needs a new approval.
Who is AtlaSent for?
Security, platform and engineering leaders who are accountable for what reaches production, and the risk, audit and finance owners who have to show that a consequential action was authorized. It also fits teams putting AI agents in front of real systems, through our design partner program. Developers can start on their own with free tools.
Can AtlaSent protect AI agents today?
Yes, through the AI Action Protection design partner program. The action gate, separate agent identities and approval holds exist in the runtime today. How they apply to your agents, tools and hosts is scoped and confirmed with you, not assumed. Developers can put the same check in front of an agent’s tools themselves with the MCP server or the SDKs.
How AtlaSent compares
We already have IAM, SSO and privileged access management. Isn’t that enough?
Keep them. AtlaSent uses them. Identity and access tools decide who someone is and what they can reach, usually when a session or credential is issued. They do not decide whether the organization authorized this specific action at the moment it runs.
A CI credential, an admin role or an agent holding a token can reach production. That is access, not permission to change it. AtlaSent takes identity as one input and adds the organization’s authority for the exact action. Identity says who. Authority says whether. See the comparison.
How is this different from AI security tools?
They can work together. AI security tools can inspect prompts and responses, govern tool calls, and block or contain unsafe behavior. Their controls can overlap with AtlaSent’s action gate.
AtlaSent does not judge content. It focuses on whether your organization authorized the exact action an agent is about to take: the deploy, the refund, the export, the access change. It binds your requirements, actor identities and any required approval to the action verified at execution. That decision is deterministic, it is made before the effect, and it fails closed.
We call this organizational authority. A valid identity, a working tool connection or a clean prompt check can each be a necessary input, but none of them is, by itself, the organization’s permission to act. On a protected path, an action nobody with authority approved does not run, whether or not a content check caught the manipulation that produced it.
We already run a security platform for endpoints and threats. Why add this?
Detection and response platforms watch for attacks and contain them. AtlaSent sits on a different line: before a consequential action runs, it checks that the organization authorized it.
Many risky changes are made with valid credentials through approved tools, so nothing about them looks like an attack. AtlaSent does not replace detection. It means a missed detection does not automatically become an executed change, and it gives you a record of who authorized what.
Does AtlaSent replace our pipeline, ticketing or approval tools?
No. Your pipeline still deploys, your ticketing or review system still records what was approved, and your identity provider still authenticates people. AtlaSent adds the decision between the approval and the execution, and the evidence afterwards. Your systems call AtlaSent at the point the action runs.
An existing approval must satisfy the configured requirements for that exact request. Approval of one commit, target or amount cannot authorize a changed request. We confirm the supported approval source and execution integration when we scope your first action.
People in the loop, and failing closed
Is this just human-in-the-loop approval?
A person’s approval is one input AtlaSent can require. When your rules require one, the action is held and nothing runs until that person approves.
But AtlaSent is not an approval inbox. The approval is bound to the exact action, so it cannot be reused for a different commit, amount or target. Separation of duties is checked, so the requester cannot be their own approver where your rules say so. And actions your rules do not require a person for are decided without one. You decide where a person is needed.
Won’t this slow our teams down?
Only where your rules say a person must decide. You choose which actions need an approver and which are decided automatically, and you start with one action rather than gating everything. An action that needs no approval gets one check before it runs.
What happens if AtlaSent cannot make a decision?
The action does not run. An error, a timeout or a malformed answer is a refusal, not a pass. That is deliberate: a control that lets actions through when it is unsure is not a control.
It is also why rollout starts with one action, and why we prove both a refusal and a valid run on your path before production protection is switched on, which you authorize separately.
Can someone just go around it?
AtlaSent can only decide actions that pass through it. If the same change can reach production another way, such as a console deploy or direct cloud access, the gate does not cover that path.
So AtlaSent reports each known execution path for a protected action as Complete, Partial, Unknown or Not configured, and a path we cannot see stays Unknown rather than being shown as protected. You see the gaps and decide how to close them.
During implementation we identify alternate routes, agree which will pass through the gate or be restricted by your existing controls, and document any routes left outside protection. A successful check on one route does not prove coverage of the others.
Build or buy
Couldn’t we build this ourselves?
You can build a check in front of one deploy. The check is usually the easy part. The harder parts are:
- binding an approval to the exact action, so it cannot be reused or swapped after review;
- verifying it where the action executes, not only when it was requested;
- separation of duties that the person administering the rules cannot quietly override;
- distinct identities for people, pipelines and AI agents, so an agent cannot act as the person it works for;
- knowing which alternate paths to the same system are still open;
- keeping a record a reviewer can trust without trusting the team that built the check.
Then all of it has to be maintained across every new system and agent. If you want to build, start with our free open-source tools and SDKs. If you want it run as a control your auditor can rely on, that is AtlaSent Enterprise.
Proof, getting started and pricing
What proof do we get?
Every decision, whether allow, hold or refuse, leaves a signed, hash-linked record of what was asked, who asked, the requirements it was measured against and the outcome. The decision, the permit verification, the execution and the effect are kept as separate records, and execution is recorded only when it is actually observed.
For production changes, exported records can be checked offline with a source-open verifier, without trusting AtlaSent’s servers.
What does AtlaSent work with today?
A GitHub Actions step in your deploy pipeline, TypeScript and Python SDKs for your own code, a REST API, and an MCP server for AI agent hosts. Other change platforms and business systems are scoped per engagement.
A connected integration is not the same as an enforcing one. We prove protection on your exact path before we call it protected.
How do we start?
Pick the one consequential action you most need to control. On an Enterprise call we look at that action and the route that performs it today.
Authority Launch proves that one consequential action in production: the identities, your requirements, a proven refusal, a proven valid run, and a production activation you authorize separately. Authority Launch typically takes 6–8 weeks, priced when we scope it. From there you expand into an annual Enterprise agreement, at custom annual pricing. Developers can start on their own with free tools and an API key.
Can someone help us set it up?
Yes, and you can see what needs setting up for free first. The Authorization Exposure Review, a tool in the AtlaSent MCP server, reads your CI workflow files and lists each deploy, publish or migration step that can run with no approval gate able to stop it, with the exact fix for each. It covers only the files it reads and says so. It runs on your machine and sends nothing anywhere.
You can apply the fixes yourself. If you want help explaining the findings or rolling the gates out, ask for an introduction to an independent implementation advisor. We tell you who they are first and share nothing until you agree. Their work is agreed and paid between you and them, and AtlaSent takes no fee from it. For Enterprise, Authority Launch is how we roll out your first action with you.
What does it cost?
AtlaSent Enterprise is custom annual pricing, scoped to the actions, systems and teams you need to protect. The path starts with Authority Launch (typically 6–8 weeks, priced when we scope it), which proves one consequential action in production, and expands into an annual Enterprise agreement. Authority Launch buys the proof; Enterprise buys the ongoing organizational authority infrastructure. Self-service plans for individual developers and small teams are listed separately on the pricing page and do not define Enterprise scope or price.
Where can our security team review AtlaSent?
The Trust Center carries our security overview, sub-processors, the current status of our compliance claims, policies and responsible disclosure. It states what we have and what we do not. We do not turn framework alignment into a certification claim.
AtlaSent Enterprise
Ask us about your own action.
An Enterprise call starts from the one consequential action you most need to control and the route that performs it today.