Security
CAPABILITY IS NOT AUTHORITY.
Elixir exists to let AI agents recover from failure without letting them acquire permissions along the way. Two sentences govern the whole architecture: capability improvement must never silently imply authority expansion, and a more capable agent is not automatically a more privileged agent.
What follows is the architecture, not a compliance posture. There is no certification to cite and no third-party audit to point at, so this page describes mechanisms you can read in the source instead.
Models do not own authority
A model supplies reasoning. It does not decide what it is allowed to do with it. The job an executor receives is frozen, its exact key set is pinned by a test, and it carries no agent identity, organization, plan or entitlement — because an adapter answers "how do I run this", never "what is this allowed to do".
The provider never decides that its own requested operation is authorized. That sentence is the load-bearing one: everything else on this page is machinery for keeping it true.
Evidence before release
A result that says its tests passed is a claim. What a runner observed is evidence, and Elixir gates on the second. A session reporting success with no observed test execution is refused, not trusted.
Evidence carries provenance — who collected it, when, how, and whether it reproduces — so a conclusion can be checked later rather than taken on faith.
Observation is not treatment
Runtime adapters read. They have no start, no stop, no restart and no write path of any kind. Reading that a service is down is a different capability from doing something about it, and they are different systems.
This is why Elixir can be installed on a production host before anyone has decided it may change anything there.
Identity is issued, never derived
An Elixir Agent ID is minted once and never reused. It is not derived from a hostname, a process id, a repository, a display name or a provider — all of which change, and none of which is an identity.
A reused identifier would silently transfer one agent’s history to another. Issuing rather than deriving is what makes an audit trail mean something a year later.
Organization isolation
An incident belongs to an organization and an agent, and those are immutable for its lifetime. A key scoped to one organization cannot read another’s incidents, results or evidence — a cross-organization read returns the same not-found response as an id that does not exist, so the boundary does not leak existence.
Approval boundaries
Some gates require a human, and they require a specific human: an approval is signed under an approver’s own key, and it is refused if it comes from a principal the policy does not name, if the signature does not verify, if it names a different result, or if it claims a gate no approval may satisfy.
An approval satisfies a named gate and then release eligibility is re-evaluated in full. It clears no defect and changes no permission. It cannot be given by a worker, by Elixir, or by the principal that deployed the code.
Provider credentials stay yours
Credentials are read from the environment or your secrets manager. They are not stored in configuration, not proxied through a service operated by anyone else, and not required by AgentDoctorMD — there is no hosted service to send them to.
Elixir is self-hosted. Your prompts and workspace contents go to the provider you configured, and to nobody else.
No silent provider fallback
If the configured executor is unavailable, Elixir refuses. It does not try the other one that happens to be installed. A fallback would mean your workload silently ran on a provider you did not choose, under a data-routing arrangement you did not agree to.
Independent verification
The session does not grade itself. Elixir re-runs what the session claims passed, using an oracle the provider did not control, and a provider exiting zero is never accepted as proof.
This is the mechanism whose failure would be least visible, so it is the one held to the highest standard: `completed` means Elixir’s verification accepted the outcome, never that a process exited successfully.
Fail closed
Missing authority never becomes implicit authority. An unreadable store is an unknown, not an empty one — a corrupt ledger is never read as a clean board. A check that cannot look reports that it could not look, and unknown is never upgraded to pass for lack of evidence.
What holds it together
THE INTERFACES HOLD NO TREATMENT AUTHORITY
Both public entry points can report and read. Neither can approve, execute or deploy — and that is structural rather than a matter of configuration.
incidents:create
incidents:read
agents:read
# There is no approval scope, no execute scope
# and no deploy scope. A key cannot be issued one,
# because none exists to issue.elixir_approve ✗ does not exist
elixir_execute ✗ does not exist
elixir_deploy ✗ does not exist
elixir_restart ✗ does not exist
elixir_shell ✗ does not exist
elixir_modify_production ✗ does not exist
# mcp/ imports nothing internal, and does not know
# the words "billing" or "entitlement".Read the mechanisms yourself: the documentation index, or the pre-production checklist.
Reporting a vulnerability
Elixir is an open-source alpha. If you find a security issue, please report it privately through the repository’s security advisory process rather than opening a public issue, and give us a reasonable window to fix it before disclosure.