# 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](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/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.

---

## Recommended modules

- [Identity Manager](https://apinizer.com/products/identity-manager) — OAuth2, OIDC, JWT, LDAP, AD, SAML — federate identity once, reuse it across every tier.
- [API Gateway](https://apinizer.com/products/api-gateway) — The runtime that enforces tier scopes on every request and every config change.
- [Analytics Engine](https://apinizer.com/products/analytics-engine) — Per-user, per-project, per-environment views. See what your tiers actually do.
- [AI Gateway](https://apinizer.com/products/ai-gateway) — Same three tiers for LLM and agent traffic. The AI plane inherits the access model.

---

## Resources

- [Three-tier access model](https://docs.apinizer.com/en) — How Platform, Project, and Environment scopes compose — and what auditors look for.
- [Identity Manager](https://apinizer.com/products/identity-manager) — OAuth2, OIDC, JWT, LDAP, AD, SAML — federated identity for every tier.
- [Audit at the persistence layer](https://apinizer.com/solutions/observability-audit) — Audit enforced at the framework boundary — bypass is rejected, not policed.
- [Compliance posture](https://apinizer.com/solutions/kvkk-gdpr-bddk-compliance) — How three-tier maps to BDDK, KVKK, GDPR, ISO 27001 segregation-of-duties controls.
- [Architecture overview](https://docs.apinizer.com/en/concepts/architecture) — Where the audit plane and identity surface live in the topology.
- [Customer roster](https://apinizer.com/company/customers) — Banks, ministries, defense, telecom — teams that already run three-tier in production.

---

## Related use cases

- [Observability & audit](https://apinizer.com/solutions/observability-audit) — For platform teams
- [API lifecycle management](https://apinizer.com/solutions/api-lifecycle-management) — For platform teams
- [KVKK / GDPR / BDDK compliance](https://apinizer.com/solutions/kvkk-gdpr-bddk-compliance) — For executives
- [Observability & audit](https://apinizer.com/solutions/observability-audit) — For platform teams

---

## 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](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs)

---

## Links

- Products: https://apinizer.com/products
- AI Gateway: https://apinizer.com/products/ai-gateway
- Solutions: https://apinizer.com/solutions
- Pricing: https://apinizer.com/pricing
- Developers: https://apinizer.com/developers
- Documentation: https://docs.apinizer.com/index-en
- Blog: https://apinizer.com/blog
- Contact: https://apinizer.com/company/contact

© 2026 Apinizer. All rights reserved.
