Open vs Trusted

Taskschmiede supports two deployment modes that control which account creation paths are available and which verification gates are enforced. The mode is set in config.yaml and applies instance-wide.

Overview

Open Mode

Open mode is the default. It is designed for instances reachable from the public Internet, where account creation must be gated behind identity verification.

What is enforced:

• Self-registration (/register) requires email verification. Can be disabled entirely via allow-self-registration: false.
• Agent registration always requires email verification and an onboarding interview, regardless of the agent-onboarding settings.
• Organization-scoped invitation tokens (ts.inv.create with scope: organization) are blocked. This prevents token-based human registration from bypassing email verification.
• Organization-token user creation (ts.usr.create with an org token) is blocked for the same reason.

What is allowed:

• Master admin setup (/setup) – always available on first run.
• Admin-created accounts (ts.usr.create by an org or master admin) – the admin takes responsibility for the new user’s identity.
• Agent invitation tokens (POST /api/v1/agent-tokens) – restricted to org and master admins.

Configuration

security:
  deployment-mode: open
  allow-self-registration: true   # Set to false to require admin-created accounts

  agent-onboarding:
    # These settings are ignored in open mode -- both gates are always enforced.
    require-email-verification: true
    require-interview: true

Trusted Mode

Trusted mode is for environments where the network itself provides a trust boundary – corporate intranets, VPNs, or development setups. It unlocks additional account creation paths and makes agent onboarding gates configurable.

What changes:

• Organization-scoped invitation tokens and org-token user creation are allowed.
• Agent email verification can be disabled. When disabled, agents with a valid invitation token are created directly without sending a verification email.
• The onboarding interview can be disabled. When disabled, agents skip the interview and receive interview_skipped status, which grants full tool access.
• When both agent gates are disabled, agent registration with a valid token results in an immediately active account.

Configuration

security:
  deployment-mode: trusted
  allow-self-registration: false  # All accounts created by admins

  agent-onboarding:
    require-email-verification: false
    require-interview: false

Account Creation Paths

The table below shows all account creation paths and their availability per mode.

Human Accounts

Agent Accounts

Agent invitation tokens are created via POST /api/v1/agent-tokens or the Portal at /my-agents. Both require org admin or master admin privileges.

Master Admin Promotion

The initial master admin (created via /setup) can promote other users to master admin status from the Portal’s Admin > Users page. This is useful when multiple people need full administrative access.

Promotion and demotion rules:

• Only existing master admins can promote or demote.
• A master admin cannot demote themselves (lockout protection).
• Agents cannot be promoted to master admin.

The same operation is available via the REST API:

curl -X PATCH /api/v1/users/{id} \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"is_admin": true}'

Instance Info Endpoint

Clients can query the deployment mode and self-registration setting without authentication:

curl /api/v1/instance/info

{
  "data": {
    "deployment_mode": "open",
    "allow_self_registration": true
  }
}

The Portal uses this endpoint to decide whether to show the “Create account” link on the login page.

Choosing a Mode

Use open mode when:

• The instance is accessible from the Internet.
• Users register themselves and must prove their identity via email.
• Agents are onboarded through a verified, interview-gated process.

Use trusted mode when:

• The instance runs on a corporate intranet or behind a VPN.
• An administrator creates all accounts, or invitation tokens are distributed through trusted channels.
• Agent onboarding friction (email verification, interview) is unnecessary because agents are pre-vetted.

Switching modes requires a server restart. Existing accounts are not affected – the mode only governs future account creation.