How is this different from a simple database check?

The Authz service centralizes evaluation through a DB provider with object inheritance, revision tokens for consistency, and CEL conditions. Performance must be measured against the target policy model, data volume, and deployment.

Can I model complex organizational hierarchies?

Yes. The Object-Edge graph allows you to model any depth of hierarchy (e.g., Team -> Department -> Company). Permission checks can automatically traverse these edges, ensuring that a company-level grant correctly propagates to all child objects.

Does it support attribute-based access control (ABAC)?

Absolutely. Using Common Expression Language (CEL) conditions, you can evaluate request attributes, IP ranges, time-of-day, or custom user metadata during the permission check itself without extra database lookups.

Are there limits on the number of permission checks?

The commercial model is source licensing rather than per-check metering. Infrastructure, provider, support, and license costs still apply, and capacity is validated against the target policy and workload.

Central authorization

Centralize every permission decision.

Authz centralizes tenant, role, resource, relationship, and conditional access decisions for every service that needs a reliable answer.

Discuss Authz architecture Read the documentation

Inspect the published API contract

Authz domain

Deny-by-default decision boundary

Available · v1

Product boundary

Subject, action, object, and tenant become one policy decision.

Subject

User, group, or service identity

Action

The operation being requested

Object

Resource type and identifier

Context

Tenant, attributes, and consistency

Central decisionExplicit reasonRevision-aware policy

Lifecycle: Available · v1
Interfaces: REST · Connect/gRPC · MCP via Agent Gateway
AWS path: Design-partner pilot
Commercial basis: Perpetual source license

Product outcome

Authorization becomes dangerous when each service invents its own version.

Scattered role flags and local permission tables drift as the product grows. A dedicated Authz boundary gives services one deny-by-default decision contract while keeping policy logic visible, versioned, and adaptable in source.

Consistent decisions

Every product service asks the same subject, action, object, and tenant question.

Policy without application rewrites

Roles, bindings, relationships, and conditions evolve behind a stable runtime check.

A reviewable boundary

Policy data, consistency behaviour, and caller authentication can be inspected by the owning team.

01 / Domain capabilities

A complete Authz boundary, not a thin endpoint wrapper.

Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.

Tenant-scoped policy

Roles, bindings, relationships, and runtime checks remain inside an explicit customer policy namespace.

Role and direct bindings

Grant actions through reusable roles or focused subject-to-resource relationships.

Object relationship graph

Represent parent and child resources so policy can follow the product hierarchy without duplicated grants.

Conditional decisions

Evaluate documented CEL conditions against request context and policy attributes where static roles are insufficient.

02 / Product workflow

One path from product intent to an enforceable result.

The overview stays business-readable. The documentation and published contract contain field-level detail.

01
Define the action
Name the product operation in a vocabulary shared by callers and policy owners.
02
Bind the subject
Connect a user, group, or service to a role or focused resource relationship.
03
Check the request
Send subject, action, object, tenant context, and optional consistency requirements.
04
Enforce the decision
The calling service continues only after an explicit allow result and records the relevant context.

03 / Technical depth

Clear operational boundaries for the team that owns it.

Support is 12 months of updates and support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.

Check a product permissionHTTP / JSON

POST /authz.v1.AuthorizationService/CheckPermission
Authorization: Bearer $TOKEN
Content-Type: application/json

{
  "subject": { "user_id": "user_42" },
  "action": { "name": "project.update" },
  "object": { "type": "project", "id": "project_18" },
  "context": { "tenant_id": "company_72" }
}

Revisioned policy store

Durable roles, bindings, object edges, conditions, and policy revision state.

Consistency contract

Policy mutations can return a token for subsequent checks that require the documented revision behaviour.

Policy change stream

Revision-ordered changes can feed reviewed caches and downstream policy consumers.

Open documentation Open API reference

04 / Where it fits

Authz supports products with real tenant and commercial complexity.

These are product patterns, not customer case studies or measured outcomes.

Pattern 01

Enterprise role models

Customer administrators manage roles and bindings inside their tenant while application services use one decision API.

Pattern 02

Resource inheritance

Company, workspace, folder, and project relationships carry policy through a product hierarchy.

Pattern 03

Approval and temporary access

Conditions and time-bounded bindings support focused operational access without permanent global roles.

Ownership model

Own the service without owning every release problem.

The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.

Licensed Go source for the authorization domain

Published REST and Connect/gRPC contract

Customer-controlled policy data and deployment

Custom policy adapters and domain actions can be scoped

Published API evidence active

Customer-cloud deployment path

Depends on identity

Authz architecture review

Put Authz behind a product boundary your team can own.

Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.

Discuss Authz architecture Build my architecture

Frequently Asked Questions

Common Questions & Answers

Everything you need to know about integrating and hosting this Launch Rail service.

Related services

Identity Audit Log API Keys

Related use cases

LegalTech Fintech Healthcare