Who may do what
Accounts, roles and allowed models decide what a person can start. Credentials are collected in secure forms and bound explicitly to Connectors.
- Role resolved
- Allowed models applied
- Connector binding verified
Enterprise · Security & Deployment
Every run is sandboxed, recorded and policy-checked. Deploy in our cloud, a dedicated environment or your own.
Usage & audit · one row per run, sensitive data masked at the gateway
Sandboxed
Every run executes in a disposable sandbox that is destroyed afterwards.
Recorded
Every task, scheduled or not, leaves an immutable Run Record.
Policy-checked
Shieldon inspects every model call before it leaves the company.
Layered model
A request passes through the workplace, the gateway and the agent runtime. Each layer decides something different, and each leaves its own record.
Accounts, roles and allowed models decide what a person can start. Credentials are collected in secure forms and bound explicitly to Connectors.
Every model call passes the gateway. Policies detect and mask sensitive data, enforce the allowed model and log the request, the tokens and the outcome.
The run executes in a disposable sandbox with scoped mounts. Every tool call, checkpoint and result lands in an ordered event stream you can replay.
Execution isolation
Agents never touch an employee's machine or a shared server. Each run gets its own container, exactly the mounts it needs, and a record of every step.
disposable · created per run · destroyed after
Event ledger · one run, in order, replayable
Created for the run, destroyed after it. Nothing persists unless it was written to the workspace on purpose.
Skills, Works, Connectors, Apps and attachments are projected under /workspace/resources, read-only or writable per path.
Change of plan? Cancel the run. Running processes stop with it, and the record shows exactly where it stopped.
Context checkpoints mark safe points in a long run, so recovery resumes from known state instead of starting over.
Identity & access
Access is defined in the Admin Console and enforced by the runtime. There is no side door: what a role does not allow, an agent cannot do on that person's behalf.
People sign in as themselves. Roles carry what they may see in Explore and which models they may use.
A role's model list is intersected with the models the company has configured. Empty means none, and nothing is substituted silently.
Open registration only for the email domains you allow. Everyone else is invited by an administrator.
Each person holds a single Connection per Connector, callable only after Test Connection passes.
Skills declare the Connectors they need and the person binds one on purpose. An invalid binding puts the run into Awaiting Authorization.
Administrators can lock a Skill, Work or Connector so its configuration cannot be changed by the people using it.
Finance analyst
12 members · Visible in Explore
Allowed models
roles ∪ → ∩ configured models · no silent substitution
Explore · resource statuses
Admin Console · Roles · allowed models resolve per person
Credentials & data
Keys and tokens are entered once, in a secure form, and delivered straight into the sandbox environment. The agent uses them. It never reads them.
ERP ledger
Connector · Connection for a.chen
delivered to the sandbox environment · never to the model
Connector configuration · values masked after save, tested before use
Sensitive values are entered in a dedicated form and never displayed again. Rotating a value means entering a new one.
Values an administrator sets appear as masked fields marked Configured by Admin. People use them without ever seeing them.
Credentials are refused in conversation, kept out of Memory and never written to resource files. The runtime is told, not the model.
A run that completes is not a job that is done. The owner verifies the content and the state of the destination system before signing off.
Audit & observability
Every task, every model call and every output can be traced back to a person, a run and a message. Administrators see the whole picture; people see their own.
Each run, including every scheduled trigger, produces an immutable record with its state, its tools and its usage.
Files and URLs are collected per task. Back to Original Message opens the request that produced them.
Back to Original Message
Tasks, tokens and model usage across teams in the Admin Console, next to credit consumption per plan.
Explore updates, scheduled-task results and administrator messages reach people where they already work.
Deployment options
The same product, three ways to host it. Models are configured centrally in every option, including the models you host yourself.
Multi-tenant and operated by us. Workspaces, files and runs are isolated per account from day one.
A single-tenant deployment operated by us, with its own AOS.work and Runtime hosts inside its own network boundary.
Installed in your cloud account or data centre and operated by your team, with our delivery team alongside.
Connect the providers you already trust, or models you host yourself. Each model is configured once, must pass Test connection, and is granted per role.
AOS.work and the Runtime run on separate hosts, sized for your expected load and verified under load before go-live, with success rate and latency percentiles recorded.
Security checklist
The short version, for the people who have to sign off.
Security review pack available on request.
Book a demo and we will set up a workspace with your knowledge, your standards and your guardrails.
Built on Basil Harness · Protected by Shieldon