Proceed
The exact request meets the configured rules and authority requirements.
Business decisions for agent-driven work
Your agents can do the work. You’re still deciding what they’re allowed to do.
You want work to move forward without reviewing every request yourself. AtlaSent is the business decision layer that applies your company’s rules and authority before a consequential action, so the agent knows whether it may proceed, must wait or must stop.
Start with a fictional example below. Real workflow setup and enforcement depend on the supported action and execution path.
Wait
A required approval or fact is missing. The action remains pending.
Stop
The request is not authorized. The reason is recorded.
Illustrative outcomes. A decision is not execution; connected tools must enforce the check before the action runs.
Free · no login · runs in your browser
Try it on your own work first.
Change Check
Paste a public GitHub pull request. See which revision was approved, which checks ran on the code that merged, and what GitHub cannot show. Passing CI is not an authorized deploy.
Approval Tester
Describe your approval rule. AtlaSent’s policy engine shows whether self-approval, a repeated reviewer or an expired approval would get through.
AI Permission Check
Paste an MCP tool list. See which tools could move money, delete data or run code, and what to ask before an agent uses them. Nothing is uploaded.
From another approval request to a permitted next step
Who says this action can go ahead?
Your business establishes the rules, delegated limits and authorized approvers. AtlaSent checks the exact request against the configured requirements. Your connected agent or workflow carries out the permitted next step.
In the refund example, see a request pass, wait for approval, fail a rule or require escalation. Then download the example policy.
See the decision before you connect anything.
The refund demo uses fictional requests and an example policy in your browser. No signup, credentials or money movement. A sample result is not a live authorization or proof of protection.
Why teams start here
Fewer hand-offs. Only the approved change runs. Proof afterwards.
Review without the chase
Each change is routed to the people your rules require, with separation of duties checked, instead of being chased across tickets, chat and pull-request comments.
Only the approved change runs
The approval is bound to the repository, commit and environment. Change the work after review and it needs a new decision before it can deploy.
Proof of what happened
The decision, the permit check at execution and what actually ran are kept as separate signed records your auditor can verify offline.
We measure review time, hand-offs and approvals on your own change path during the launch. We do not publish a speed figure we have not measured with a customer.
Illustrative example
The approval must match the action that runs.
On a connected production-change path, approving one change does not authorize a different one.
Approved
A reviewer approves a specific repository, commit and production environment. The permit is bound to that request.
Changed
The commit or target changes after review. The original approval does not cover the new request.
Refused
The changed request cannot use the original permit. It needs a new decision before execution.
This is an illustrative workflow, not a live customer result. Decision, permit verification, execution and observed effect remain separate records. Protection covers the execution paths that enforce the check.
Where we are going
One change, checked across every system it touches.
A change is often proposed in one system, reviewed in another and deployed to a third, such as a configuration change proposed in GitHub, reviewed by your team and deployed to an ERP or CRM. AtlaSent is being built to carry one authorization across that path and then check the target system for what actually changed.
Today: a GitHub Actions step, the TypeScript and Python SDKs, the REST API and the MCP server. Business-system paths are scoped per engagement, and checking the result in the target system is in development, not a shipped capability.
The question we answer
Was this exact change approved by the right people, could something different have been deployed, and can you prove what really happened afterwards?
Enterprise products
Start with production changes. Extend the same controls to AI agents.
Production Change Protection
Deploys, infrastructure and configuration changes run only when the exact change is authorized: the right identities, approvals and separation of duties, bound to the repository, commit and environment. Change the work and it needs a new decision.
AI Action Protection
Agents can hold credentials and tool access without your organization’s permission to act. AtlaSent gates the consequential tool call, records the agent’s provenance, holds for a person when your rules require one, and refuses when authority cannot be established. We confirm the supported agents, tools and execution paths with your team before activation.
Find your path
Just because you can doesn’t mean you should.
Capability is not authority. AtlaSent provides organizational authority before consequential actions, and evidence of what actually happened.
CIOs and VPs of IT
What changes in production and across business systems, and being able to answer for it afterwards.
Your path →Engineering and platform leaders
Shipping quickly without self-approved changes, swapped commits or deploys that went around the pipeline.
Your path →Security leaders
Privileged and consequential actions by people, pipelines and AI agents, and the evidence behind them.
Your path →Regulated operations: quality, finance and clinical
Showing that a batch release, a payment or a code break was authorized by the right qualified person, for exactly that action.
Your path →Running AI agents? See how organizational authority applies to agent actions.
How protection works
Gate the action. Preserve the proof.
- Find the action boundary. The point where a deploy, grant, export or tool call actually executes.
- Apply your organization’s requirements. Who may do it, who must approve, which duties must stay separate, and under what conditions.
- Decide before it runs. Allow, refuse or hold for a person. Refusals fail closed, with the reason.
- Verify at execution. Only the exact action that was authorized can go ahead. Change the commit, target or amount and it needs a new decision.
- Preserve the proof. Every decision, yes or no, leaves a signed, hash-linked record you can verify offline.
An approval decision is not proof the action ran. AtlaSent verifies the permit at the point of execution, and records what happened only when it is actually observed or reported.
For the technical reader
Identity is not authority. Approval is not authorization. An allow decision is not proof of execution. Permit verification is not execution success.
Enterprise operating layer
Run protection as an organization, not a pipeline step.
Enterprise adds the layer that lets security, platform and risk owners see what is protected, what is not, and why, across teams and systems.
Protection Portfolio
Every protected action in one place: what it protects, the path it runs on, the requirements it enforces and its current state.
Coverage
Each action and execution path is Complete, Partial, Unknown or Not configured. Unknown stays Unknown. It is never shown as protected.
Identity and administration
People, services and AI agents are resolved as distinct identities. Enterprise identity and member administration are confirmed for your environment in the agreement.
Organizational controls
Approvals, separation of duties and independent review are required where your rules say, and kept separate from who can administer the rules.
Findings and operations
Blockers, gaps and drift are surfaced with the exact repair, so owners can fix protection instead of reading a wall of green checks.
Evidence and proof
Every decision leaves a signed, hash-linked record you can verify offline. Execution and effects are recorded only when they are actually observed.
Support and implementation
Assisted implementation of your first protected action, and support commitments written into the agreement.
AtlaSent Enterprise
Start with one consequential action.
Authority Launch proves one consequential action in production: we find the execution path with your team, configure your requirements, prove a refusal and a valid run, and prepare a separately authorized production activation. Then expand into an annual Enterprise agreement.
Action Catalog
What do you want to authorize?
Software and AI can prepare the work. AtlaSent controls the consequential action at the point it executes.
Actor+Action+Resource+Context+Authority requirements+Evidence→DENYHOLDPERMIT
| Work AI or software can prepare | Consequential action AtlaSent controls | Canon |
|---|---|---|
| Draft an agreement | Sign agreement | Canonical action identity.sign |
| Complete an application | Submit application | Canonical action submission.submit |
| Find availability | Schedule appointment | Custom action today |
| Draft correspondence | Send message | Canonical action communication.external.send |
| Prepare an order | Place purchase | Canonical action workflow.approve |
| Reconcile an invoice | Pay invoice | Canonical action finance.payment.authorize |
| Prepare a transfer | Move money | Canonical action finance.wire.transfer |
| Analyze a refund | Issue refund | Canonical action finance.payment.authorize |
| Prepare a filing | Submit filing | Canonical action submission.submit compliance.certify |
| Generate content | Publish externally | Canonical action content.publish |
| Evaluate a user | Grant access | Canonical action access.grant |
| Prepare records | Release data | Canonical action data.export |
| Generate or change code | Deploy production | Canonical action production.deploy |
| Prepare infrastructure change | Change infrastructure | Canonical action infrastructure.change |
| Determine an emergency action | Unblind / override | Canonical action trial.unblinding.emergency control.override |
| Anything else your systems or AI prepare | Custom action | Define your own |
Other consequential actions
The same protection, wherever the action is irreversible.
Privileged access
Admin grants, new roles and break-glass access, checked against who may approve them before they take effect.
Data release
Exports of customer, patient or audience data to another system or party, held until the right person authorizes the release.
Finance actions
Payments, journal entries and close certification, bound to the amount, payee and entity that were authorized.
Regulated actions
Batch release, unblinding and validated-system change, with evidence a reviewer can verify independently.
Your systems call AtlaSent before the action. AtlaSent does not replace your identity provider, pipeline or export tool.
For developers
Building it yourself? Start free.
The agent guard and MCP Gate block risky actions on your machine with no account. The TypeScript and Python SDKs, the REST API, the MCP server and the GitHub Action put the same checks in your own code and pipelines. Self-service cloud plans are separate from Enterprise.
Partners
Implementation, advisory, channel and technology partners deliver AtlaSent inside the security, technology, finance and AI programs they already run.