Good point on credential resolution. You're right — static API keys in env/context are the weakest link in agent auth today.
AgentBadge currently checks whether authentication exists and is documented, but we're working toward a rule that distinguishes session-scoped credentials from static keys. The shift from "does the agent have a key" to "can the agent prove who it is for this operation" fits naturally into the rules → evidence → assertion pipeline.
A concrete check could verify: (1) does the API support scoped/token-based auth vs static keys, (2) are credentials passed via headers (not query params), (3) does the API document session expiration and rotation. That makes credential vault usage a measurable property, not an assumption.
Would be interested to hear how you'd define a check for credential vault vs plaintext key passing — that could be a real rule in the next ruleset version.
The measurement framework makes a strong case for reproducible, evidence-based scoring over LLM opinions. Authentication being one of the four pillars is exactly right. An agent cannot authenticate autonomously if the credentials it receives are static API keys with no scope or session identity. The credential resolution step is where most agent-authentication chains break today. An agent is given a key as a string, stores it in context or env, and that key leaks on the first instruction override or tool hallucination. The fix is not better documentation. Its a credential vault that resolves secrets without ever exposing them as plaintext, scoped per request with session-level identity. That shifts authentication from whether the agent has a key to whether the agent can prove who it is for this specific operation. The same reproducibility principle applies: same agent, same identity, same scope, same outcome. Session-level identity is what makes agent authentication verifiable rather than assumed, and thats the pattern that programmable wallets and credential vaults are already using.