Documenso Enterprise RbacSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: documenso-enterprise-rbac
description: 'Configure Documenso enterprise role-based access control and team management.

  Use when implementing team permissions, configuring organizational roles,

  or setting up enterprise access controls.

  Trigger with phrases like "documenso RBAC", "documenso teams",

  "documenso permissions", "documenso enterprise", "documenso roles".

  '
allowed-tools: Read, Write, Edit
version: 1.14.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags:
- saas
- documenso
- rbac
compatibility: Designed for Claude Code
---
# Documenso Enterprise RBAC

## Output

- A least-privilege role/project configuration with named owners, access-review evidence, and a tested revocation path.
- Verified separation between development/staging/production document and signer permissions.

## Examples

Grant a development service account only the document action and project it needs, validate it with a synthetic document, and confirm it cannot view or sign production documents. Record the owner and review date; revoke overly broad access and correct group mapping before proceeding.

## Overview

Configure team-based access control and enterprise features in Documenso. The Team plan enables multi-user collaboration with shared documents. Enterprise adds SSO (OIDC), audit logging, and organization-level management.

## Prerequisites

- Documenso Team or Enterprise plan
- Understanding of RBAC concepts
- For SSO: OIDC-compatible identity provider (Okta, Azure AD, Google Workspace, Auth0)

## Documenso Team Model

```
Organization
├── Team A
│   ├── Owner (full control)
│   ├── Admin (manage members, settings)
│   └── Member (create, view, sign team documents)
├── Team B
│   └── ...
└── Personal Accounts (separate from teams)
```

**Key concepts:**

- Teams are separate from personal accounts -- team documents are owned by the team
- Team API keys access all team documents; personal keys only access personal documents
- Each team member can have Owner, Admin, or Member role
- Unlimited teams and users on Team/Enterprise plans (early adopter pricing)

## Instructions

### Step 1: Team API Key Scoping

```typescript
import { Documenso } from "@documenso/sdk-typescript";

// Personal key: only YOUR documents
const personalClient = new Documenso({
  apiKey: process.env.DOCUMENSO_PERSONAL_KEY!,
});

// Team key: all documents in the team
const teamClient = new Documenso({
  apiKey: process.env.DOCUMENSO_TEAM_KEY!,
});

// Common mistake: using personal key for team operations
// Results in 403 Forbidden on team resources
```

### Step 2: Application-Level RBAC

Documenso handles team membership internally. For finer-grained control in your app, implement an authorization layer:

```typescript
// src/auth/documenso-rbac.ts
type Role = "viewer" | "editor" | "admin" | "owner";

interface TeamMember {
  userId: string;
  teamId: string;
  role: Role;
}

const PERMISSIONS: Record<Role, string[]> = {
  viewer: ["documents:read"],
  editor: ["documents:read", "documents:create", "documents:send"],
  admin: ["documents:read", "documents:create", "documents:send", "documents:delete", "members:manage"],
  owner: ["documents:read", "documents:create", "documents:send", "documents:delete", "members:manage", "team:settings", "team:billing"],
};

function hasPermission(member: TeamMember, permission: string): boolean {
  return PERMISSIONS[member.role]?.includes(permission) ?? false;
}

// Middleware
function requirePermission(permission: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const member = req.teamMember; // Set by auth middleware
    if (!hasPermission(member, permission)) {
      return res.status(403).json({
        error: "Forbidden",
        required: permission,
        userRole: member.role,
      });
    }
    next();
  };
}

// Usage
app.delete("/api/documents/:id",
  requirePermission("documents:delete"),
  async (req, res) => {
    await teamClient.documents.deleteV0(parseInt(req.params.id));
    res.json({ deleted: true });
  }
);
```

### Step 3: Enterprise SSO Configuration

Documenso Enterprise supports SSO via OIDC. Configuration is done in the admin panel:

```text
SSO Setup (Enterprise only):
1. Navigate to Organization Settings > SSO
2. Select your OIDC provider
3. Enter:
   - Client ID (from your IdP)
   - Client Secret (from your IdP)
   - Issuer URL (e.g., https://login.microsoftonline.com/{tenant}/v2.0)
4. Configure redirect URI in your IdP:
   https://sign.yourcompany.com/api/auth/callback/oidc
5. Test with a non-admin user first

Supported providers:
- Google Workspace
- Microsoft Entra ID (Azure AD)
- Okta
- Auth0
- Any OIDC-compliant provider

Once enabled, team members sign in via:
https://sign.yourcompany.com/sso/{organization-slug}
```

### Step 4: Audit Logging (Enterprise)

Enterprise includes built-in audit logging. For additional application-level auditing:

```typescript
// src/audit/documenso-audit.ts
interface AuditEntry {
  timestamp: string;
  userId: string;
  teamId: string;
  action: string;
  resourceType: "document" | "template" | "team" | "member";
  resourceId: string;
  metadata: Record<string, any>;
}

async function auditLog(entry: Omit<AuditEntry, "timestamp">) {
  const log: AuditEntry = {
    ...entry,
    timestamp: new Date().toISOString(),
  };

  // Write to your audit store (database, CloudWatch, etc.)
  console.log(JSON.stringify(log));

  // Example: document sent
  // { action: "document.send", resourceType: "document",
  //   resourceId: "42", userId: "user_123", teamId: "team_456" }
}

// Wrap Documenso operations with audit logging
async function sendDocumentAudited(
  client: Documenso,
  documentId: number,
  userId: string,
  teamId: string
) {
  await client.documents.sendV0(documentId);
  await auditLog({
    userId,
    teamId,
    action: "document.send",
    resourceType: "document",
    resourceId: String(documentId),
    metadata: { status: "PENDING" },
  });
}

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.