# OpenWork Data Security: Architecture and Implementation in different-ai/openwork

> Discover how OpenWork secures your data with TLS encryption JWT authentication role-based access control server-side policies and vulnerability scanning Learn about its robust data security architecture and implementation

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: architecture
- Published: 2026-08-02

---

**OpenWork ensures data security through a layered defense-in-depth architecture combining TLS encryption, JWT-based authentication, role-based access control, server-side policy enforcement, and automated vulnerability scanning.**

OpenWork data security is built on a comprehensive framework designed to protect sensitive information across transport, authentication, and application layers in the different-ai/openwork repository. The platform employs multiple security mechanisms working in concert to prevent unauthorized access, data breaches, and privilege escalation attacks. This technical deep dive examines the concrete implementations, file paths, and enforcement mechanisms that secure user data.

## Transport-Level Encryption and TLS

All API traffic in OpenWork is served exclusively over TLS/SSL, preventing eavesdropping and man-in-the-middle attacks. According to the privacy policy at `ee/apps/landing/app/privacy/privacy-policy.md#L64`, sensitive information is transmitted via Secure Socket Layer (SSL) before being encrypted for persistent storage. This transport encryption ensures that data remains confidential during transit between client applications and the Den API.

## Authentication and JWT Token Management

OpenWork uses short-lived JSON Web Tokens (JWTs) stored in browser **localStorage** under the key `openwork:web:auth-token`. Every request to protected endpoints includes this token in the `Authorization` header using the Bearer scheme, as demonstrated in `evals/specs/library-view.slow.test.ts#L33`.

The following pattern shows how authenticated requests are constructed in the codebase:

```typescript
// Retrieve the stored authentication token
const token = localStorage.getItem('openwork:web:auth-token');

const response = await fetch('https://api.openwork.dev/v1/library', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json',
  },
});

if (!response.ok) throw new Error('Unauthenticated');
const data = await response.json();
console.log('Library data →', data);

```

## Role-Based Access Control (RBAC)

The platform implements a four-tier role hierarchy: **owner**, **super-admin**, **admin**, and **member**. These roles are defined in [`docs/cloud-organization-role-access.md`](https://github.com/different-ai/openwork/blob/main/docs/cloud-organization-role-access.md) and enforced at multiple levels of the stack.

Clients can query their current role via the `/v1/org/role` endpoint:

```typescript
// The /v1/org/role endpoint returns the caller's role in the current workspace
async function getMyRole() {
  const token = localStorage.getItem('openwork:web:auth-token');

  const res = await fetch('https://api.openwork.dev/v1/org/role', {
    headers: { 'Authorization': `Bearer ${token}` },
  });

  const { role } = await res.json(); // role = 'owner' | 'super-admin' | 'admin' | 'member'
  console.log(`My role is: ${role}`);
  return role;
}

```

While the Den Web UI may hide elements based on role, the true security boundary exists in **server-side route guards** that validate the caller's role before processing reads or writes. This prevents client-side bypass attempts where users might manipulate local state to access restricted features.

## Server-Side Policy Enforcement

Every API route that modifies state executes guard logic to verify authentication type, credential mode, and OAuth configuration. In `ee/apps/den-api/src/routes/org/plugin-system/store.ts#L4188`, the `validateConfiguredPluginMcpConnection` function exemplifies this enforcement:

```typescript
// Simplified excerpt from store.ts
function validateConfiguredPluginMcpConnection({ authType, connection }) {
  if (authType === 'apikey' && !connection.apiKey) {
    throw new PluginArchRouteFailure(400, 'invalid_mcp_auth',
      'authType apikey requires apiKey.');
  }
  // Additional checks for OAuth, credential mode, etc.
}

```

This server-side validation ensures that **only the declared authentication method is used** and prevents privilege escalation attacks by verifying credentials before any state changes occur.

## Secret Handling and Automated Security Review

OpenWork never commits secrets such as API keys or OAuth client secrets to the repository. Instead, the project employs **Warden**, an automated security skill located at [`.warden/skills/diff-security-review/SKILL.md`](https://github.com/different-ai/openwork/blob/main/.warden/skills/diff-security-review/SKILL.md), which scans diffs for vulnerabilities including command injection, XSS, and SSRF.

The `diff-security-review` skill acts as a gate in the development workflow, blocking pull requests that introduce new security issues before they reach the main branch.

## Vulnerability Reporting and Telemetry Limitations

For security researchers, OpenWork provides a dedicated contact at `ben@openworklabs.com` and a clear disclosure policy outlined in [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md). This ensures vulnerabilities are handled privately and patched promptly.

Operational telemetry is limited to service health metrics such as availability, error rates, and performance data. As stated in [`ee/apps/landing/app/privacy/privacy-policy.md`](https://github.com/different-ai/openwork/blob/main/ee/apps/landing/app/privacy/privacy-policy.md), telemetry explicitly **does not contain personal data**, minimizing the impact of any potential data breach.

## Summary

- **Transport encryption**: All API traffic uses TLS/SSL to prevent eavesdropping, as documented in the privacy policy at line 64.
- **JWT authentication**: Short-lived Bearer tokens stored as `openwork:web:auth-token` secure every API request, with usage patterns verified in [`library-view.slow.test.ts`](https://github.com/different-ai/openwork/blob/main/library-view.slow.test.ts).
- **RBAC enforcement**: Four-tier role system (owner, super-admin, admin, member) defined in [`cloud-organization-role-access.md`](https://github.com/different-ai/openwork/blob/main/cloud-organization-role-access.md) and enforced server-side in route guards.
- **Policy guards**: Functions like `validateConfiguredPluginMcpConnection` in [`store.ts`](https://github.com/different-ai/openwork/blob/main/store.ts) prevent unauthorized modifications by validating authentication types.
- **Automated scanning**: The Warden `diff-security-review` skill blocks security vulnerabilities in CI/CD before merging.
- **Responsible disclosure**: Security issues are reported to `ben@openworklabs.com` per [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md).

## Frequently Asked Questions

### How does OpenWork store and transmit authentication tokens?

OpenWork stores short-lived JWT tokens in the browser's localStorage under the key `openwork:web:auth-token`. Each API request includes this token in the `Authorization` header using the Bearer scheme, as implemented in `evals/specs/library-view.slow.test.ts#L33`. This pattern ensures that credentials are never transmitted in URL parameters or request bodies.

### What role hierarchy does OpenWork use for access control?

OpenWork implements a four-tier RBAC system consisting of **owner**, **super-admin**, **admin**, and **member** roles. The complete role matrix is defined in [`docs/cloud-organization-role-access.md`](https://github.com/different-ai/openwork/blob/main/docs/cloud-organization-role-access.md), with critical enforcement occurring in server-side route guards rather than relying solely on UI visibility. Clients can verify their role by querying the `/v1/org/role` endpoint.

### How does OpenWork prevent security vulnerabilities from entering the codebase?

The repository uses the **Warden** automated security skill `diff-security-review` located at [`.warden/skills/diff-security-review/SKILL.md`](https://github.com/different-ai/openwork/blob/main/.warden/skills/diff-security-review/SKILL.md). This tool scans code diffs for security issues such as command injection, XSS, and SSRF, blocking merges that introduce new vulnerabilities before they reach the main branch.

### Where should I report a security vulnerability in OpenWork?

Security issues should be reported privately to `ben@openworklabs.com` according to the disclosure policy in [`SECURITY.md`](https://github.com/different-ai/openwork/blob/main/SECURITY.md). This responsible disclosure process ensures vulnerabilities are addressed promptly before public announcement, protecting all users of the platform.