—Trust · Permissions
Each capability has its own authority boundary.
Signing in, reading a repository, proposing a write, approving it, and deploying are separate permissions. Axiom does not treat one successful connection as authority for everything else.
Fail closed
01
Workspace roles
Workspace membership establishes the tenant boundary. Administrator-only actions—such as approving Agent writes and managing sensitive configuration—are checked again at the server route that performs the action.
02
GitHub repository scope
The GitHub App installation determines which repositories are available. For a repository action, the service mints a short-lived token scoped to the selected repository rather than reusing a broad user token.
03
Agent authority
The decision loop may execute registered low-risk reads. Medium- and high-risk tools create proposals. The approval responder—not the model—invokes the real write after an authorized administrator approves it.
04
AWS ECS authority
Axiom dispatches the tenant workflow; GitHub Actions OIDC assumes the environment's configured AWS role. AWS permissions therefore remain constrained by both the GitHub trust subject and the role policy.
Trust questions
Does sign-in grant GitHub write?
No. GitHub installation, repository scope, role checks, and approval are separate.
Can the model approve itself?
No. The model only returns a decision; approval is an authenticated administrator action.
Is AI on by default?
No. Workspace provider policy is opt-in and fails closed.
Does Axiom store an AWS access key?
Not for the released ECS path. The tenant workflow uses OIDC.
Can risk be lowered by context?
No. Context can only escalate a tool's baseline risk.
Are identity providers active after configuration?
No. They remain pending until a real identity flow is implemented and verified.
Still blocked?
Include the failed step and error. Never send a password, token, or cloud secret.