# Security Policy

`@takk/krikos` is a stable (1.0.0) library for agent identity, capability
authorization, lifecycle, and audit. We take security reports seriously and aim
to acknowledge each one within two business days.

## Supported versions

Each published version follows strict SemVer (see [`SPEC.md`](./SPEC.md) §5 and
[`.github/RELEASING.md`](./.github/RELEASING.md)). Only the latest minor of the
current major receives security patches; an older major receives critical-CVE
fixes for 6 months after the next major lands.

| Package | Supported |
|---|---|
| `@takk/krikos` | current `latest` dist-tag |

## Reporting a vulnerability

**Please do not file public GitHub issues for security problems.** Send reports
to **davcavalcante@proton.me** (preferred) or **say@takk.ag** (Takk relay),
with the subject line beginning `[SECURITY]`.

Include, at minimum:

- Affected version (`npm ls @takk/krikos`).
- Reproduction steps or a minimal proof-of-concept.
- Impact assessment (what an attacker can achieve).
- Any suggested mitigation.

If your report involves a vulnerability in a third-party peer dependency, please
also link the upstream advisory (CVE, GHSA, etc.) so we can coordinate the
disclosure.

PGP / signed reports are welcome but not required. If you need an out-of-band
channel, ask in the first message and we will propose one.

## Response process

1. Acknowledgement within **2 business days**.
2. Triage and severity assignment within **7 days**.
3. Fix targeted for the next release; critical issues ship as an out-of-band
   patch on the affected minor.
4. Coordinated disclosure: the reporter is credited in the changelog and
   advisory unless they request anonymity.

## Threat model in scope

Findings in any of the following are in scope:

- **Authorization bypass.** Any path that causes `can()` or `authorize()` to
  return true for an agent that is not `active`, is past its expiry, or does not
  declare an admitting capability. Authorization is fail-closed by contract; any
  way to defeat that is a vulnerability.
- **Lifecycle integrity.** Any way to perform an illegal lifecycle transition
  (for example resuming a revoked agent, or acting as an archived one), or to
  make a revoked or expired agent authorizable again without an explicit, legal
  operation.
- **Cryptographic identity.** Any way to make `verifyAgent` or `verifyAgentCard`
  accept, against a pinned trust anchor, a forged or impersonated card (one
  signed by a key other than the pinned issuer key), a tampered card, or a stale
  signature (a fingerprint or credential version that no longer matches), or any
  flaw in the Ed25519 key handling in `@takk/krikos/a2a`. Note by design that
  `verifyAgentConsistency` / `verifyCardConsistency` only check internal
  consistency and are explicitly NOT trust checks; relying on them as if they
  were is an integration error, not a library vulnerability.
- **Audit tampering.** Any way to mutate a recorded audit event in place, or to
  edit history such that `verifyAuditChain()` still reports the chain intact.
- **State persistence.** Path traversal in the `fileState` write path; any way to
  make Krikos write outside the configured path; any way to make a corrupt
  snapshot silently overwrite recoverable state instead of being quarantined.
- **Hook and bridge safety.** Any way for a sibling bridge, store mirror, or
  telemetry listener to crash the registry or abort an in-memory operation. By
  design, listener and mirror faults are caught and never reach a caller.
- **Supply chain.** Tarball contamination, compromised npm scope, or a published
  artifact whose provenance attestation does not match the source commit.

## Out of scope

- The custody of an agent's private key after Krikos returns it from `issueSigned`
  or a signer; persisting it in your secret store is the operator's
  responsibility (Krikos never retains it).
- The strength of the FNV-1a fingerprint and audit-chain digest as a
  cryptographic primitive. These are deterministic integrity bookkeeping, not
  cryptographic non-repudiation. For the latter, use the Ed25519 signer or sign
  the snapshot out of band. This is documented, not a defect.
- Denial of service via unbounded inputs against your own application; sizing the
  number of agents (`maxAgents`) and audit growth remain the operator's
  responsibility.
- The security of any framework, store, or sibling you wire Krikos into.

## Supply-chain assurances

- **Zero required runtime dependencies.** The attack surface from transitive
  dependencies is eliminated. Siblings are optional, structural, and never
  imported at runtime.
- **Provenance.** Every release is published with `npm publish --provenance`
  (SLSA attestation by GitHub Actions). Verify with
  `npm view @takk/krikos@<version> --json | jq .dist.attestations`.
- **Lockfile committed.** `pnpm-lock.yaml` is tracked in git for reproducible
  installs.