CMF extensions and the attribute bag

A policy is written against a flat AttributeBag. The bag is filled by praxis-policy-apl-cmf: each present slot on Extensions is walked into dotted keys. Plugins that received the typed slot still see the original struct. This document is the contract for what the bridge emits, how original collections relate to flattened booleans, and which keys exist.

The twelve slots dispatched by extract_extensions are listed below. raw_credentials and candidate_constraint are not among them: credentials never enter the bag, and a routing constraint is not a policy attribute.

Contents

• Absent values
• Original collections and flattened booleans
• subject.claims
• What each decision point does with a missing key
• The twelve slots
• Payloads that are not slots

Absent values

The rule is per attribute type, and it only applies inside a present slot. An absent slot writes nothing for its namespace. CEL then reports an undeclared reference for that namespace; synthesizing empty namespaces for missing slots is out of scope.

ppe-pdp-diff is the executable form of this table for the keys Cedar can see. Empty subject.teams and a subject with no roles (no role.* keys, empty subject.roles) must Deny on APL, CEL, cedar-direct, and OPA when the policy is a membership or flattened-bool gate. Unguarded presence, equality, membership, and order probes of an omitted claim scalar also Deny on all four (CEL and Cedar report a key error rather than a policy false). That agreement does not cover APL != or not in: those evaluate true on a missing key, so require(claim.tenant != "acme") Allows in APL while CEL, cedar-direct, and OPA Deny. not in Allows in APL (and in OPA, where not of undefined is true) while CEL and cedar-direct Deny. A flattened bool whose namespace was never written, and a missing subject.id, remain allowlisted: CEL is an eval error, Cedar cannot build a principal without an id, and making those agree needs CEL root seeding and a generated Cedar schema, which is a follow-up to #18.

Original collections and flattened booleans

Pull request #7 added the original CMF collections as bag keys alongside the flattened booleans that were already there.

The set is the primary form. The five flattened collections exist because require(role.hr) predates the original sets; no more are added. Nine other StringSets are set-only — client.teams, client.authorized_scopes, client.authorized_audiences, caller_workload.selectors, this_workload.selectors, security.labels, agent.conversation.topics, meta.tags, llm.capabilities — so require(tag.pii) is false forever, by design.

Membership names are atomic values. A dotted name such as admin.readonly stays unchanged in subject.roles, but it does not emit role.admin.readonly. Emitting that key would make CEL construct nested maps and incorrectly satisfy has(role.admin). Address dotted names through the original set: subject.roles contains "admin.readonly" in APL or "admin.readonly" in subject.roles in CEL.

Authors should use the original set for membership (subject.roles contains "hr" in APL, "hr" in subject.roles in CEL, "hr" in input.subject.roles in OPA). That key is present whenever the subject (or client) sub-record is, so the four decision points agree on empty.

Flattened booleans are an APL convenience: require(role.hr) is false when the key is missing. They are not a second source of truth. The bridge always derives them from the set, so as emitted they cannot disagree. A later AttributeBag::set that writes one and not the other last write wins on that key; the other key is left as it was. Do not mix a hand-built bag with the bridge if you need them to stay paired.

Cedar does not read the bag the way CEL and OPA do. principal.roles, principal.permissions, and principal.teams are read from the canonical subject.roles, subject.permissions, and subject.teams sets, preserving dotted membership names. When a manually built bag omits a canonical roles or permissions set, Cedar falls back to flattened role.* / perm.* trues for compatibility. A present canonical set is authoritative. Cedar does not surface client.*, http.*, or the other slots as principal attributes. A Cedar policy that needs those values does not get them from this mapping.

subject.claims

There is no subject.claims bag key, and there will not be one until the bag gains a map type.

AttributeValue is Bool, Int, Float, String, or StringSet. A JWT claim object is none of those. The bridge walks each claim through the same JSON flattener as custom.* and args.*:

• a scalar lands at claim.<name> with its type kept
• a scalar array, empty included, lands as a StringSet (numbers and bools rendered as strings)
• {}, null, and an array holding a nested container set no key
• a nested object sets only the children (claim.realm_access.roles), never the parent (claim.realm_access)

Client claims are the same shape under client.claim.<name>.

That is enough for every predicate the language can ask: claim.tenant == "acme", claim.realm_access.roles contains "admin". What it cannot do is treat the whole map as one value (exists(subject.claims) meaning “any claim”). Cedar still injects an empty principal.claims record so a probe of the record itself is not a missing-attribute error; individual missing claim names inside it follow Cedar’s own rules.

To put a dict in the bag would take a sixth AttributeValue variant, APL lookup into it, CEL map construction (already nested from dotted keys, so partly redundant), a Cedar record that is not string-keyed leftovers, and an OPA object. The flattened keys would still be required for the predicates that exist today. Until that type exists, claim.* / client.claim.* are the policy surface, and SubjectExtension.claims remains the typed form plugins read.

What each decision point does with a missing key

require inverts its predicate and denies when that inversion is true, so the APL row above splits require on a missing key:

Authors who need the denylist to stay closed when the key is missing write require(exists(claim.tenant) & claim.tenant != "acme").

A policy written against a present-empty set therefore agrees — including when Cedar and CEL both read subject.roles. A policy written against an omitted claim scalar agrees on the verdict (all Deny) for ==, order, and membership, and is an AgreeDeny in ppe-pdp-diff; the cause still differs. != and not in do not agree across all four engines: they are missing-claim-not-eq / missing-not-in on the allowlist. A flattened bool whose namespace was never written (unguarded CEL role.hr with no role.* keys), or a missing subject.id, is the missing-collection / missing-subject-id class of split.

The twelve slots

Keys listed always are written whenever the slot (and, where noted, the sub-record) is present. The rest are omitted when the field is None or the map has no entry.

1. security — SecurityExtension

Subject (sec.subject present):

Client (sec.client present):

Workload (caller_workload / this_workload; same shape, two namespaces). These are not agent.*. agent.* is session context.

attested_at is not in the bag. request.timestamp and completion.created_at are carried as plain strings, so the bag does not refuse timestamps; unifying the three is out of scope here.

Other, written whenever the security slot itself is present:

security.objects and security.data are not in the bag. Both live on SecurityExtension, and filter_extensions copies them to every plugin (unrestricted sub-fields). The bridge does not flatten ObjectSecurityProfile or DataPolicy (apply_labels, allowed_actions, denied_actions, retention). Plugins that need them read the typed slot. The static data: payload tree (data.* keys) is a different source; see Payloads that are not slots.

capability_namespaces maps read_* capabilities to bag prefixes. read_labels unlocks security.labels; read_workload unlocks caller_workload.* and this_workload.*. Nothing writes a workload.* prefix.

2. delegation — DelegationExtension

Per-hop scopes, audience, and strategy stay on the typed chain.

3. agent — AgentExtension

conversation.history is not flattened.

4. meta — MetaExtension

5. request — RequestExtension

A default request slot adds nothing.

6. http — HttpExtension

7. llm — LLMExtension

8. mcp — MCPExtension

Tool present:

Resource present:

Prompt present:

Schemas and annotations are not flattened.

9. completion — CompletionExtension

10. provenance — ProvenanceExtension

11. framework — FrameworkExtension

12. custom — HashMap<String, Value>

An empty map adds nothing.

Payloads that are not slots

These use the same walker and the same absent-value rules, but they are not extract_extensions slots: