Skip to main content

​
Overview

Jinba Toolbox implements a security model centered on organization-based isolation. Every resource — toolsets, tools, versions, runs, API keys, and webhooks — belongs to an organization and is protected by role-based access control (RBAC) and authenticated sessions or API keys.

​
Authentication

Jinba Toolbox supports two authentication methods, each designed for a different access pattern:

Session-Based (Web)

Used by the web console. Users sign in through JinbaAuth (the shared Jinba sign-in service, including tenant SSO); the console sends a JinbaAuth JWT to the API, which verifies it and resolves the user’s organization role from JinbaAuth.
  • For human users managing toolsets
  • Required for testing draft code, publishing versions and creating API keys
  • Role-based access to organization resources

API Key (Programmatic)

Used by the SDK, AI agents, and external integrations. Passed as a Bearer token.
  • Authorization: Bearer jtb_xxxxxxxxxxxx
  • For automated and programmatic access
  • Scoped to a single organization, Member-level permissions, bound to one ToolSet environment

​
API Key Management

API keys are scoped to an organization and track their issuer:
Key properties:
  • No expiration — keys remain valid until manually deleted.
  • Hashed at rest — only a SHA-256 hash is used for verification; an encrypted copy allows the full key to be revealed again from the console.
  • Last-used timestamp is recorded for each key.
  • Issuer tracking — the member who created the key is recorded.
  • Environment binding — each key selects the ToolSet environment (variables and active version) used by its executions.
If the member who issued a key leaves the organization, the key remains active to avoid breaking integrations. The console displays an “Issuer is no longer a member” warning, and an Owner or Admin can delete the key and issue a new one.

​
API Key Endpoints

​
Role-Based Access Control (RBAC)

​
Role Hierarchy

Jinba Toolbox defines roles at two levels:
Organization roles are assigned in JinbaAuth and read by Toolbox on every request.

​
Organization Roles

​
Permission Matrix

Organization and member management (rename, delete, invite, change roles, remove) is performed in JinbaAuth; the corresponding Toolbox API routes return 403.

​
Role Rules

  • Roles and ownership are managed in JinbaAuth.
  • Members can create and delete their own API keys and can see all keys of the organization, but cannot delete keys created by others.
  • API keys act as Member regardless of the issuer’s role.

​
Organization-Based Isolation

Every resource in Jinba Toolbox is scoped to an organization. The isolation is enforced in the API server: for every organization-scoped request it resolves the caller’s membership (session) or verifies that the API key belongs to the requested organization, and only then queries that organization’s resources. Requests from non-members are answered with 404, and permission failures with 403. Run records keep both the caller and the provider organization. When another organization executes one of your public tools, you can see the run’s status and timing but not its input, output or logs; only the caller organization can.

​
Run Logging

Tool executions are tracked in run records with the input, output, error and captured stdout/stderr. Credit consumption is recorded as credit transactions that the Credits page lists.

​
Sandbox Isolation

Tool execution occurs in isolated sandbox environments (E2B or Daytona). Each execution runs in a fresh sandbox instance with:
  • Process isolation — each sandbox is a separate container or VM.
  • Egress control — when the egress proxy is enabled for your organization (a JinbaAuth organization setting), E2B sandboxes are hardened before user code runs and route outbound traffic through the Jinba egress proxy; the proxy credential is masked out of anything returned to the caller. Without that setting the sandbox keeps the provider’s default outbound network access.
  • Configurable environment variables — secrets are injected per toolset environment, not shared across toolsets; secret values are stored encrypted.
  • Automatic cleanup — sandboxes are killed as soon as execution completes or times out.

​
Best Practices

  • Use separate API keys for different environments (production, staging, CI/CD) to limit blast radius if a key is compromised.
  • Audit API key usage — review the last-used timestamp regularly and delete keys that are no longer needed.
  • Assign the least-privilege role — use Member for developers who only need to create and edit tools.
  • Review run history periodically to detect unexpected usage patterns.
  • Do not share API keys between organizations — each key is scoped to a single organization.
  • REST API — Authentication details and endpoint reference
  • Webhooks — Event notification security (signature verification)
  • Sandbox Providers — Execution environment isolation