Topic starter
06/09/2026 6:20 pm
TL;DR: Opal Security says Paladin now runs in self-hosted, on-prem deployments where access governance decisions, review cycles, and LLM inference can stay inside customer-controlled infrastructure. That changes the control boundary for AI access governance: review logic may be local, but trust still depends on how entitlements, usage signals, and model access are administered.
Editorial analysis by NHI Mgmt Group, based on content published by Opal Security: “Paladin, Opalâs access agent, is now available in on-prem, self-hosted deployments”.
Key questions
Q: How should teams govern access review agents that run inside their own infrastructure?
A: Treat the deployment as part of the control design.
Q: What breaks when access automation is treated as governance?
A: What breaks is control quality.
Q: How do security teams know whether access review recommendations are trustworthy?
A: Look at the underlying entitlement data first.
Practitioner guidance
- Define the self-hosted control boundary Map which parts of the access review workflow run inside your environment, which depend on external model services, and where audit evidence is generated.
- Validate entitlement signal quality Check whether role assignments, peer-group definitions, and last-use telemetry are complete enough to support revoke-or-keep recommendations without manual rework.
- Separate recommendation from authority Document which access decisions the agent may make autonomously and which must always escalate to a human reviewer with supporting reasoning.
Bottom line: Self-hosted access governance moves AI review logic into the customer's environment, but the identity and entitlement problem remains the same.
What's in the full announcement
Opal Security's full product post covers the operational detail this post intentionally leaves for the source:
- Self-hosted deployment paths, including the KOTS option and the Helm chart option
- How to supply an Anthropic API key or point Paladin at Amazon Bedrock in your own AWS account
- The way Paladin evaluates role, peer-group, and last-use signals before it recommends keep, revoke, or flag
- The setup guides and installation prerequisites for teams planning an on-prem rollout
👉 Read Opal Security's product post on self-hosted Paladin for AI access governance →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 6:21 pm
Self-hosting shifts the control boundary, not the governance burden. Moving Paladin into customer infrastructure changes who owns the runtime, but it does not remove the need for strong entitlement governance, evidence quality, and decision traceability. The centre of gravity moves from vendor tenancy to customer-operated control planes, which means the IAM programme inherits more operational responsibility. Practitioners should treat self-hosted access governance as an architecture choice with governance consequences, not as a shortcut around identity discipline.
A question worth separating out:
Q: When should organisations prioritise human review over fully autonomous AI decisions?
A: Organisations should prioritise human review whenever the decision carries legal, safety, ethical, or reputational consequences. That includes areas such as diagnosis, access decisions, financial judgement, and autonomous action. Human review is also appropriate when the model is poorly understood, the data is sensitive, or the cost of a wrong outcome is difficult to reverse.
👉 Read our full editorial: Self-hosted AI access governance shifts the control boundary