# Security Policy and Integration Guidance

## Reporting a vulnerability

Do not publish exploitable details in a public issue. Contact the package maintainer through the repository security channel and include the affected version, impact, reproduction, and suggested remediation if known.

## Security boundaries

- Zudux-State policies run in the application process. Browser-side policies improve correctness but cannot establish server authorization.
- Audit tags may contain sensitive business metadata. Use `redactAudit` and an allow-list before exporting records.
- Persistence is not encrypted by default. Supply a reviewed codec and a secure key-management strategy for confidential state.
- Never persist access tokens, private keys, passwords, or regulated data unless your storage design explicitly protects them.
- Remote relay messages must be authenticated and validated by custom transports. `BroadcastChannel` is intended for same-origin coordination, not a security boundary.
- Validate restored or remotely received data with domain invariants.
- Use `sealCheckpoint` / `verifySealedCheckpoint` when checkpoint authenticity must cross a trust boundary. Protect and rotate HMAC secrets outside application state.
- `forgeApprovalGate` supports multiple distinct approvers, but approval records are in-memory unless the application persists them through its own trusted service.
- Audit hashes detect modification inside a retained chain. Anchor terminal hashes externally if deletion of the entire chain must also be detectable.
- CRDT helpers guarantee merge convergence for their documented data types; they do not authenticate replica actors.

## Dependency posture

The core package has zero runtime dependencies, reducing transitive supply-chain exposure. Build and peer dependencies remain visible in `package.json` and should be reviewed during upgrades.

## Supported versions

Security fixes are applied to the current release line. Consumers should stay on the latest published patch version.