feat(sensitive): record credential-free handle lifecycle evidence

[seonghobae]

Partial implementation of #10.

Buyer/security gap

OriginWeave's protected-main sensitive-data policy already binds purpose, destination, classification, expiry and bounded handle-use authority, and its evidence crate records credential-free access decisions. The next bounded gap was lifecycle evidence for an opaque sensitive-value handle: issuance, expiry, use limit, observed resolution count and revocation must be auditable without putting the opaque handle token or the protected value into evidence.

Scope

This PR adds that narrow immutable value object to the existing originweave-evidence crate. It intentionally does not add a new workspace crate or modify Cargo.lock because current repository governance does not authorize scheduled lockfile changes for this task.

SensitiveHandleLifecycleEvidence records only request ID, policy decision ID, trusted issuance/expiry epochs, maximum uses, observed resolution count and optional trusted revocation epoch. It has no field for an opaque handle token and no field for raw/protected data.

Validation fails closed for invalid/bounded identifiers, zero/non-increasing lifetimes, zero use limits, over-limit resolution counts and revocation outside the handle lifetime.

TDD evidence

RED/GREEN evidence was established through exact-head repository Actions because the local execution container could not resolve github.com for an exact checkout.

1. Test-only head b6b5b2746f4319454d6abf996f731291f8e77799 first exposed a rustfmt setup defect; that was not counted as RED.
2. After formatting, CI run 31357517628 reached cargo check --locked --workspace --all-targets and failed exactly because SensitiveHandleLifecycleEvidence and SensitiveHandleLifecycleEvidenceInput did not exist: valid production-boundary RED.
3. The production object/export was added in the existing evidence crate.
4. Tests cover active/revoked handles, every identifier predicate boundary, lifetime ordering, zero/over-use limits, revocation bounds, all public getters and absence of secret/handle material from debug evidence.
5. Intermediate heads exposed and removed repository-contract defects only: rustfmt import/order differences and forbidden test expect() usage.
6. Current exact head 0f07fea031090c72a448fd9501b49d4dd7568419 is mergeable against live protected main 67af7c87589edc2039545af335c95064d9b8391c and has exact-head CI 31358358734, Security Scan 31358358708, and SAST Semgrep 31358358727 all successful. CodeRabbit exact-head status is successful and no inline review threads are currently returned.

No predecessor-head check or review is being transferred to the current head.

Explicit non-scope

This is not the trusted broker. It does not implement or claim protected-value storage/encryption/KMS, raw value resolution/fill, opaque-handle token storage, atomic use reservation/enforcement, revocation enforcement, cross-process/tenant persistence, model/provider/region disclosure policy, hash-chained durable audit sequencing, or the planned standalone originweave-sensitive-data authority/service crate.

Those remain open under #10. A stale scaffold branch for the standalone crate exists but is not reused or presented as current implementation evidence. Issue #10 now contains a lineage comment linking this bounded slice and explicitly warning against duplicate scaffold/broker work.

This PR must not close #10 and cannot be called shipped until protected integration and every applicable exact-head gate pass.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 27 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 76ea0b38-0fc8-47ab-b191-0a87e479c360

📥 Commits

Reviewing files that changed from the base of the PR and between 67af7c8 and 0f07fea.

📒 Files selected for processing (4)

• crates/originweave-evidence/src/lib.rs
• crates/originweave-evidence/src/sensitive_access.rs
• crates/originweave-evidence/src/sensitive_handle_lifecycle.rs
• crates/originweave-evidence/tests/sensitive_handle_lifecycle_evidence.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}