Security objective
CALI centralizes a high-impact decision: which approved mechanism, key and provider execute an operation. That improves governance only if the policy path, broker, adapters, key custody and evidence channel are independently protected.
Required failure behavior
CALI fails closed for:
- ambiguous or expired policy;
- authentication or authorization failure;
- missing algorithm or provider capability;
- invalid key state, usage, tenant or protection level;
- unknown or unsupported operations;
- idempotency conflicts; and
- provider failures that prevent the resolved operation.
Availability pressure never authorizes downgrade.
Key and secret handling
Private keys are opaque by default. Requests, examples, logs and evidence must not include private key material, bearer tokens, complete sensitive payloads or unrestricted provider diagnostics. Public keys and certificates may be returned only when the operation and caller permit it.
Policy threats
An attacker who can modify policy can redirect operations, weaken parameters, select a compromised provider or extend a transition window. Policy must therefore be authenticated, versioned, scoped, expiring, auditable and protected against rollback. The broker must pin the resolved version for the complete operation.
Adapter and provider threats
Adapters are security boundaries. They can mis-map algorithms, ignore non-exportability, truncate parameters, suppress provider failures or report capabilities inaccurately. Implementations need adapter-specific tests, negative vectors, least privilege, isolation and evidence reconciliation.
Evidence threats
Evidence can become a data leak or tampering target. Access must be authorized, fields minimized, integrity protected, retention bounded and correlation identifiers designed to avoid exposing secrets.
Non-goals
CALI does not make weak algorithms strong, compromised providers trustworthy, incompatible protocols interoperable or migration automatic. It does not replace certificate policy, relying-party validation, secure software development, provider certification or cryptographic review.
Reference implementation warning
The checked-in service uses an in-memory development provider. It is useful for testing contracts and failure behavior, not for protecting production keys.