atmon for enterprise
Your teams hand over the work.
You decide where it runs.
Run it on our cloud, in a setup that is your organization's alone. Or run it in your own building. Either way a department gets an assistant that finishes the work in the systems it already uses, and every action is checked against your rules first and recorded after.
Where it stalls today
Your teams have already tried this
Somebody in finance operations asked an assistant to chase the overdue invoices. It came back with a good list and a good draft, and then it stopped, because it cannot open the billing system and it cannot send anything.
So the plan is right and the work is still manual. That is the state of it in every department that has tried: the thinking arrives, the doing does not.
The reason is not the model. It is the review. Nobody signs off on an assistant holding real credentials in a real system with no limits on it and no record of what it did.
The blocker is trust, not capability. Everything on this site is about what a security review needs before the doing is allowed.
The two offers
Two ways to run it
The software is the same in both, and so are the rules, the roles, the approvals and the record. What changes is who holds the machine, and that is what decides which promises we are able to make you.
On our cloud
We run it, with enterprise controls
Your organization gets a place of its own, kept apart from every other, with the whole record of every action and every refusal in it. Where the agreement warrants it, a setup we run for you alone: your own address, on a node nobody else is on.
Your administrators sign in with an email at enterprise.atmon.ai/console. There is nothing for your platform team to stand up and nothing for it to operate.
In your building
You run it, and no data leaves the building
The software runs on machines you own, inside your network, sealed with a key you generate. Credentials, records and the work itself stay where they are, and the one thing that ever crosses the boundary is a signed count of what your deployment did.
Your cloud account, a private subnet with no way in from outside, or a server on your own floor. Your team operates it, under the change process your team already runs.
Both are one annual license and both start from the same floor. What runs where, drawn, and what each shape costs.
In your world
What a department hands over
Three shapes of work, said the way the people who own them would say them. Each one runs against systems your teams already log into.
Finance operations
Chase the overdue invoices. It finds the ones past due in your billing system, drafts the reminder in the mailbox that normally sends them, and holds anything above your limit until a person releases it.
Customer support
Work the overnight queue. It reads each ticket, pulls the order and the account behind it, drafts the reply, and waits for a person before anything that offers money or credit goes out.
IT and access
Joiners and leavers. It opens the accounts a new starter needs and closes every account a leaver had, in the order your policy sets, and shows you the whole plan before the first step runs.
None of the three is a demonstration account or a copy filled with made-up data. They are the systems the department works in, reached under the limits you wrote.
The review
What your reviewer is going to ask
Seven questions, in the order they usually arrive. Where the two offers answer differently, both answers are here, because the difference is the thing being decided.
| The question | On our cloud | In your building | Written out |
|---|---|---|---|
| Where does the software run? | On our machines, in a place your organization is alone in | On machines you own, inside your own network | Deployment |
| Where do the credentials sit? | Sealed in the store, under the key that seals our deployment | Sealed in the store, under a key you generate and hold | Security |
| Can anybody read one back out? | No. Nothing on any surface returns a stored secret, on either offer | Security | |
| What is it allowed to reach? | Only the addresses on your list. Everything else is refused, and the refusal is recorded with what was reached for | Security | |
| Who can approve? | Somebody other than whoever asked, holding a role you gave them. The asker cannot release their own work | Security | |
| What does the audit look like? | A row per action, exported from your console whenever you want it | A row per action in your own database, kept as long as your policy says | Security |
| Whose accounts are your people in? | Ours, in the setup we run for you. The door is an email and nothing else | Yours. We hold no account for anybody who works for you | Security |
The deal
The shape of the agreement
- Hosted enterprise An annual license, invoiced, from $24,000 per year, with the setup we run for you inside the number. What the commitment covers is set in the conversation rather than on a self-serve page.
- On-prem license An annual license per node, from the same floor. The meter is a signed count of the actions your deployment took, which is the one thing that crosses the boundary, and you can read the same counts yourself.
- Viewer seats Free and unlimited on both. The people who only need to read the record never cost anything, because an audit nobody can open is not an audit.
The license, in full, with both shapes side by side.
Said plainly
Where this stands today
- Beta Live provider connections are beginning with GitHub. Every other path on this site is proven against stand-in services rather than against your systems.
- No outside audit There is no third-party security audit and no compliance certificate to hand your reviewer today. What exists is the design, on trunk, with tests.
- Single sign-on is not built Single sign-on and directory provisioning are on the enterprise roadmap and are not shipped. Accounts and roles live in your deployment until they land.