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:

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.