We audited how 30 popular AI agent projects handle authorization. The results are alarming: nearly all of them rely on unscoped API keys with no per-agent identity, no user consent, and no revocation mechanism. Published March 15, 2026 · BySanjeev Mishra· Grantex Research We analyzed 30 of the most popular open-source AI agent projects on GitHub, representing over500,000 combined stars. For each project, we evaluated six authorization capabilities: We reviewed each project's documentation, source code, configuration files, and example applications. Projects were evaluated on their built-in authorization mechanisms, not on what a developercouldbuild around them. 28 out of 30 projects (93%) rely exclusively on environment-variable API keys for authorization. The standard pattern is: This key grants the agent the same permissions as the key owner. There is no mechanism to restrictwhichoperations the agent can perform,on whose behalfit acts, orwhenthe access expires. Not a single project we reviewed assigns a unique, cryptographically verifiable identity to each agent instance. When multiple agents share the same API key (which is the default configuration), it is impossible to determine which agent performed which action. 29 out of 30 projects (97%) have no mechanism for the end-user to approve what the agent is doing on their behalf. The developer decides what the agent can access at build time, not the user at runtime. The one partial exception is LangGraph's human-in-the-loop feature, which pauses execution for approval but does not issue scoped authorization tokens. Every project we reviewed treats revocation as a binary: rotate the API key, or don't. There is no way to revoke access for a single agent while leaving others operational. In multi-agent systems (which are the explicit use case for frameworks like CrewAI and AutoGen), this means one misbehaving agent forces a full credential rotation. Only 4 projects (13%) include any form of action logging. Where it exists, it is opt-in, application-level, and not tied to an authorization grant. No project produces an audit trail that links a specific action to a specific agent, a specific user authorization, and a specific set of scopes. In multi-agent frameworks (CrewAI, AutoGen, MetaGPT, OpenClaw), when one agent calls another, the child agent either inherits the parent's full credentials or receives its own independent key. No project implements scope narrowing, depth limits, or cascade revocation for delegated access. Star counts as of March 2026. "Partial" indicates the feature exists in a limited form (e.g., opt-in logging, basic role separation) but does not meet the bar for production authorization. This is not a theoretical risk. Major incidents have already occurred: Censys identified21,639 exposed OpenClaw instancespublicly accessible on the internet. Misconfigured instances were leaking API keys, OAuth tokens, and plaintext credentials. With 210,000+ GitHub stars and rapid adoption, the blast radius was enormous. Source:Reco.ai BlueRock Security analyzed over7,000 MCP serversand found that 36.7% were potentially vulnerable to SSRF. Trend Micro found492 MCP servers with zero client authentication and zero traffic encryptionon the public internet. The Moltbook database breach exposed1.5 million API authentication tokensand 35,000 email addresses, demonstrating the cascading impact of centralized credential storage. Source:Wiz.io Thousands of Google Cloud API keys deployed as billing tokens were discovered to haveunrestricted access, effectively becoming live Gemini credentials on the public internet. Source:The Hacker News