mirror of
https://github.com/hanzoai/dev.git
synced 2026-10-25 03:32:32 +00:00
zeekay
dbb650041c
create_hanzo_provider() read exactly one variable, HANZO_USER_KEY — the bearer a person's `hanzo auth login` fills in. No service has one. Measured in a live sandbox pod (hanzo-sandboxes/blue-ms-e2), `dev exec` for a perfectly authenticated caller reported: ERROR ... Authentication expired. Authentication required. Run `code login` That caller held an IAM token. It was refused because the only credential the provider would look at is the one that exists on a laptop and never in a pod. So the provider now declares alt_env_keys — HANZO_API_KEY (an org key) and HANZO_MACHINE_TOKEN (the bearer an IAM machine identity holds after the client_credentials exchange) — and api_key() tries those BEFORE env_key. MACHINE FIRST IS THE DELIBERATE PART. Where both are present the process was started BY something, and the credential it was handed is the one that should be billed and audited; a stale human key left in an environment must not quietly outrank the identity the caller actually presented. alt_env_keys is empty for every other provider, so nothing changes for them, and it is skipped on serialize so no config file grows a field it does not use. Two tests pin it: the provider must read both machine names, and HANZO_API_KEY must be tried before HANZO_USER_KEY.