SecurityProduct controls and current limits
Security claims below describe controls visible in the current code and release process. They do not represent an independent certification, a guarantee about every deployment, or a substitute for customer configuration and review.
The desktop flow uses a browser approval handoff and a scoped application session. Source uses the operating-system credential vault for session persistence; the exact packaged keychain journey remains unverified. Provider credentials remain connector-specific, and no privileged shared secret belongs in a distributed installer.
Implemented with documented gap
The domain model separates review, approval, merge, workflow dispatch, environment approval, and change management. UI visibility alone is not treated as authorization; each consequential service path still requires server-side enforcement and release verification.
Implemented in product model · verification ongoing
Contact and operational text passes through secret-redaction utilities before durable storage or notification. Live connector credential custody, revocation, and recovery are verified provider by provider—not inferred from a generic security claim.
Application controls implemented
Audit and evidence models record actors, actions, timestamps, rationale, and outcomes where the selected workflow is wired. Export availability and retention vary by workflow and are not evidence of an external certification.
Implemented in supported workflows
Security posture
These are product design principles, not a claim of military certification, HIPAA compliance, CMMC compliance, FedRAMP authorization, or a customer's completed risk assessment.
Connections and service paths are scoped to the smallest authority the supported workflow needs. A recorded connection is not treated as live until it is validated.
Approval, execution, validation, and closure remain distinct decisions. A convenient interface state is never used as proof that production authority exists.
Secrets stay server- or operating-system-bound where the supported path requires them. Browser and desktop surfaces do not expose provider credentials as product data.
Axiom keeps version, actor, decision, and validation context close to the release record so teams can review what happened instead of relying on a status label.
For healthcare and other regulated environments, Axiom must be deployed with the customer's required agreements, vendor review, identity controls, retention rules, incident process, and independent compliance evidence. Product controls can support that work; they do not replace it.
Use the verified support address or review the detailed security documentation.