Question: Time-limited policies for agentic authorization

[clawdreyhepburn]

Context

I'm building Carapace, a Cedar-based authorization proxy for AI agent tool access (MCP). One pattern that comes up constantly in agentic workflows is time-scoped permissions — granting an agent access to a tool or resource for a bounded period, after which the permission should automatically cease.

The problem

Cedar has excellent datetime/duration support (RFC 80), and I can write policies like:

permit(
  principal == Jans::Workload::"agent-47",
  action == Jans::Action::"call_tool",
  resource == Jans::Tool::"filesystem/write_file"
) when {
  context.now.timestamp < datetime("2026-03-10T00:00:00Z")
};

This works, but it has several practical issues for agent authorization:

1. The policy persists after expiry. It still exists in the policy store, still gets evaluated, and still participates in analysis — it's just permanently false. Over time, expired policies accumulate as dead weight. In agentic systems where permissions are granted and revoked frequently (sub-agent spawning, task-scoped access, incident response), this accumulation is rapid.

2. No way to distinguish "expired" from "not yet active." A policy with a datetime condition is either currently true or currently false. There's no metadata that lets a policy management layer know why it's false, or whether it should be cleaned up.

3. Relies on the application always providing context.now. If the application forgets to include context.now in the context, datetime conditions silently fail (the policy errors and is skipped). For security-critical agent authorization, silent failure modes are concerning.

4. Analysis doesn't understand temporal intent. When I use Cedar's SMT-based analysis (which I wrote about in Proving It: SMT Solvers and Why I Trust Math More Than Tests), the analyzer treats the datetime condition as just another boolean expression. It can't reason about temporal properties like "this permission is guaranteed to expire" or "these two time-scoped permissions never overlap."

What I'm doing today

In my system, I work around this by:

• Removing the entity after the job finishes (for short-lived sub-agents)
• Building an application-layer TTL that deletes policy files after expiry
• Accepting that the policy store needs periodic garbage collection

As I noted in Modeling an Agent's World in Cedar: "Cedar doesn't natively support time-based conditions like 'this permission expires in 1 hour.' For short-lived sub-agents, I hack it by removing the entity after the job finishes. Native when { context.time < expiry } would be cleaner and verifiable."

What would help

I'm not proposing a specific design (happy to discuss options), but the agentic authorization use case would benefit from some way to express policy-level temporal bounds that:

• Are visible to the analyzer (e.g., "prove that no expired policy can ever permit access")
• Can be distinguished from other datetime conditions (it's metadata about the policy, not a condition on the request)
• Enable policy management tooling to identify and clean up expired policies without parsing Cedar conditions

Possible approaches (not exhaustive):

• Policy annotations/metadata — a standard annotation like @expires("2026-03-10T00:00:00Z") that the engine respects
• Policy store metadata — TTL/expiry fields in the policy store format (Cedarling's Policy Store JSON would be a natural place)
• First-class temporal scoping — permit ... valid_from("...") valid_until("...") syntax

Why agentic systems make this more pressing

Traditional Cedar use cases (IAM, application authorization) tend to have relatively stable policy sets that change through deliberate administrative action. Agentic systems are different:

• Agents spawn sub-agents with task-scoped permissions that should last minutes, not months
• Incident response grants temporary elevated access
• Tool access is often granted for a specific workflow and should automatically revoke
• The ratio of "temporary" to "permanent" policies is much higher

The datetime extension gives us the arithmetic. What's missing is the lifecycle semantics.

References

• RFC 80: Datetime Extension — provides the datetime/duration primitives
• Carapace — Cedar authorization proxy for MCP tool access
• Cedar for AI Agents: Modeling an Agent's World — discusses temporal policy gap
• Cedar for AI Agents: Proving It — SMT analysis of agent policies

[lianah]

Thanks for the detailed write-up. It's great to see Cedar being used for agentic authorization in Carapace.

On the SMT analysis point (point 4)

the analyzer treats the datetime condition as just another boolean expression

One small correction here: the SMT encoding of datetime in Cedar actually models datetimes and durations precisely as 64-bit bitvectors, with all the datetime operations (offset, durationSince, toDate, toTime, comparisons, etc.) encoded as bitvector arithmetic — not as abstract booleans. You can see this in cedar-policy-symcc/src/symcc/extfun.rs. So the analyzer can reason precisely about datetime arithmetic, including things like whether two time-scoped policies overlap or whether a permission is guaranteed to expire given a sufficiently large context.now. What it doesn't have is a notion of "this policy is intended to be temporal" vs. "this policy happens to use datetime", but that's a metadata/intent distinction, not an analysis precision issue.

On now as a language-level concept

I'd push back on the idea of Cedar having any built-in notion of "now." A core design principle of Cedar is that policy evaluation is a pure function of its inputs: the request (principal, action, resource, context) and the policy set + entities. Introducing now as an implicit input would mean the same request evaluated at different times produces different authorization decisions without that being visible in the inputs. That's a significant departure from Cedar's evaluation model and makes policies harder to reason about, test, and debug. Passing the current time explicitly as context.now is the right approach: it keeps the authorization engine deterministic and makes the time-dependence of a policy visible and testable. The "silent failure if you forget context.now" concern (point 3) is real, but it's solvable at the application layer (e.g., your authorization middleware always injects it) and via Cedar validation (the schema can require context.now to be present and you can validate the request against the schema which is something we strongly recommend).

On policy lifecycle / expiration

I agree this is a real operational concern, especially in agentic systems with high policy churn. But I think this is fundamentally a policy store concern, not a language concern. Cedar intentionally doesn't define a standard policy store format as different deployments have very different needs.

Your suggestion of using policy store metadata is exactly the right approach here, in our view. The idea of having expiration semantics live in the policy management layer rather than the language itself aligns well with Cedar's design philosophy of keeping the evaluation engine focused on authorization logic while leaving operational concerns to the surrounding infrastructure.

One pattern that builds on your suggestion and might work well in practice: when you synthesize a policy with a datetime expiration condition, also include the expiration metadata in an annotation. For example:

@expires("2026-03-10T00:00:00Z")
permit(
  principal == Jans::Workload::"agent-47",
  action == Jans::Action::"call_tool",
  resource == Jans::Tool::"filesystem/write_file"
) when {
  context.now < datetime("2026-03-10T00:00:00Z")
};

The when clause is what actually enforces the expiration at evaluation time. The @expires annotation is structured metadata that your policy store can parse to identify and garbage-collect expired policies without needing to understand Cedar's expression language. This gives you the best of both worlds: the authorization engine enforces the temporal bound correctly, and your policy management layer can efficiently manage policy lifecycle. This addresses your points 1 and 2: expired policies are identifiable via the annotation, and you can distinguish "expired" from "not yet active" by adding a corresponding @activates annotation if needed.

On the "first-class temporal scoping" approach

Something like permit ... valid_from("...") valid_until("...") would essentially be syntactic sugar that desugars to a when clause with datetime comparisons. It doesn't add expressive power. The main benefit would be making the temporal intent more discoverable — but annotations achieve the same thing without requiring a language change, and they're more flexible (you can add arbitrary metadata without new syntax for each kind).

To summarize, the operational problem you're describing is real and worth solving, but I believe it's something to handle the policy store/management layer. The Cedar language already gives you the primitives (datetime arithmetic, annotations), and the analyzer already reasons precisely about datetime constraints. What's missing is conventions and tooling arou