AI employees that ask before they act.

Agents read freely. They propose writes. People approve them.

When in doubt, an action is treated as the stricter kind — if either our classifier or the tool vendor says an action is destructive, it is blocked.

• Every external write waits for a person
• Destructive actions cannot even be proposed
• Unknown actions fail safe, not open

Approve this once, for this session, or always — for exactly this.

An approval covers the exact action, on the exact resource, in the exact project you saw. “Always allow emailing acme.com” never becomes “always allow emailing anyone”. Session approvals end with the conversation. And a standing approval can never unlock something policy has blocked.

• Edit before you approvechange a recipient or cut a paragraph, then approve. Reviewers can change the values — never swap the action, add fields the agent didn’t propose, or change what kind of data a field holds
• Approve where you already arein Monitor, in the product, or with the Approve / Reject buttons in Slack
• Claimed oncea double-click or two teammates approving at the same moment still runs the action exactly once

Only a person, in the moment, can say yes.

Every agent turn knows where its authority came from — a person, a schedule, a webhook, another agent, or a retry. Only a person who asked for it in that turn can approve an action. A job someone set up six weeks ago does not inherit their authority today, and anything that forgets to say where it came from is treated as not a person.

• Meeting speech is treated the same way: anything decided on a call waits for a human before it touches your tools — because a forwarded invite link can’t tell you who is really in the room

Company policy first. Teams and projects can tighten it — never loosen it.

Policy is evaluated in layers — your company’s settings, then any team or project rule, then your own unbreakable playbook rules — and the strictest answer always wins. A project can turn “allowed” into “needs approval”. Nothing can turn “needs approval” back into “allowed”.

• Your playbooks become enforcementmark a company rule such as “legal approves any contract before it is sent” as never-override and name the action it governs, and it is checked before the action runs
• Knowledge can only tightenbecause company memory reads inbound email, company knowledge can only ever tighten policy, never relax it

Not just what ran. What was attempted, denied and blocked.

Every external action an agent attempts leaves a permanent record — including the ones policy denied and the ones a person rejected. Each record names who asked, who approved, whose connected account ran it, what it was for in the agent’s own words, and what happened. In an incident, “what did the agent try to do?” is the question that matters — so it always has an answer.

• Attempts, denials and rejections are all recorded
• Who asked, who approved and whose account ran it — on every action
• Connection owners can see everything done through their accounts
• Retries and re-fired jobs act once, never twice

Share the ability to use an account — never the account.

• We never hold your OAuth tokensthey are vaulted by our integration provider; we store an opaque reference that never reaches the browser
• Owners decide who can use a connectionjust themselves, named teammates, or the whole company. Admins set the ceiling, and tightening it applies to existing connections too
• Enforced twicea connection you can’t use contributes no tools to your agent at all — and even if that check failed, the provider independently refuses to run it for you
• Approval cards name the accountbefore the action, when it will run on someone else’s connection
• Removing someone really removes themthey lose access everywhere, and the connections they owned are revoked
• Connected is not ingestednothing from a tool enters company memory until you say yes, and choose which labels, channels, folders or files

Company, team, project, personal — and nothing leaks between them.

Every company’s data is separated on every database query — one company can never read another’s memory. Inside your company, knowledge, files, skills, connectors, apps and automations each belong to a scope. Personal notes are never shared implicitly. Only someone who manages a scope can share from it — being given access never lets you pass it on — and revoking access works on the very next request, not at the end of a session.

• Rolesadmins, members and read-only viewers. Viewers can see, never change
• Joining by email domain is safe by designpublic providers like Gmail can never be approved as “everyone here works for us”, checked when the domain is added and again at every join

An email that says “ignore your instructions” is just an email.

Anyone can email your company, so everything arriving from outside — messages, fetched pages, tool results, meeting speech — is screened for known injection attacks before it is stored, and fenced off as data, never instructions, whenever an agent reads it. Company memory weighs what you said above what a stranger sent, and a “fact” that reads like a command is never written.

• We test against a standing red-team battery of known attack patterns — and we say plainly that pattern screening catches known attacks, not every rephrasing. That is why the controls that matter are gates, not filters

AI-written code never runs next to your data.

• Every project gets its own sandboxkernel-level isolation (gVisor), resource limits, and no access to cluster credentials
• Default-deny networkingsandboxes can’t reach each other, the cloud metadata service or private networks — only the public internet they need
• Each sandbox has its own keyso one sandbox can only ever open itself
• Mission scriptsrun in a separate process with no environment secrets, no file system, no child processes and no network of their own
• Server-side fetchesof any URL an agent supplies are checked on every redirect, so a link can’t be bounced into our internal network

The unglamorous controls, done properly.

• Signing out ends that session on the servera stolen session token stops working, not just the cookie in your browser. “Sign out everywhere” is a separate button
• Stored credentials are encryptedAES-256-GCM, and every purpose — sessions, stored secrets, invite links, channel tokens — uses its own derived key
• Passwordshashed with bcrypt, and sign-in takes the same time whether or not an account exists, so the login page can’t be used to discover who your users are
• Email and reset linkssingle-use and stored only as hashes
• Shared rate limitson sign-in, sign-up and password reset, enforced across every server
• Cross-site request forgery protectionon every state-changing request, plus HSTS, a Content-Security-Policy and clickjacking protection on every page
• Webhook replaysrecognised and ignored, per company

Hard spend limits. Your choice of AI providers.

Usage is capped per company over rolling 24-hour and 30-day windows. When a cap is reached, work stops with a clear message naming which limit it hit — never silent overage billing. And if your company has a vendor or data-residency policy, we can restrict which AI providers are allowed near your data, from Google, Anthropic, OpenAI and Groq.

Every decision waiting on a person, in one queue.

Action approvals, mission approvals, company-knowledge confirmations, spend limits, model-policy requests and team invites all arrive in Monitor — and stay on their own page too. Nobody has to know which screen a decision is hiding on. And nothing is ever approved because nobody answered: silence is never consent.