# Security Policy

## Reporting

Report vulnerabilities privately to the maintainers. Do not publish exploit
details, proof-of-concept payloads, or affected deployment identifiers before a
fix is available and affected operators have had time to update.

Include:

- affected crate, binary, transport, profile, or connector;
- reproduction steps and payloads;
- expected impact;
- whether credentials, customer data, or model outputs are exposed;
- any known mitigations.

## Supported Versions

| Version | Security support |
|---|---|
| `1.0.x` | Supported |
| `< 1.0` | Not supported |

Security fixes are applied to the current `1.0.x` release line and mainline.
Protocol version support does not qualify an arbitrary deployment: operators
must still validate the exact image, identity provider, storage topology,
connectors, and external services they promote.

## Security Boundaries

AIP treats these as separate trust boundaries:

- native AIP participants;
- compatibility profiles such as MCP, A2A, and signed webhooks;
- transport bindings such as HTTP, SSE, WebSocket, and NATS;
- product connectors such as Dify, CrewAI, Chatwoot, and Hermes Agent;
- human operators and escalation channels;
- external LLM providers.

Do not collapse these boundaries in application code. A connector translating a
trusted product event is not automatically authorized to invoke every AIP
capability.

## Required Controls

- Authenticate transport peers before granting high-risk capabilities.
- Bind every authenticated transport identity or trusted `did:key` to a
  server-owned `Principal`; never authorize `Envelope.from` by assertion alone.
- Verify HMAC webhook signatures using constant-time comparison.
- Verify signed native envelopes over canonical JSON bytes.
- Reject replayed message ids through a durable, TTL-bounded replay registry.
- Use idempotency keys for retried external deliveries.
- Enforce timestamp skew for webhook deliveries.
- Redact secrets and raw product payloads before logging.
- Keep capability authorization explicit and auditable.
- Do not pass connector API keys through shared context unless required.
- Scope provider tokens to the smallest endpoint and lifetime possible.
- Treat model output as untrusted input when it is routed to tools or channels.
- Use NATS accounts, credentials, and subject permissions to restrict
  `aip.v1.{trust_domain}.{service}.{version}.>` subscriptions and request
  publishers.
- Bind approval decisions to the authenticated actor and require durable
  approval authority, expiration, evidence, and transition fencing.
- Restrict callback destinations by explicit host allowlist, reject userinfo,
  redirects, private addresses, and DNS rebinding, and sign callback payloads.
- Encrypt A2A push credentials at rest and rotate the encryption key under a
  deployment-controlled migration procedure.

## Secret Handling

Secrets should enter the process through environment variables, secret stores,
or deployment-specific configuration. They must not be committed to fixtures,
examples, schemas, conformance payloads, or logs.

Connector crates should store only the minimum secret needed by their outbound
client. Shared runtime structures should carry references, scopes, or redacted
metadata rather than raw tokens.

`aipd` is secure by default: it listens on loopback, requires signed native
envelopes, and accepts a signer only after an explicit DID-to-principal binding.
For HTTP operator access, configure `--native-bearer-token` and a
server-controlled `--native-principal`. The
`--allow-insecure-development` switch is restricted to loopback listeners and
must never be used as a production authentication mode.

Callback signing seeds, A2A credential-encryption keys, native/MCP bearer
tokens, connector credentials, and database URLs are secrets. Pass them through
the deployment secret store or environment and avoid command-line arguments in
multi-user process environments where process listings are not private.

## Release Gates

Public releases should pass:

```sh
cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features
cargo test --workspace --no-default-features
cargo doc --workspace --all-features --no-deps
```

Public release candidates should additionally run the optional tools documented
under `tools/ci/README.md`: `cargo nextest`, `cargo deny`, `cargo audit`,
`cargo machete`, `cargo semver-checks`, and `cargo fuzz`.