Security
The limits are set outside the model.
Two offers, two honest lists.
An assistant that can act inside your systems needs its limits set by you. Every limit here is checked inside the path an action takes, so a refusal happens before your systems are touched at all. What changes between the offers is who holds the machine, and this page says so both ways.
On our cloud
What we hold, and what we do not
If we run the machine, a claim that we see nothing would be a lie. So the hosted offer gets its own list, in the same shape as the one under it, and neither list borrows a word from the other.
- A place of your own Every read is scoped to your organization, and a record belonging to somebody else reads as missing rather than as refused, so nobody learns what else is there by guessing. Where the agreement warrants it, your own address on a node nobody else is on.
- Your credentials Every password, token and key your people connect is sealed in the store under the key that seals our deployment. No surface returns a stored secret, so there is no path by which one is read back out, by you, by us, or by anything that asks.
- Your record Every action, every refusal and every approval is a row, written as the last step of the action, on the same terms as the record on your own machines. Your administrators export it from the console whenever they want it rather than asking us for it.
- Your rules The same rules document, the same ceilings and deny lists, the same approval thresholds, checked in the same place in the path. The asker still cannot release their own work and an assistant still cannot rewrite the rules.
- Your people Accounts live in the setup we run for you, and the door is an email and nothing else: no key entry, no address to type. Single sign-on is on the roadmap and is not built. An administrator invites a person and gives them a role, and nobody self-joins.
- What our operators reach We run the machine, so our operators can reach the machine. What they cannot do is read a stored secret back out, because no path returns one, and what they do not do is read your record as a matter of course.
If your policy says no third party may hold the credential at all, the honest answer is the offer below rather than this one. It is the same software under a license that covers either shape, and your administrators start at enterprise.atmon.ai/console only on this one.
In your building
What we never see
This is the whole list for the on-prem offer, and it is the reason that offer exists. Everything under it on this page is how each line is held.
- Your credentials Every password, token and key your people connect goes into a store inside your deployment, sealed with a key you generate and hold. No copy of that key exists outside your organization, and nothing we run can open the store.
- What an action carried The arguments going out and the answers coming back move between your deployment and the systems you connected. Invoice lines, ticket bodies, documents, rows: none of it passes through anything of ours.
- Your record The audit is a table in your own database, on your own storage, kept for as long as your retention policy says. We cannot read it, cannot query it and cannot delete a row of it.
- Your people Names, addresses, roles and sessions live in your deployment and your own identity system. We hold no account for anybody who works for you.
- What you asked for The instruction a person typed, the plan an assistant made from it and the model calls behind that plan all stay inside your network, against the model endpoint you registered.
- Your network Nothing dials home for instructions and nothing opens a path back in. We are not on the list of addresses your deployment may reach, and adding us is not something the software can do for itself.
One thing crosses the boundary, and this is it: a signed count of the actions your deployment took, which is what the license is invoiced against. It carries counts, dates and a signature. It carries no arguments, no answers, no names and no addresses, and the pricing page writes out exactly what is in it.
Credentials
The store, and the key over it
Each person connects their own accounts once, the way they would connect an app to a work calendar. The secret goes straight into the store and is sealed there, and what the assistant is handed instead is a numbered claim ticket.
The ticket is enough to say act as this person in this system. It is not enough to walk off with the account, and a request that carries no ticket fails rather than going out unsigned.
The key that seals the store is given to the process at start. A missing or malformed key stops the deployment from starting; there is no path where it runs without one.
- No read path. Nothing on any surface returns a stored secret. Outbound calls are authorized inside the store against a placeholder, rather than by handing the secret to whatever asked.
- A cap on what may be requested. A project can say which permissions its connections are allowed to ask a provider for, and the cap is checked before the consent screen is built rather than after somebody has already agreed.
- Revoking is one step. Take the connection away and every future action through it stops. Work already running finishes or fails, and says which it did.
- Who holds the key. On our cloud it is the key that seals our deployment, held by us and returned by nothing. On your own machines you generate it and hold it, and no copy of it exists outside your organization.
Outbound
Where a deployment is allowed to reach
There is a written list of every outside address the deployment may contact. Everything not on it is refused, and the refusal is recorded along with what was reached for. You do not maintain the list by hand, and every entry says why it is there.
| What goes on the list | Where the entry comes from |
|---|---|
| The apps your people connected | Added when the connection is made, removed when it is revoked |
| Your relays | Registered by an administrator, for internal systems with no public address |
| Your model endpoint | The address and key you registered for the per-row reasoning work |
| Your storage | The bucket a project's files and collections point at |
| An address issued to your account alone | Some providers give every customer their own hostname; the one your account answers on is the one the list names |
A list maintained by hand is a list somebody forgets to trim, which is why entries arrive and leave with the thing that justified them. A request that never established which address it belongs to is refused rather than sent somewhere nobody chose.
The order
What happens before anything is touched
This is the sequence every action goes through, and the order is what decides what a refusal costs.
- Work out what was actually asked for.
- Read the details of the request.
- Refuse anything that deletes or destroys unless the request says yes to that in so many words.
- Check your rules: what is allowed, what is denied, who may act, what needs a person, how often it may act at all.
- Take the lock, where the work needs one.
- Only now, unlock the account and go.
A refusal therefore unlocks nothing, holds nothing open and never reaches your systems. That is the reason the checks sit inside the path rather than in front of it: a request turned back at the third step never gets as far as the store, and the key stays where it is.
Your rules are one document per project. Changing it takes an approver, and an assistant is refused. An assistant that could rewrite the rules could delete the ceiling, the deny list and the approval step in one move, which would make all three advice rather than limits.
Who may act
The role model
Four roles, and the one property that makes an approval worth having: the person who asked for the work cannot be the person who releases it.
| Role | What it can do | Seat |
|---|---|---|
| Administrator | Invite and remove people, change roles, create and delete projects, register relays, hold the license | In the commitment |
| Approver | Write the rules document, release work that is waiting on a person, set ceilings and deny lists | In the commitment |
| Member | Connect their own accounts, hand over work, read what their own work did | In the commitment |
| Viewer | Read the record and the usage, and nothing else. Cannot act, cannot approve, cannot connect | Free and unlimited |
Work done for one person cannot touch another person's connections, and one project's records are invisible to another project's. Asking for something that belongs elsewhere gets the same answer as asking for something that does not exist, so nobody learns what else is in there by guessing.
Viewer seats are free because an audit only your administrators can open is an audit your auditors have to ask permission for.
Limits
Ceilings a run stops at
You write down what a project may spend and how fast it may act, and both are checked in the same place as everything else on this page: before the account is unlocked.
When a ceiling is reached the next request comes back refused and says so, rather than being quietly dropped or retried until it works.
- Money. So a long job cannot spend more than the department meant it to.
- Pace, per person. So a mistake that would have sent a thousand messages sends the first few and then stops.
- Approval thresholds. So anything above a line, or anything leaving the company, waits for a name.
The audit
The record is the audit
Writing the record is the last step of every action and it is not optional. No path through the software is allowed to skip it, which is what makes the record complete rather than mostly complete.
On your own machines it is a table in your database, so your own tools read it and your own retention governs it. On our cloud it is yours to export from the console, on your own schedule, without asking anybody for it.
- What ran, who asked for it, what changed, what was refused and why, and what is still waiting on a person.
- Refusals are rows too. A policy that turned something back is as much of an audit event as an action that went through.
- A partial result says it is partial. A job that could not read everything finishes and names what it missed, rather than reporting a clean run over half the work.
- A crash halfway through does not send anything twice. When it picks up again it knows what already went out.
- Code your own people write in a reduce step runs sealed off from everything: no network, no clock, no files.
The boundary
What we are not claiming
atmon is in beta, and the honest boundary matters more on this page than anywhere else on this site.
- One live provider account, not the whole list. GitHub is the first provider sign-up registered. Every other path above is proven against stand-in services and made-up data rather than against a real account.
- No outside audit. There is no third-party security audit and no compliance certificate to point at today.
- Single sign-on is not built. It is on the enterprise roadmap and it is not shipped. What exists today is said plainly on the ecosystem page.
- What does exist. The design above, on trunk, with tests, and a team that would rather tell you this than let your reviewer find it.
For the review
The same facts, in your reviewer's terms
Everything in this panel is stated in plain words above. This is the version with the terms attached, for the person who is going to search for them.
The technical detail
- Credential storage.
AES-256-GCMwith a fresh nonce per value, in a versioned envelope. The key is supplied by the deployment, and a missing or malformed key means the module refuses to start. There is no plaintext fallback. - No read path. No method on any surface returns a stored key or token. A submitted key is sealed exactly like a delegated token, and outbound requests are authorized by the credential module against a placeholder.
- Isolation. Project-scoped reads, the way row-level security works. A record in another project reads as missing rather than as forbidden. Only a
SHA-256hash of an issued key reaches the database; the plaintext is returned once at creation and never stored or logged. - Hosted isolation. On our cloud the same project-scoped reads are the isolation boundary between one organization and the next, and a dedicated setup adds a node and a hostname of its own on top of it.
- Scope caps. Per-project caps on requested provider permissions, checked before the consent URL is built rather than at call time, because a granted permission is real once the user approves it.
- Gate order. Read the request, parse it, classify the mutation, evaluate policy (deny, allow, entity visibility, approval, velocity), take the lease, and only then unseal the credential. Policy is evaluated before any secret is unsealed.
- Separation of duty. Parked work is released by a different, authorized key. The requester cannot self-approve, and writing the policy document requires the approver role.
- Outbound governance. An allowlist with a reason per host, computed from connected apps, registered relays, the model endpoint and the storage backend, on a labelled transport that refuses everything else, with an audit of refusals and of hosts actually reached.
- Repeat safety. Keys derived per row and scoped per mode, so a crash and resume cannot double-send and a rehearsal does not spend the permission the real run still owes you.
- Isolated execution. Customer code in a reduce step runs with no host imports at all: no network, no clock, no filesystem.
- Audit. The record write is the unconditional last step of every action and every job step. No execution path may skip it.