Authorization deployment models for regulated NHI environments

At a glance

What this is: This guide explains how externalized authorization deployment models work and finds that the real decision is where the control plane lives, not where the policy decision point runs.

Why it matters: IAM, NHI, and compliance teams need a deployment model that keeps decision logs, policy governance, and audit evidence aligned with regulatory and operational constraints.

👉 Read Cerbos' guide to authorization deployment models for regulated environments

Context

Authorization is the runtime control that decides whether a request is allowed, and the governance problem is where that decision logic and its logs can legally and operationally reside. For NHI programmes, this matters because service-to-service access often needs the same traceability and residency discipline as human access, especially when regulated workloads sit behind every call path.

The article’s core claim is that cloud-hosted, self-hosted, and air-gapped are not interchangeable categories. They are different answers to the same governance question: who owns the control plane, where are the audit records stored, and how much operational burden can the team carry without weakening policy enforcement.

Key questions

Q: How should teams decide between cloud-hosted and self-hosted authorization?

A: Start with residency, auditability, and operational capacity. If decision logs or policy artifacts must stay inside a specific jurisdiction or perimeter, self-hosted is usually the safer fit. If the compliance model allows vendor-managed control planes and the team wants to reduce infrastructure overhead, cloud-hosted can be appropriate. The deployment choice should follow governance constraints first, not convenience.

Q: When does self-hosted authorization create more risk than it removes?

A: Self-hosted creates more risk when the team cannot reliably patch, monitor, back up, and recover the control plane. In that case, the burden of sovereignty can turn into delayed fixes, inconsistent versions, and weak audit evidence. The model only reduces risk when the organisation can operate it continuously and prove that it does so.

Q: What breaks when authorization decision logs leave the expected jurisdiction?

A: Auditability breaks first, followed by regulatory confidence and internal traceability. If regulators require records to remain in a specific country or controlled environment, exporting decision logs elsewhere can undermine compliance even when the policy itself is correct. Teams should treat log residency as part of the access control design, not as a downstream storage choice.

Q: Who is accountable for authorization in a self-hosted deployment?

A: The organisation remains accountable for the authorization service, including uptime, patching, incident response, backups, and evidence retention. Self-hosting may shift operational tasks away from the vendor, but it does not shift regulatory responsibility. Security, platform, and compliance teams need a clear ownership model before the system is placed into production.

Technical breakdown

How externalized authorization splits the decision path

Externalized authorization separates the policy decision point from the applications that enforce it. The PDP evaluates requests in real time, while the control plane handles policy authoring, validation, versioning, distribution, and audit logging. The key architectural constant is that the PDP stays close to workloads inside the customer environment. What changes across models is who operates the control plane and where policy artifacts and logs are managed. That split is why cloud-hosted and self-hosted are governance choices as much as infrastructure choices.

Practical implication: map every authorization flow to the control plane location and decision-log storage path before approving the deployment model.

Why self-hosted authorization changes compliance posture

Self-hosted authorization keeps the control plane inside the customer’s perimeter, alongside PDPs and internal logging systems. That matters when residency, traceability, or regulated recordkeeping cannot depend on a vendor’s infrastructure choices. It also supports tighter integration with internal PKI, observability, and identity sources. The trade-off is that the team inherits uptime, patching, backup, and scaling responsibilities. In practice, the deployment is only as compliant as the team’s operational discipline.

Practical implication: treat self-hosted authorization as an owned service with explicit SRE, security, and audit responsibilities.

Air-gapped authorization is an environment property, not a separate model

Air-gapped authorization works the same way as self-hosted authorization, but policy updates and patches move through controlled transfer channels rather than direct network connectivity. Policies are signed, exported, and verified before activation, while decision logs stay internal until exported on controlled schedules. That means the core governance question is not whether authorization can function offline. It can. The question is whether your change-management and compliance processes can tolerate manual movement and delayed visibility.

Practical implication: design manual transfer, verification, and export workflows before placing regulated workloads into an isolated environment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization deployment is an identity governance decision, not an infrastructure preference. The article is right to separate the policy decision point from the control plane, because that distinction determines where audit evidence lives and who can prove compliance. For NHI programmes, authorization data is part of the identity record, not a side effect of application traffic. Practitioners should treat deployment choice as a governance boundary, not a hosting convenience.

Jurisdictional control over decision logs is the real regulatory pressure point. The article repeatedly shows that the risk is not policy correctness alone, but whether access decisions and their logs remain in the jurisdiction auditors expect. That is why self-hosted models matter for regulated sectors. The practical conclusion is that residency, not just latency, is often the deciding factor in authorization architecture.

Operational ownership becomes the hidden cost of sovereignty. Self-hosted and air-gapped deployment improve control, but they also shift patching, monitoring, recovery, and version management onto the team. This is where many programmes overestimate their readiness. The implication is simple: if the team cannot operate the platform continuously, the governance value of self-hosting can erode quickly.

Policy fragmentation is the failure mode when hybrid authorization grows without unified governance. The article notes that some organizations run both cloud-hosted and self-hosted models, which is often rational. But without unified authoring, testing, and audit practices, the same authorization logic can drift across environments. That creates an identity control plane split that security teams must manage deliberately, not accidentally.

Unified policy lifecycle is the named concept that matters here. The deployment model only stays governable when policy authoring, validation, rollout, and audit review remain consistent across every environment. Once those stages diverge, authorization stops behaving like one system and starts behaving like several partially synchronized ones. Practitioners should measure deployment success by lifecycle consistency, not by whether the platform is cloud or on-premise.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, which underscores how quickly identity governance is moving beyond traditional access models.
• For a deeper governance lens, compare this with NHI Lifecycle Management Guide to align policy, rotation, and offboarding across environments.

What this signals

Unified policy lifecycle: deployment consistency matters because authorization only stays governable when authoring, validation, rollout, and audit review move together across environments. Once those controls diverge, hybrid deployments become harder to certify and easier to drift.

For regulated teams, the practical signal is that self-hosted and air-gapped models will keep expanding wherever residency and traceability dominate the design brief. The right question is not whether a platform can run in your environment, but whether your programme can operate it with evidence.

The broader pattern is that identity teams are being pulled into architecture decisions much earlier than before. That shift aligns with the need for stronger governance over NHI lifecycles and access decisions, especially where auditability and jurisdiction are inseparable.

For practitioners

• Classify authorization data by residency requirement Separate policy content, decision logs, and relationship data by the jurisdictions that govern them. Use that mapping to decide whether cloud-hosted control planes are permissible or whether self-hosted placement is mandatory.
• Document the control-plane ownership model Record who patches, backs up, monitors, and recovers the authorization control plane. Include escalation paths, support coverage, and evidence retention so ownership is auditable rather than assumed.
• Test policy rollout without application redeployments Validate that policy changes can be compiled, distributed, and rolled back independently of application releases. This reduces the chance that authorization updates create downtime or slow engineering delivery.
• Unify audit evidence across hybrid deployments If you run cloud-hosted and self-hosted authorization together, standardize policy versioning, log schema, and review workflows so auditors see one governance model rather than two disconnected ones.

Key takeaways

• The central issue is not where authorization executes, but who controls the policy plane and where its evidence resides.
• Regulated environments make residency and audit traceability first-order design constraints, not implementation details.
• Teams that choose self-hosted or air-gapped authorization must prove continuous operational ownership, or the governance benefits will not hold.

Key terms

• Policy Decision Point: The component that evaluates an authorization request and returns allow or deny in real time. In externalized authorization, it sits close to the workload so every request can be judged consistently without embedding policy logic in application code.
• Control Plane: The management layer for policy authoring, validation, versioning, distribution, and audit logging. It determines who can change authorization rules, how those changes are tested, and where the evidence for those decisions is stored.
• Air-Gapped Environment: A network or system that has no external connectivity and relies on controlled transfer methods for updates and exports. For authorization, it changes the operating model rather than the underlying decision logic, because policy updates and log movement become manual and tightly governed.

Deepen your knowledge

Authorization deployment models and audit traceability are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is weighing self-hosted, cloud-hosted, or air-gapped patterns, it is worth exploring.

This post draws on content published by Cerbos: authorization deployment models for regulated environments. Read the original.