How Cedarling works

One policy decision, right where it matters.

Cedarling evaluates Cedar policies inside your application, service, gateway, or sidecar. Requests can use validated tokens or identity facts established by your application.

Try a policy decision Find your environment

Open sourceEmbedded runtimeCedar policies

JavaScriptPythonRustKotlinSwiftGoJavaCBrowseriOSAndroidAPI gatewayCedarling Sidecar

Your language outside.
Cedarling inside.

Cedarling embeds the Cedar policy engine where enforcement happens—or runs as a sidecar—while you keep using the tools you know. Identity can come from validated tokens or facts established by the application.

One policy model, with binding-specific integration surfaces.

Keep policy separate from application logic.

Write authorization rules in Cedar and let the application focus on gathering facts and enforcing the result.

One explicit policy boundary.

Distinguish decisions from failures.

A DENY is a valid policy outcome; initialization, validation, and SDK errors follow a separate error path.

Fail clearly and safely.

Keep useful diagnostics.

Use the request ID and available reasons or errors for debugging without logging tokens, secrets, or sensitive request data.

Evidence without secret leakage.

One policy boundary.
Across every security edge.

01LOCALEvaluate where enforcement happens.
02PORTABLEBring your integration surface.
03CONTEXTApplication facts become policy input.
04EVIDENCEReturn the decision and diagnostics.

Define the store.
Ask for a decision.

Cedarling loads a schema and Cedar policies, plus optional default entities and trusted-issuer configuration. Your application supplies action, resource, and context together with validated tokens or an application-asserted principal at the enforcement point.

Example workspace

import { createCedarling } from "@janssenproject/cedarling";

const created = await createCedarling({

applicationName: "tool-firewall",

policyStore: { type: "inline", document: policyStoreDocument },

});

if (!created.ok) throw created.error;

const client = created.value;

try {

const result = await client.authorizeUnsigned({

principal: { type: "ToolFirewall::User", id: "alice" },

action: 'ToolFirewall::Action::"invoke"',

resource: { type: "ToolFirewall::Tool", id: "deploy" },

context: { approved: true },

});

if (!result.ok) throw result.error;

console.log(result.value.decision ? "ALLOW" : "DENY");

} finally {

const closed = await client.shutDown();

if (!closed.ok) reportShutdownFailure(closed.error);

}

Read-only JavaScript guide—not an executable Playground. Cedarling also supports token-backed requests and equivalent policy evaluation through its other bindings and deployment surfaces.

Open the policy boundary.

Cedarling brings explicit policy decisions to the enforcement point without tying policy to one language or deployment model.

Principal /
ActionResource /
ContextCedar
policiesALLOW
with reasons and request IDDENY
with reasons and request ID

Open the playground Find your environment