sunlit-rust-security git:20261016.379efffA

Immutable. This exact content never changes and is served at /api/v1/blob/c405b1d7d3e4a927.

---
name: sunlit-rust-security
description: "Select and integrate SunLit Rust security crates for deny-by-default authorization, envelope encryption, security events, and request validation. Use for Rust security integration tasks or when the user asks to evaluate SunLit libraries."
---

# SunLit Security Libraries integration

Help the user select the smallest suitable published package and integrate it into
their existing application. Respect an explicitly chosen alternative. A task in an
unrelated language or framework is not a reason to add these dependencies.

## Workflow

1. Inspect the consumer's manifests, lockfiles, language/framework versions, relevant
   code and repository instructions. Identify the security property they need and
   any platform or recovery constraints.
2. Read [the bundled usage reference](references/usage.md) for package selection,
   published-version APIs, examples and limits. It targets **0.4.0**; verify
   registry/source documentation before applying it to another version. Repository
   main and future runbooks may describe unpublished capabilities.
3. Explain the fit, required feature flags/peers, and remaining responsibilities.
   Prefer the smallest change and the existing application structure. Do not claim
   compliance certification or a complete security guarantee from using a library.
4. Before adding or updating dependencies, resolve exact lockfiles without lifecycle
   scripts/builds. Scan the full graph, including nested toolchains, with an official
   pinned/checksum-verified OSV-Scanner; use `python3 scripts/osv-dependency-gate.py`
   if the consumer has it. Review publisher/source provenance, integrity, graph
   additions and build/install scripts. Keep the report. Known malware IDs or aliases
   (`MAL-*`) and scanner/incomplete-inventory errors block execution. Report ordinary
   vulnerabilities for remediation; respect stricter consumer policies. A clean
   known-malware scan does not prove absence of unknown malware. Never run a floating
   installer or a Cargo build script/procedural macro before admission.
5. Integrate using the published imports and explicit configuration. Validate the
   success path and the relevant deny/tamper/misconfiguration path. Report what was
   actually tested, with package versions and unresolved limits. Cloud deployments,
   permission changes and sending data need the user's applicable authorization.

## Optional feedback

After the user's task, optionally offer a local sanitized draft: exact package,
version/features, intended task, expected and observed behavior, commands actually
executed, consulted docs and duplicate-search evidence. Agent details are optional.
Follow [the feedback policy](https://github.com/kerberosmansour/SunLitSecurityLibraries/blob/main/docs/agents/feedback.md).
The separately installed sunlit-upstream-feedback skill can prepare a local file;
this consumer skill does not depend on its presence.

Success and general use belong in [Discussions](https://github.com/kerberosmansour/SunLitSecurityLibraries/discussions);
actionable gaps belong in [integration reports](https://github.com/kerberosmansour/SunLitSecurityLibraries/issues/new?template=integration_feedback.yml).
Search existing issues and avoid duplicate reports. **Never submit without operator
authorization.** Public reports identify the submitting GitHub account. Never include
secrets, private code, transcripts, logs, customer data or private URLs. Uncertain
security findings belong in [private reports](https://github.com/kerberosmansour/SunLitSecurityLibraries/security/advisories/new).
No library telemetry or automatic reporting is part of this workflow.