Security

Nenjo protects sensitive workspace content with keys that are created and used on trusted clients. The server stores encrypted payloads and the metadata required to route work, enforce permissions, and help trusted devices regain access.

How Nenjo protects your workspace

Several layers work together so that connecting to the platform is never the same as being able to read or change your work:

• Authentication — every worker and integration connects with an organization API key. No valid key, no connection.
• Authorization — what an authenticated caller may do is bounded by organization membership and scopes. Scopes decide which resources and platform tools are reachable.
• Isolation & outbound connectivity — each organization has its own dedicated event bus. Your worker connects out to that bus with an org API key and keeps the subscription open. Work is delivered over that channel — you don't open inbound ports or expose your harness to the public internet for remote access from the dashboard.
• Admin-gated access — trusted devices and workers must be approved by an owner or admin before they receive the keys needed to decrypt protected content. Connecting is not the same as being trusted.
• Encryption — sensitive content is encrypted on trusted clients before it reaches the platform, so the server only ever holds ciphertext for it.

Authorization and encryption are independent: scopes decide whether you can reach a resource, while encryption keys decide whether you can read its protected content. A caller needs both.

Security model

There are two encryption scopes in use:

The server does not need plaintext for encrypted content. It stores the encrypted payload, object type, object ID, key version, nonce, and ciphertext. Resource metadata is still stored separately so the app can show lists, search, enforce scopes, and route work.

Trusted devices

A trusted device is a browser or client that has local encryption material for the signed-in user. During secure workspace setup, the device creates the user's local content key material, approval signing key, and recovery bundle.

For organization content, a trusted device also needs access to the active organization content key. When a device has that access, it can decrypt org-scoped content such as Library documents, task content, agent prompts, and context blocks.

If a user signs in from a device that does not have org content access, the device can request access. An owner or admin with access can approve that request by wrapping the organization content key for the requesting device.

Recovery phrase

The recovery phrase protects the user's encrypted recovery bundle. It is shown during secure workspace setup and must be backed up outside Nenjo.

Recovery restores the user's account encryption material. For organization content, owner and admin roles may also receive a recovery-wrapped organization content key grant. That grant lets a recovered user regain org content access and then trust the new device.

If the recovery phrase is lost, Nenjo cannot reconstruct the user's local recovery material. A team admin may still be able to approve org content access for a new device, but user-scoped encrypted chat history depends on the user's recovery path.

Workers

Workers need explicit enrollment before they can run work for an organization. The onboarding flow creates a worker API key, starts the worker, then approves the worker so it can receive the encrypted access material it needs.

Once approved, your harness (nenjo run) maintains an outbound connection to your organization's event bus. Chat, tasks, schedules, and live resource updates are pushed to the worker over that bus — the platform does not call into your network. You don't need a public URL, reverse proxy, or open firewall rules so the dashboard can reach your agents.

The connection stays up while the worker runs. If the bus or backend is briefly unavailable, the worker retries with backoff until it can reconnect.

Workers do not get general plaintext access just because they exist. They receive scoped credentials and wrapped keys needed for the work they are approved to perform. Org-scoped encrypted payloads must match the enrolled organization before the worker can decrypt them.

Connecting with an API key is not the same as being trusted: an unapproved worker can reach the bus, but it cannot decrypt protected content until an owner or admin approves it.

What remains visible

Some data is intentionally not encrypted because Nenjo needs it to operate:

• Organization membership, roles, scopes, invites, and access-request state
• Project, agent, routine, model, worker, and API key metadata
• Resource names, descriptions, paths, IDs, timestamps, tags, status, and assignments
• Routine definitions and model settings
• Library document metadata, task titles, execution run metadata, and activity records

This metadata is protected by authentication, organization membership, and scopes. It is not protected by content encryption.

Current limits

• There is no automatic organization key rotation today.
• Key-version fields are present so encrypted payloads can identify which key version was used.
• Removing a member or worker revokes future access grants, but already-decrypted local content is outside server control.
• Metadata is not end-to-end encrypted.