feat(cedar): add namespace option for namespaced Cedar policies

[victornicolet]

Summary

Adds a namespace config option to CedarAuthorization that prefixes action and resource types in the authorization request. This will allow using Cedar's tool directly, get full schema validation support, and better integration with the proposed Cedar policy builder: cedar-policy/cedar-for-agents#137.

We can do a follow up PR for Python, but afaik, there is not Python policy builder yet, so the need isn't as pressing.

Motivation

Policy generators like cedar-agent-policy-builder produce namespaced Cedar policies following the @cedar-policy/mcp-schema-generator-wasm conventions (e.g. Agent::Action::"search"). Currently, CedarAuthorization hardcodes unnamespaced types (Action::"search"), making it incompatible with these policies.

Changes

• Add namespace?: string to CedarAuthorizationConfig
• When set: action → {ns}::Action, resource → {ns}::McpServer::"default", default principal → {ns}::User::"anonymous"
• Schema generation preserves the namespace wrapper instead of stripping it
• When unset: behavior is unchanged (fully backward compatible)

Usage

Before the merge, CedarAuthorization generates a schema without a namespace:

const cedar = new CedarAuthorization({
  policies,  
  entities, 
  principalResolver: (state) => ({ type: 'User', id: state.user_id }),
})

The type of the principal is User, without namespace. Policies and entities reference User for the users, and Resource. This is convenient for quick writing quick policies, but doesn't work once you start integrating with other Cedar or agents tools (such as the policy generator e.g. in lizradway/cedar-for-agents#2).

After the merge, you can add an optional namespace:

const cedar = new CedarAuthorization({
  namespace: 'Agent',
  policies,  // e.g. from cedar-agent-policy-builder
  entities,  // e.g. from cedar-agent-policy-builder
  principalResolver: (state) => ({ type: 'Agent::User', id: state.user_id }),
})

The type of principals is Agent::User and the agent is represented by Agent::Resource. You can use policies that fully validate against schemas generated by the cedar-policy-mcp-schema-generator, or use other policy generators.

Testing

3 new tests added, all 39 Cedar tests pass.

[github-actions]

Issue (Important): This adds a new public config option but the diff doesn't touch the user-facing docs. The Cedar Authorization page (site/src/content/docs/user-guide/concepts/agents/interventions/cedar-authorization.mdx) documents the principal/action/resource mapping table and is the place users learn this API — the new namespace option and its effect on the type mapping should be documented there, ideally with the cedar-agent-policy-builder use case from the PR description.

Also, as a new public API surface on a vended intervention, this looks like it should carry the needs-api-review label so a designated reviewer can weigh in on the abstraction (e.g. a single namespace string vs. configurable resource type/id). The PR body's usage example and signature are a good starting point for that review.

[github-actions]

Assessment: Request Changes

The namespace option is a useful addition with clean backward-compatible defaults, but there's a correctness gap: the schema generator treats namespace as a boolean while its stub hardcodes namespace Agent, so namespaced configs that use schema auto-generation (tools) will fail validation for any namespace other than Agent. The new tests don't exercise that path, so it slipped through.

Review themes

• Correctness: Schema generation doesn't actually use the namespace value; request types (McpServer/default) also don't match the stub's Resource entity — namespaced + schema-validated configs won't validate.
• Testing: The schema-generation path (the riskiest change) is untested; one of the three new tests duplicates existing backward-compat coverage. A namespace + tools test with a non-Agent namespace would catch the above.
• Cross-SDK parity: This is a vended intervention shipped in both SDKs; Python wasn't updated. Worth aligning or explicitly deferring.
• Docs / API review: New public option isn't documented on the Cedar page and likely warrants the needs-api-review label.
• Minor: Per-call type ternaries in beforeToolCall can be precomputed in the constructor.

The backward-compatibility design is solid and the inline JSDoc on the new option is clear — nicely scoped once the schema-generation path is sorted out.

[github-actions]

Re-review of dc62dd8 ("address review comments and reformat")

Assessment: Comment (close to approval)

The correctness and testing concerns from the first pass are resolved, verified locally (all 39 Cedar tests pass):

• ✅ Schema generator now interpolates the configured namespace into the stub — it's genuinely threaded through, not treated as a boolean.
• ✅ Request resource type aligned to ${ns}::Resource to match the stub's @mcp_resource entity Resource.
• ✅ The previously-duplicate test was replaced with one that exercises the namespace + tools schema-generation path under a non-Agent namespace — the exact gap that hid the original bug.
• ✅ Namespaced types precomputed in the constructor.

Two items from the original review are still open and not addressed by this commit:

Remaining (non-blocking)

• Docs: The new namespace option still isn't documented on cedar-authorization.mdx. Worth a short addition with the cedar-agent-policy-builder use case.
• Cross-SDK parity: Python CedarAuthorization still lacks namespace. Fine to defer, but please track it explicitly so the two SDKs don't drift.

Nice, focused iteration — the implementation side looks good to me now.

[lizradway]

if you could put an api example in the pr description before/after merge that would be great.

similarly, if you wanted to do follow ups for python / docs site, if not happy to do them when i'm back.

[victornicolet]

if you could put an api example in the pr description before/after merge that would be great.

Added a little bit more description of how it changes the API.

similarly, if you wanted to do follow ups for python / docs site, if not happy to do them when i'm back.

I'll follow up with the docs site soon, the python will probably come later since the use case isn't as pressing (we don't have a policy generator plan in Python?).