Question: Extension types for hardware-rooted trust in autonomous agent authorization

[3du4rd0v3g4]

I'm working on authorization infrastructure for autonomous AI agent systems and have been exploring whether Cedar is the right policy layer. I think it is — but I'm missing native types for expressing hardware-rooted human accountability in policy.

Today, if I want to require that an agent's authorization traces to a hardware-bound key (e.g. Apple Secure Enclave, TPM, enterprise HSM), I have to pass raw strings through context and check them with string comparisons. This has the same problems the datetime extension solved for time — unreadable policies, no policy-write-time validation, no formal structure.

I've sketched three extension types that I think would fill this gap:

hardwareKey(string) — models a hardware-rooted cryptographic key. Constructor parses a structured token encoding binding type, vendor, FIPS security level, and enrollment timestamp. Methods: bindingType(), fipsLevel(), isHardwareBound(), isNonExtractable(), enrolledAt() (returns datetime), vendorIs().

biometricBinding(string) — models a biological authentication event with a timestamp. Methods: method(), verifiedAt() (returns datetime, composes with duration for freshness), isPhysiological(), isMultiFactor(), isBoundToOperation(), hardwareKeyMatches().

trustChain(string) — models a complete accountability chain from human principal through hardware binding to agent action and cryptographic receipt. Methods: isComplete(), hasHumanPrincipal(), hasHardwareBinding(), principalIs(), agentIs(), timestamp().

A policy requiring a complete trust chain for a financial action would look like:

permit (principal == Agent::"agent-runtime", action == Action::"executeTrade", resource == Portfolio::"investments")
when {
  trustChain(context.chainToken).isComplete() &&
  trustChain(context.chainToken).principalIs("owner@example.com") &&
  hardwareKey(context.keyToken).fipsLevel() >= 3 &&
  biometricBinding(context.bmToken).verifiedAt() > datetime(context.now) - duration("5m") &&
  biometricBinding(context.bmToken).isPhysiological() &&
  context.amount < 10000
};

All three types evaluate purely against the token string — no I/O, no external calls — which I believe satisfies Cedar's SMT and Lean modeling constraints. I'm less certain about the formal modeling requirements and would value the team's input before investing in a full RFC.

A few specific questions:

1. Is this a direction the Cedar team sees value in, or is the right answer to keep this in context strings?
2. Any concerns about the Lean/SMT modelability of structured string parsing in extension constructors?
3. Is there prior art in the Cedar ecosystem I should be aware of before drafting an RFC?

[cdisselkoen]

This feels to me like a usecase that would be better served by implementing your custom authentication logic outside of Cedar and then passing only the result in via context. But I'm interested in hearing others' opinions on whether this is generally useful such that it's worth standardizing and maintaining inside of Cedar.

[cdisselkoen]

Also relevant: cedar-policy/cedar#2126

[3du4rd0v3g4]

Thanks for the response, @cdisselkoen — and for the pointer to #2126.
If user-registered extensions become a supported path, that seems like the right mechanism for this rather than a built-in. Would that be the team's preferred direction for a use case like this?