—ReleaseOps · Connectors
Integration boundaries.
What Axiom can currently connect, what each connection is allowed to see, and the checks required before it is treated as active.
The model: consent is not proof
GitHub
- Auth method: GitHub App installation for selected repositories
What Axiom reads
- · Selected repository metadata
- · Release evidence configured for a deployment request
- · A harmless read-only validation after installation
What Axiom does NOT read
- · Repository secrets or Actions secret values
- · Credentials or private keys
- · Write access to repositories, pull requests, workflows, or deployments
An installation is not shown as validated until Axiom completes its scoped, read-only check. A workspace owner can stop Axiom from using the recorded installation; removing the GitHub App remains a GitHub-side action.
Slack
- Auth method: Browser OAuth, only when an Axiom-managed Slack app is configured
What Axiom reads
- · The minimum workspace context needed to validate the consent
- · Only the scopes shown before consent
What Axiom does NOT read
- · Slack passwords
- · Unrelated workspace data
- · A connection status inferred only from a browser return
Consent is tenant-bound, one-time, encrypted at rest, and starts as awaiting validation. Messaging is not represented as active until a live validation succeeds.
Microsoft identity
- Auth method: OAuth with PKCE, only when an Axiom-managed Microsoft app is configured
What Axiom reads
- · Basic identity needed to verify consent
- · Only the consented scope shown in the Microsoft authorization flow
What Axiom does NOT read
- · Microsoft or Teams passwords
- · Teams messages or files by default
- · An active connection without server-side validation
The PKCE verifier and returned credential are encrypted and bound to one tenant and one callback. Teams messaging is not yet a live Axiom capability.
Other delivery systems
- Auth method: Not connected
What Axiom reads
- · Nothing until Axiom publishes and validates a dedicated, least-privilege connector
What Axiom does NOT read
- · GitLab, Azure DevOps, Jenkins, Argo CD, ServiceNow, CI/CD, observability, or ticketing credentials
These systems may be evaluated where they reduce release handoffs or improve evidence, but are not represented as available integrations today.
Revocation and revalidation
- Workspace owners can revoke Axiom's recorded use of a connection from the governed connection record.
- Provider-side removal remains the source of truth: remove the GitHub App or revoke the OAuth grant in the provider when access must end there too.
- Validation timestamps distinguish a recorded consent from an active, reachable integration.
- Do not treat a webhook, browser success screen, or cached status as proof of a live connection.
Trust questions
What does Axiom access?
Only the minimum provider facts named above, after a workspace owner starts a scoped consent flow. The initial GitHub release-evidence path is read-only.
Where are provider credentials handled?
On Axiom's service boundary, encrypted at rest. They are not returned to the browser or written into release evidence.
Is Axiom certified for regulated environments?
No certification is implied here. Regulated use needs your own risk review, agreements, identity controls, retention policy, and independently verified evidence.
Can access be revoked?
Yes. Stop Axiom's recorded use from the workspace and revoke the provider-side grant or App installation when access must end at the provider too.
Which other tools are supported?
No other delivery-system connection is claimed here until it has a dedicated consent lifecycle, least-privilege scope, validation, revocation, and audit path.
What happens when validation fails?
Axiom must show the connection as needing attention or awaiting validation—not as connected—and avoid treating its data as current release evidence.
Still blocked?
Include the failed step and error. Never send a password, token, or cloud secret.