Governance philosophy
Atlas lets intelligence work independently within authority you define, and makes every consequential outcome accountable.
You can delegate bounded authority for routine actions, and Atlas works within those limits without asking at every step. Delegation is not a bypass: it is scoped, recorded, can expire or be revoked, and never covers more than you granted.
Much of this page describes our rules for Atlas, which are still being built. Every item is labeled: In use internally, Implemented, Demonstrated, Planned or Example.
Governance is what lets Atlas do real work on its own without anyone losing track of who allowed it, who checked it and why it was accepted. The colors on these four cards mark concepts, not status.
Authority starts with a person. Atlas acts within what was granted; anything beyond it comes back to a person.
Atlas's approval step records whether a person approved, approval was delegated, or a bypass was used. It never assumes a person approved just because the work went ahead.
Higher-risk changes are checked by a reviewer that didn't build them, from a different provider, on the exact version under review.
A model saying it's finished isn't evidence: "verified" has to come from a machine check or a named person's sign-off. A failed check is recorded as failed, never reported as green.
Each agent has a defined role and a list of commands it's allowed to run. A request for more is saved as a record: what Atlas wants to do, what happens if you say no, and what you decided.
A principal, the person or organization the work is for, grants Atlas bounded authority for a mission. Inside that boundary Atlas keeps working. At the boundary it stops and asks.
A grant names what Atlas may do, for which mission, and until when. Routine work such as planning, drafting, analysis and retrying an internal step goes ahead and is recorded. Recording is not asking.
Demonstrated Scoped grants in Atlas's core, in tests.
Committing money, sending something outside Atlas or contacting a person, deploying, deleting or other hard-to-reverse actions, changing permissions, and anything beyond the mission's authority, privacy or budget envelope.
Demonstrated Atlas's stop-and-ask rule, in tests.
A grant can expire, and it can be revoked. An expired or revoked grant authorizes nothing, and a clock that runs behind can only narrow what is allowed.
Demonstrated In tests of Atlas's core.
If authority is missing, unclear or can't be read, the action doesn't run. Atlas asks a specific question instead of guessing. An unpriced spend is a question, not an approval.
Demonstrated In tests of Atlas's core.
You approve the plan. Atlas does the work within it, and the result comes back to you to accept. Nothing merges or ships without your decision.
You delegate the merge decision. Atlas merges only when every required check passes and the reviewed version is still the latest. A hold or failure stops it.
Implemented Both modes exist in Atlas's code; Coordinator's merge step is built but not yet accepted for live use. Planned Granting and revoking authority from Atlas's own screens.
Reading a file isn't deleting data. Our rules for Atlas scale scrutiny to the consequence of the action, not to how important the system feels. Missing authority stops the action at every tier.
Proceeds within the grant and is recorded.
Needs authority that covers it; otherwise Atlas stops and asks.
Needs explicit sign-off and the strongest independent review.
In use internally Many changes to Atlas cite an assurance tier, and higher tiers require an independent reviewer on the exact version. The detailed rules aren't published. Planned The same tiers applied to customer missions.
A finished mission should leave an inspectable record of why its result was accepted, or why it wasn't. Step through an example receipt for a mission that stopped because a spending limit was missing.
Refresh the weekly price summary
A person grants bounded authority for one mission.
The work runs inside the grant until it reaches the edge.
A qualified verifier checks the resulting artifact and acceptance criteria.
A person decides what happens next.
Held for approval
Example only. No live mission or independent verification is represented.
Provider separation alone doesn't make a reviewer independent. Here is how review is kept honest, and which parts are a process people follow today versus a control Atlas's code enforces.
If a check fails or the reviewer holds the change, it goes back for repair and is reviewed again.
These are the rules Atlas is being built to follow. They describe intent, not commitments. For what we actually do with your data today, read the Privacy notice.
Planned All of the above, as product controls.
There's no separate security page yet. Report a security concern to dominick@atlasai.my.
Each status has a strict meaning. These colors mark status only.
Nearly every change merged through the Atlas pull request process runs through CI. Higher-risk changes are reviewed by a separate AI agent from a different provider; sometimes one review covers several changes together.
Many changes to Atlas cite an assurance tier that sets how much independent review they need.
A defined role and a list of allowed commands for each agent.
Reviews and holds name the exact version; failed checks and holds stay on the record.
Two authority modes, Plan and accept and Coordinator. The Coordinator merge step isn't yet accepted for live use.
Approval records that tell a person's approval apart from delegated approval or a bypass.
Approval requests saved as records: approve once, up to a spending limit, for the rest of the mission, or deny.
A limit on repair attempts, after which the decision goes to a person.
Scoped grants that expire, can be revoked, and authorize nothing once they do.
Stopping to ask before spending, sending outside Atlas, deleting, or when essential information is missing.
Model calls that are routed, priced and checked against limits before anything is sent.
Rejecting stale reviews and same-provider reviewers.
Atlas enforcing these controls in live operation, and the same rules for customer missions.
Atlas keeping each mission's governance receipt itself.
Granting authority, approving and accepting inside Atlas's own screens.
Data, credential and provider controls; safe cancellation and recovery of interrupted missions.
Atlas holds no third-party certifications. This page describes how Atlas governs AI work. It isn't a company governance, security or data policy.
This page is a policy, not marketing copy. It has an owner, a revision date and a change history.
To report a concern, contest an action Atlas took, or ask for a review, use the contact page or email dominick@atlasai.my.
Design references: the NIST AI Risk Management Framework and OWASP guidance on limiting agent permissions and autonomy. We use them to shape our rules. This isn't a claim of compliance or certification.