SecurityOctober 9, 2026 · 6 min read

Provision once, enforce everywhere: Cedar & SCIM in Starlight

Starlight 1.6 puts one authorization model under everything. Users, compute, storage, and networking all answer to the same Cedar policies, fed by the identity provider you already run. It keeps enforcing when the link goes down.

Brad Sollar

What Cedar is

Cedar is an open source language for writing authorization policy. It answers one question: can this principal take this action on this resource, in this context?

It came out of AWS, went open source in 2023, and joined the CNCF as a Sandbox project in October 2025. The engine is written in Rust. The language specification is formally verified.

A policy reads like a sentence:

cedar

# Virtual machine example: customers only see their own machines

permit(principal, action, resource) when {
  context.action == "vm:instances:read" &&
  resource.tenant == principal.tenant
};

# This is a "view your own organization's VMs" rule attached to a customer
# role, which lets a customer view a virtual machine only if it belongs to
# the same organization they do. If Alice works for Company A, she can see
# Company A's VMs but not Company B's, even if she knows exactly which one
# to ask for. The rule only grants viewing, so if she tries to delete or
# change a VM, even one of her own company's, she's refused, because in
# Starlight anything not explicitly allowed is denied.

Three properties make it a good fit for a platform like ours:

Default deny. Nothing is allowed until a policy permits it. A forbid always beats a permit.
One language, three models. Roles, attributes, and relationships all fit in the same policy set. No separate RBAC and ABAC systems to reconcile.
Analyzable. Policies can be validated against a schema and reasoned about before they ship. You can prove a change did not widen access.

Auditors can read it. Engineers can test it. That combination is rare.

What SCIM is

SCIM is the System for Cross-domain Identity Management. It is an IETF standard, published in 2015, for moving users and groups between systems over a REST API.

Your identity provider is the source of truth. When someone joins, changes teams, or leaves, the provider pushes that change to every connected system. No tickets. No local accounts drifting out of date.

SCIM handles the lifecycle that single sign-on does not. SSO proves who you are at login. SCIM makes sure the account, its attributes, and its group memberships exist before you log in, and disappear when you should no longer have them.

The failure it prevents is a familiar one: the account that outlives the person.

Why the pair matters

SCIM gets identity in. Cedar turns identity into decisions. Each is half an answer without the other.

Most infrastructure stacks grew their access control one subsystem at a time. The hypervisor has roles. The storage array has its own. The network controller has a third set. Each one maps to the directory differently, if at all.

That sprawl is where zero trust programs stall. You cannot show an assessor one policy when there are five. You cannot revoke access cleanly when five systems each hold a copy of the user.

Put SCIM and Cedar together and the model collapses to something you can explain on one slide:

The directory says who people are and what groups they belong to.
SCIM keeps the platform's copy current.
Cedar policies decide what those people can do.
Every request is checked against those policies. Every decision is logged.

How Starlight 1.6 uses them

In 1.6, Cedar is the authorization layer for the whole product. It is not a feature bolted onto the console. Every surface that can change the system asks the same engine first.

Area	What policy decides
Users	Who can sign in, which groups and roles they carry, who can manage identity and policy itself
Compute	Who can create, start, stop, open a console to, or migrate a workload, and on which clusters and sites
Storage	Who can create, attach, snapshot, or delete volumes and shared storage
Networking	Who can create or change virtual networks and attach workloads to them

The same policy set covers all four rows. An operator scoped to one site is scoped to that site's VMs, its storage, and its networks in one statement. There is no second place to forget.

Identity and policy live in a dedicated IAM workspace in the console. Users and groups arrive there by SCIM. Policies are written, reviewed, and applied there.

This is what lets Starlight act as the IAM for the system, not a consumer of someone else's.

Policy that holds offline

Cloud IAM assumes the cloud is reachable. Our customers cannot assume that.

Cedar is an embedded engine, not a hosted service. Starlight evaluates policy locally, against identities and policies held on the platform. A decision never needs a call home.

So when the link drops, nothing about enforcement changes. The same people can do the same things. Everything else is still denied. When the link returns, identity changes from the provider sync back in.

Disconnected operation is the normal case at the edge and in air-gapped enclaves. Access control that fails open, or fails closed on everyone, is not acceptable in either.

Works with the provider you already run

Nobody wants another directory. Starlight 1.6 connects to the one you have: Okta, LDAP, Active Directory, and other standards-based providers.

Your groups stay your groups. A team that already exists in the directory becomes a principal you can write policy against. Remove someone upstream and their access on Starlight goes with it.

The provider stays the source of truth for who people are. Starlight is the source of truth for what they can do on the platform.

"Can my agent set this up?"

We walked a customer through all of this recently. Identity syncing in. One policy set across compute, storage, and networking. Enforcement with the uplink pulled.

They said it was awesome. Then they asked the question we now expect from every serious team: could they point their Hermes or Claude agent at it and have the agent do the setup?

Absolutely! The MCP server is part of Starlight. It is not an add-on and it is not a side door.

Then the part that mattered more: policy applies to it too. An agent connected over MCP is a principal like any other. It gets the permissions policy grants it and nothing else. If Cedar says an identity cannot touch production storage, it does not matter whether that identity is a person in the console or an agent on a tool call.

They said it would reshape how they work.

That reaction tells you where the market is. Teams want agents doing real infrastructure work. What stops them is not capability. It is the fear of handing an agent the keys with no guardrails. Put the agent under the same policy engine as everyone else and that fear has an answer.

One engine. One policy set. Humans, automation, and agents all under it. Connected or not.