Security Model Overview

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude

The Security Model defines how identities authenticate to Synqly and how access to resources is authorized. It applies consistently across the Management API, Connector APIs and MCP servers.

The model combines permission sets, resource restrictions, roles, and scoped tokens to enforce least-privilege access while supporting auditing, delegation, and enterprise governance requirements.

If you haven't read Understanding the Synqly Model yet, start there — it covers organizations, accounts, and members, which the Security Model acts on.

How authorization is determined

This section explains the RBAC model that the token types are built on. It provides the context needed when designing roles, troubleshooting unexpected access denials, or understanding why a token has a particular level of access.

Synqly's authorization model is built on three building blocks:

Permission sets

A permission set is a named, predefined bundle of API actions. You pick from a fixed catalogue — you don't assemble one from scratch.

Resources

A permission set says what you can do — but to what? Without a resource restriction, administrator means administrator over everything in your organization. Resources let you apply restrictions across three dimensions:

• Organizations (resources.organizations) — restrict by organization ID or label
• Accounts (resources.accounts) — restrict by account ID, label, or environment
• Integrations (resources.integrations) — restrict by connector category

resources:
  accounts:
    ids: ["account-123", "account-456"]

Roles

A role is a permission set + resource restriction, given a name so you can reuse it across tokens and members.

curl -i -X POST \
  https://api.synqly.com/v1/roles \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "production-account-manager",
    "resources": {
      "accounts": {
        "environments": [
          "prod"
        ],
        "labels": [
          "customer-success-team"
        ]
      }
    },
    "permission_set": "account-manager"
  }'

See the Roles API reference for full create/list operations.

Members

A role does nothing until it's bound to a member — a human user or a service account. A member's effective access is the union of all their role bindings.

curl -i -X POST \
  https://api.synqly.com/v1/members \
  -H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "user@example.com",
    "secret": "password123",
    "role_binding": [
      "production-account-manager"
    ]
  }'

See the Members API reference.

Why Synqly uses role-based access control

Synqly uses role-based access control (RBAC) to support least-privilege access, resource isolation, and auditability. Instead of granting broad access through shared credentials, RBAC allows permissions to be assigned according to a caller's responsibilities and constrained to specific resources.

A resource restriction is not a convention or expectation about how a caller should behave. It is a platform-enforced boundary that is evaluated on every request.