SharedOS Cloud
Your application runs SharedOS and enforces permissions. SharedOS Cloud shows the decision events your application sends.
The console
Every decision, in one place
try the tabsAllowed runs two orders of magnitude above the rest, so refusals sit flat against the floor until you rescale.
01The ideas
Six ideas carry the whole thing
read these first01
Messages coordinate, grants authorize.
Sending an agent a message gives it no access. Every agent works with the grants the owner issued to it, never with the sender's.
02
Deny by default.
No matching grant means denied. There is no admin agent, no wildcard identity, no setting to forget. Only the absence of a grant.
03
Three gates on every tool.
A tool is usable only if it is registered, its namespace is switched on for the context, and a grant covers the exact resource and action. Switching a namespace on grants nothing.
04
An agent can't see what it can't use.
The catalog is filtered by grant before the model sees it, and each call is authorized again from its real arguments, so rewriting a path cannot reach outside the grant.
05
One bounded turn at a time.
Each request runs one agent for one turn, with step, tool-call and time limits. What runs next, and when the product is done, is your loop's decision.
06
Denied is an answer, not an error.
A refused call comes back as a successful response with status: denied and a reason. HTTP 403 means the request never reached the kernel at all.
02The layout
Where each thing lives
figure 1Your product keeps its users, its loop and its opinions about what to do next. The owner issues grants. Your application runs the SharedOS kernel and turn envelope, checking each call locally. The model or CLI sits in the seat and never sees a grant.
03The grants
Design the team as a map of who may touch what
figure 2Memory is files. Anything an agent should remember, share, or be kept away from is a path. So lay the file tree out around the permissions you want, then read the grants straight off the map: one grant per subtree per role. Private working notes are one folder per agent. Handoff is a folder another agent may read. Finance is not on anyone's row: it simply is not granted.
Three grants are not about files, and every team needs them: an execution grant so an agent may be run at all, a messaging grant per sender→recipient pair, and an escalation grant for the agents allowed to stop and ask a human.
04The check
Three gates on every call
figure 3Being able to see a tool is not permission to use it. The third gate is re-derived from the arguments the agent actually sent, so a model that rewrites the path in its own call still cannot reach outside the grant.
05The loop
A cycle of work
figure 4SharedOS never decides the product is done. Your loop steps the ring: run the lead, read the plan it wrote, run the workers, run the reviewer, run the lead again. One trace id per cycle keeps the audit trail grouped; a fresh execution id per attempt keeps replays honest.
Two exits. When the lead's plan says done, you stop. When an agent with the escalation grant hits something it may not do, the turn ends escalated, nothing is granted, and the request names the exact authority it wanted, so the owner can say yes with one grant and you re-run the task.
06The seat
Three ways to put an agent in the seat
figure 5Which model or framework runs a turn is a deployment choice, never something a request can pick. All three shapes pass through the same kernel, so the grants, the gates and the audit trail are identical.
escalated outcome. The other two still re-authorize and audit every call.07The trail
What you get back
illustrativeEvery turn returns a status (succeeded, denied, failed, cancelled or escalated), the agent's output, and an ordered list of events: what the agent tried, what was allowed, what was refused and why. A turn can succeed and still contain denied calls. Count those; they are your earliest signal that a grant is too narrow or an agent is probing.
Behind the response, every decision reaches the audit trail with the actor, the authority, the exact resource and action, the purpose, the reason code, and for a refusal the list of grants that were considered and the first condition each one failed. Two hashes travel with each turn, the catalog the agent saw and the authority set it was judged against, so two runs are comparable only when both match.
08The walkthrough
How it works for one product
guided tour · 4 stepsAtlas is an internal launch. Maya owns it; two agents do the work. Step through how it comes together in an application running SharedOS, then add more agents the same way.
09The split
Before you start
the whole split- The kernel and the one-turn envelope
- Your grant store, files, and tool providers
- Your model or CLI and its credentials
- Your orchestration loop and audit sink
- Decision events sent by your host
- Trails behind allowed and refused calls
- Decision trends across environments
- Decision history beyond a log tail
- Run and verify the kernel locally first
- Discuss design-partner access with the team
- Confirm the supported event integration
- Keep enforcement in your application
The host owns the world. SharedOS guards the turn. Begin with Get Started. If you expose your kernel to another process, use the self-hosted HTTP guide. Your host supplies authority from its trusted store; enforcement remains local. The console demo is illustrative. Confirm the supported event integration with the preview team.