Approvals, control, and your data

An intelligence that does real work needs real safeguards. The more Gwen can do, the more it matters that you decide what actually happens in the outside world.

Gwen's model is simple: it can think, plan, and prepare freely, but it asks before it acts irreversibly. You get the speed of an agent that does the work and the safety of staying in the loop on anything that matters.

Gwen does not stop to ask permission for the safe, reversible parts of work. It can read the context available to it, scope a job, draft text, generate content, summarize information, analyze data, and prepare artifacts — all without taking an external action.

This is most of the work, and it is where you want Gwen moving fast. Nothing here leaves your workspace or touches the outside world.

Anything with real-world consequences pauses for your approval or follows a policy you have set. That includes:

• Sending messages or emails to anyone outside the workspace.
• Publishing pages or content to the public.
• Purchases, payments, and anything that spends money beyond the work itself.
• Pushing code, deploying, or changing a live system.
• Changing or deleting records, files, or data.
• Other sensitive or hard-to-reverse actions.

The rule of thumb: if it cannot easily be undone or it is visible outside your workspace, Gwen asks first.

Approvals are meant to protect you, not nag you. For routine, low-risk steps you can set policies so work flows without a click every time; for high-stakes actions, Gwen surfaces exactly what it intends to do — the message, the recipients, the change — before it happens.

The goal is the right amount of control: full oversight where it counts, no busywork where it does not.

Every mission records what Gwen did, what context it used, which tools it attempted, which approvals are waiting, and what it delivered.

This ledger is both your window and your audit trail. You can see and steer work in progress, and you have a durable record of how any result was produced — which matters for trust, for teams, and for anything you need to stand behind later.

The context you give Gwen — your documents, records, decisions, and memory — belongs to you. It exists to do your work, not to become someone else's training data or a product you did not ask for.

You can inspect what Gwen knows, correct it, and remove it. Memory and knowledge are things you control, not a black box accumulating assumptions you cannot see.

Gwen is multi-tenant by design: each workspace's data, memory, connections, and missions are isolated from every other workspace. Work done for one company is not visible to another.

The same boundary separates a company workspace from personal context. Shared company knowledge stays in the workspace; personal memory stays personal. Isolation is enforced as a core property of the system, not left to convention.

When you connect a tool — email, a CRM, a drive, a repository — that connection is scoped to your workspace and used only when a job needs it and only for what you authorized.

Gwen tells you in plain language when a job needs access you have not granted, rather than reaching for it silently. You grant access deliberately, and you can review or revoke it.

Work that runs code or tools runs in isolated runtimes, so a build or a task cannot reach beyond its sandbox. Spend is bounded by your Work Budget and your top-up rules, so Gwen cannot run up cost beyond what you have allowed.

Validation runs before results are trusted, and destructive operations are checked. Capability is paired with containment at every layer.

As teams grow, control needs more structure. Gwen is designed to support configurable approval policies, role separation, and governance for organizations running many missions across many people.

That means the same approval-and-audit foundation that protects an individual scales into something an enterprise can hold accountable — who can approve what, what is logged, and how sensitive actions are governed.