Agent mode·Plain-text view for agents and LLMsraw md →

Three-tier permissions — Use case

Platform / Project / Environment — three layers of access, one model. Engineers move fast, auditors get a clean trail, and nobody touches what they shouldn't.

Platform teams · Access · For platform teams

Three layers of permission. One model your auditor will love.

Platform admins set the rules. Project owners ship the work. Environment operators flip the switches. Each tier sees exactly what their role needs — no more, no less.

Request a demo · Read the docs

The problem

The problem

Flat permission models eventually collapse.

Either everyone is an admin (and the auditor leaves angry), or every change becomes a ticket (and engineers leave angry). Apinizer's three-tier model gives platform teams a way out: Platform owns governance, Projects own delivery, Environments own operations. Each tier has explicit scopes; nobody escalates by accident.

Capabilities

Platform tier

Owns the global policies, identity sources, encryption keys, and audit destinations. The smallest group with the largest blast radius — and the strictest controls.

Project tier

Each business domain — payments, claims, inventory — gets its own project. Owners design, ship, deprecate within their boundary. They cannot see other projects' secrets.

Environment tier

Dev, test, staging, DR, prod — each is its own access scope. Promotion requires explicit grants; nobody pushes to prod by hitting the wrong dropdown.

Federated identity

Roles map from your existing AD / LDAP / OIDC groups. Onboarding is a group membership change; offboarding is automatic.

Per-action audit

Every grant, change, deploy, and view captured at the persistence layer. The trail is queryable by user, project, environment, and time window.

Encrypted secret fields

API keys, tokens, and credentials live as encrypted fields — decrypted only at runtime, never visible in lists or exports.

Real-world examples

Banking

Scenario: Aktif Bank platform team grants 8 business units project scopes

Outcome: Each unit ships APIs within their own project. Platform stays out of the daily flow; auditors see who did what without paging anyone.

Government

Scenario: Berlin federal agency separates citizen-facing and admin-facing scopes

Outcome: Citizen project lives in one tier; backoffice project in another. Operators in one cannot read secrets in the other; audit confirms quarterly.

Banking

Scenario: Riyadh bank meets SAMA segregation-of-duties with three explicit tiers

Outcome: Platform tier holds 4 people. Project tiers hold 27 owners. Environment promotions need a different person than the author — enforced by the gateway, not by policy memos.

Metric: 4 / 27 / 110 split

Insurance

Scenario: Paris insurer maps roles from a 9000-person Active Directory

Outcome: AD groups drive every grant. New hires get access on day one; leavers lose it on day zero. No spreadsheets, no Wiki pages tracking who has what.

Telecom

Scenario: Madrid carrier separates B2C, B2B, and partner-facing projects

Outcome: Three project owners; three audit lanes. When a partner asks for a change, the right team has the right keys — and only those keys.

Public sector

Scenario: Warsaw ministry ships a deploy-approval workflow without a build

Outcome: Author and approver are different humans in different AD groups. The gateway enforces the split; the auditor's quarterly export is a one-liner.

Healthcare

Scenario: Stockholm regional health agency gives 22 clinics scoped access

Outcome: Each clinic project sees its own APIs and nobody else's. Platform tier holds patient-data classifications; clinics cannot remove them.

Energy

Scenario: Baku utility ties environment promotion to an external ticket system

Outcome: Promotion to prod requires a referenced ticket in ITSM. The gateway stamps the audit record with the ticket ID — auditors stop asking for spreadsheets.

Three tiers. Explicit grants. Nothing implicit.

  • 01 · Map identity — Federate from AD / LDAP / OIDC. Roles map to existing groups — no parallel user store.
  • 02 · Define projects — Each business domain gets its own project with its own secrets, variables, and owners.
  • 03 · Scope environments — Dev, test, staging, prod, DR — explicit grants per environment. Promotion is a permission, not a habit.
  • 04 · Audit continuously — Every grant, change, deploy, and view writes immutable audit. Export by query, not by request.
  • Identity Manager — OAuth2, OIDC, JWT, LDAP, AD, SAML — federate identity once, reuse it across every tier.
  • API Gateway — The runtime that enforces tier scopes on every request and every config change.
  • Analytics Engine — Per-user, per-project, per-environment views. See what your tiers actually do.
  • AI Gateway — Same three tiers for LLM and agent traffic. The AI plane inherits the access model.

Resources

  • Three-tier access model — How Platform, Project, and Environment scopes compose — and what auditors look for.
  • Identity Manager — OAuth2, OIDC, JWT, LDAP, AD, SAML — federated identity for every tier.
  • Audit at the persistence layer — Audit enforced at the framework boundary — bypass is rejected, not policed.
  • Compliance posture — How three-tier maps to BDDK, KVKK, GDPR, ISO 27001 segregation-of-duties controls.
  • Architecture overview — Where the audit plane and identity surface live in the topology.
  • Customer roster — Banks, ministries, defense, telecom — teams that already run three-tier in production.

Next step

Permissions that match how teams actually work

Engineers move fast. Auditors get clean evidence.

A 30-minute walkthrough — Platform, Project, Environment, and the audit trail behind them.

Book a Demo · Read the docs

© 2026 Apinizer. All rights reserved.