For IT and security teams

How it keeps agents in check

The detail behind the promises on the overview: the approval gate, provider failover, the tamper-evident audit chain, cited retrieval, the permission model and what actually runs.

Agent traces are kept for 180 days by default; administrators can change this. An approval nobody decides expires after 24 hours, and nothing is sent.

Provider keys and connector credentials are stored encrypted, each under its own data key and bound to its workspace. A workspace can also require that someone other than the person who asked approves, either for every approval or only for actions that delete something or cannot be undone, such as refunds and cancellations; this is off by default.

Back to the overview

Try it here

Four things that make it safe to switch on

Pick one and try it. Where a demo waits, time is compressed.

Simulated in your browser. Nothing is sent, and no account is needed.

01 · Approval gate

Simulated

It asks before it acts

Reads and drafts run freely. Anything outbound or destructive, such as gmail.send_message, slack.post_message or calendar.delete_event, parks the run until a person with approval:decide answers.

Try this

Choose who is deciding: Manager, Employee or Viewer.
Approve or reject the email, or let the deadline pass.
Watch the run carry on, or stop, because of that decision.

Deciding as

ManagerEmployeeViewer

Run · HR agent

Waiting for approval

Model call · sandbox modelDone
Reads the new hire record and plans the email
Tool · gmail.draft_messageDone
Draft written. Reads and drafts run freely.
Approval · gmail.send_messageWaiting for approval
Sending leaves the workspace, so the run parks here.
Tool · gmail.send_messageNot started
Sent through the sandbox gmail driver. Nothing left your browser.
Model call · resumeNot started
Resolves routing again and writes the run summary.

Approval requested · gmail.send_message

Send the welcome email to the new hire

HRRequested just nowReal deadline: 24 h, sped up hereWaiting for approval

Exactly what will be sent

{
  "to": "newhire@example.com",
  "subject": "Welcome to the team",
  "body": "Hello, welcome to the team."
}

Time is compressed. A real approval waits until its deadline.

Who can do what

Five roles, and you can compose your own

Roles are built from individual permissions and edited in the console. A change takes effect the next time somebody's session refreshes, not the next time the platform is deployed.

Manager

Built-in role

Runs agents, approves actions, cancels runs and tasks, and edits agents. Cannot change who may.

25 of 47 permission codes

Compare with

In plain words

Allowed: Read runs and tracesrun:read
Allowed: Read analyticsanalytics:read
Allowed: Ask questions and hand over workchat:use · task:create
Allowed: See approvalsapproval:read
Allowed: Approve or reject agent actionsapproval:decide
Allowed: Cancel runs and edit agentsrun:cancel · agent:update
Not allowed: Change who may do whatmember:invite · role:update

Console areas

10 of 11 areas

Command Map
Agents
Tasks
Approvals
Chat
Knowledge
Connectors
Model routing
Members
Audit log, not available to this role
Analytics

All 47 permission codes

Held by Manager
Not held

workspace:read, held
workspace:update, not held
workspace:delete, not held

member:read, held
member:invite, not held
member:update, not held
member:remove, not held

role:read, held
role:create, not held
role:update, not held
role:delete, not held

api_key:read, not held
api_key:manage, not held

agent:read, held
agent:create, held
agent:update, held
agent:delete, not held
agent:run, held
agent:grant_tools, not held
agent:set_model_policy, held
agent:set_approval_policy, not held

task:read, held
task:create, held
task:cancel, held

run:read, held
run:cancel, held
run:replay, not held

chat:use, held
chat:read_all, not held

approval:read, held
approval:decide, held

knowledge:read, held
knowledge:query, held
knowledge:source_manage, held

integration:read, held
integration:connect, not held
integration:disconnect, not held

provider:read, held
provider:manage, not held

budget:read, held
budget:manage, not held

audit:read, not held

analytics:read, held

settings:read, held
settings:update, not held

memory:read, held
memory:purge, not held

See it work

Under the hood

What is actually running

8 services
Independent Spring Boot services
7 + sandbox
Model providers, plus the offline sandbox model
20 connectors
MCP servers: all 20 connect live once an administrator adds a token or signs in with the provider, and use practice data until then
47 permission codes
Composed into roles
5 built-in roles
Plus any roles you compose

Model providers

OpenRouter
Groq
NVIDIA NIM
Google Gemini
AWS Bedrock
Anthropic
OpenAI
Sandbox

Connect live

GitHub
Slack
Notion
Linear
HubSpot
Webhook
Jira
Confluence
Asana
Zendesk
Stripe
Zoom
Twilio
Gmail
Google Calendar
Google Drive
Google Sheets
Microsoft Outlook
Microsoft Teams
Salesforce

What it does not do

Stated plainly, so nothing here is a surprise later

Agents are not autonomous. They stop at every outbound or destructive action and wait for a person.
Answers are only as good as the documents you connect. With nothing indexed, an agent will tell you it cannot answer.
The offline model is a placeholder. It returns sensible-looking text so the platform can be tried, and says so wherever it answers.
Each connector reaches a real account only once an administrator adds its access token or signs in with the provider (GitHub, Slack, Notion, Linear, HubSpot, webhooks, Jira, Confluence, Asana, Zendesk, Stripe, Zoom, Twilio, Gmail, Google Calendar, Google Drive, Google Sheets, Microsoft Outlook, Microsoft Teams and Salesforce). Until then agents work with practice data and nothing is sent.

Look around

Try it on the sandbox model

Runs on an offline sandbox model out of the box, so no API key is needed. Live providers are one stored key, one enabled provider and a routing policy away.

See it work Create your workspace