Security Model
How UnderOcean protects your data, tenants, and AI workloads.
Authentication & sessions
- Every request is authenticated with short-lived, cryptographically signed session tokens.
- Sessions renew automatically on a rolling basis and expire quickly when unused, limiting the exposure window if a token is ever compromised.
Role-based access control (RBAC)
Access is governed by a small set of built-in roles, enforced consistently across every part of the platform:
| Role | Scope | Capabilities |
|---|---|---|
| Platform Admin | Platform | Manage all organizations |
| Organization Admin | Organization | Manage members and all projects in the organization |
| Organization Member | Organization | Access only the projects they're assigned to |
Custom roles
Organizations can also define custom roles with a precise, named subset of permissions — useful when the built-in owner/admin/member/viewer roles don't map cleanly to your internal structure. See Organizations & Projects.
Project-level access grants
Owners and admins always have full access to every project in their organization. For everyone else, access to a given project's resources (agents, flows, knowledge bases, MCP servers, gates) is closed by default and opened only through an explicit grant, scoped to that one project:
- A role grant extends a permission set to every member holding a given built-in role (member/viewer) or custom role, for that project only.
- A member grant extends a permission set to one specific member, for that project only — useful for exceptions that don't warrant a new custom role.
Grants can only include permissions that make sense to delegate — a fixed set of organization-level permissions (like managing billing or deleting the organization) can never be handed out this way, at either the custom-role or project-grant level.
A role or member grant can also be narrowed further to a specific subset
of records within a resource type — for example, a member grant with
FLOW_READ/FLOW_UPDATE can be restricted to only two named flows out of
a project's ten, instead of all of them. This record-level restriction is
enforced everywhere: list endpoints only return in-scope records, and
direct access to an out-of-scope record's ID is rejected even though the
grant otherwise holds the required permission. A grant with no such
restriction on a resource type continues to see every record of that type,
matching the platform's default (all-or-nothing) behavior.
Secrets & encryption
- Provider credentials (API keys and connection secrets) are encrypted at rest using industry-standard encryption, and are never exposed in any API response — not even to the organization admin who created them.
- The platform has no default or placeholder secrets — every secret must be explicitly configured before the system will run.
Tenant isolation
Every organization's data — projects, agents, flows, executions, and knowledge bases — is isolated from every other organization's data at the storage layer, not just at the application layer. See Multi-tenancy for details.
Responsible AI safeguards
User-supplied input is screened for prompt-injection attempts before it reaches a model, and any user-authored logic — such as flow branching conditions — is evaluated in a restricted, sandboxed manner rather than executed as arbitrary code.
Related
- Multi-tenancy — how tenant isolation is enforced beyond role-based authorization