Short answer: Mostly no, as far as their documentation shows. We read the READMEs of 1,634 MCP servers on the curated awesome-mcp-servers list and scored each one on six things a person would need in order to stay in control of an agent’s access: how the credential reaches the agent, whether there is an approval moment, whether one agent’s access can be revoked on its own, how long the access lasts, whether it can be narrowed, and whether the server can tell which agent made a call. Among the 857 servers that document a real credential channel, 85% deliver the credential through an automated pipe such as an environment variable or a config file. 8% document a way to revoke one agent’s access on its own. 9% document a credential that expires. Two thirds document no way to narrow what the agent may do. Half take the credential through an automated pipe and document none of the five user controls we looked for.
What did we measure, and how is it different from “is there auth?”
Other groups have already measured whether MCP servers authenticate at all. A May 2026 arXiv preprint, A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, identified 7,973 live remote MCP servers and found that 40.55% expose tools without any authentication; among 119 testable OAuth-enabled servers, every one had at least one flaw. Canopii’s monthly MCP Security Index, as read on September 30, 2026, scores 31,466 servers and reports that 3% of the 3,243 live endpoints it probed declared authentication and then served their tool surface to an anonymous caller. Astrix’s State of MCP Server Security 2025 read the READMEs of 5,205 repositories and found 53% relying on static API keys or personal access tokens.
Those studies answer “does a lock exist?” We asked a different question: once the lock exists and a person hands an agent the key, can that person still see, scope, and revoke what the agent holds? That is the layer where prompt injection turns a helpful agent into an exfiltration path, and we found no published measurement of it.
So we built a rubric with six dimensions, each one a question a user could ask about their own agent:
- Credential delivery. Does the credential reach the agent through an automated channel (environment variable, config file, redirect callback), or does a person approve access each time?
- Consent surface. Is there any moment where a human approves this agent’s connection?
- Revocability. Can the user end this one agent’s access without rotating a key that other things depend on, and without redeploying?
- Credential lifetime. Static, expiring on the server’s schedule, or a duration the user picks?
- Scoping. All-or-nothing, or can what the agent may do be narrowed?
- Attribution. Can the server tell which user or agent made a given call, or does every caller look the same?
The frame is the punkpeye/awesome-mcp-servers list: 1,347 repositories fetched on July 13, 2026, plus 287 repositories added to the list by September 10, for 1,634 total. This is a curated list, so it skews toward active, popular servers, and the long tail is probably less well documented.
How do you read these numbers?
Every figure below is a statement about documentation: “the README documents X” or “the README does not document X.” We chose that form after testing our own method. When a README says nothing about revocation, a classifier can either infer “there is no way to revoke” or answer “not enough information,” and which one it picks changes from run to run. Counting only what a README affirmatively documents gave figures that held steady when we repeated the classification. Counting inferred failures did not, so we do not report them. The method section near the end has the details, including the starker numbers we threw away.
How does the credential reach the agent?
Of the 1,634 servers, 857 document a real credential channel. Of the other 777, 668 need no credential (a local filesystem tool, a public read-only API) and 109 do not document one clearly enough to classify. Everything below about credentials uses those 857 as the denominator.
84.5% of credential-requiring servers deliver the credential through an automated pipe. 585 take it from an environment variable and 139 from a config file. A further 104 (12.1%) use a redirect-based authorization flow, where the agent’s client starts the flow and receives the token at the end of it. Only 29 servers (3.4%) document a path where a person approves access per request or per session, as opposed to setting a value once.
The distinction matters because an automated pipe has no human in it after setup. The key is planted once and the agent holds it from then on. Whatever the agent is talked into doing, it does with that key, and nothing on the delivery path asks a person whether this particular agent should have it.
This was the most stable result in the study. Two independent classification passes agreed on the delivery label for 95% of sampled servers, and an earlier pass that read far less of each README produced 84.6%.
Is there a moment where a human authorizes this agent?
80.1% of all 1,634 servers document no approval step at all. No “authorize this agent” screen, no confirmation, nothing: access is implicit once the server is configured. Among credential-requiring servers the figure is 75.1%.
161 servers (9.9%) document a connection-time approval, typically the consent screen of a standard authorization flow.
The rubric also has a label for an approval step that is reachable or operable from the agent’s own execution context, such as a confirm flag or a confirmation tool the agent can call. That pattern looks like consent, but the party asking and the party approving can be the same process. The classifier applied the label to 36 servers. It was the least stable consent label between passes, so we re-read all 36 READMEs one at a time.
In 24 of the 36, the README documents a confirmation step that is completed inside the agent’s own tool call. Thirteen use a confirm flag or a fixed confirmation string that the agent passes as a tool argument. Five return a confirmation token to the caller, which sends it back on a second call. Six expose the approve or trust action as another tool on the same server. Four of the 24 say in so many words that the agent cannot bypass or skip the step. As documented, though, the input that completes the step is available to the agent. A second call shows that the call was made twice. It does not show that a person read the preview.
Three READMEs in the set state that limit themselves and describe their confirmation step as friction or defense in depth, not as a human-approval boundary. That is the accurate way to document it.
The other 12 are a mix. Two raise a dialog in the client and fall back to a value the agent can pass when the client cannot show one. One requires an approval code that the operator holds. Four are sign-in flows that the agent starts and a person completes in a browser. Three are not approval steps at all, and two do not describe the mechanism in the text we read.
Two caveats. A client’s own tool-approval prompt can still put a person in front of each call; that is a property of the client, not of the server’s confirmation step. And 24 is a floor: it counts only rows the classifier flagged, so it shows the pattern exists on the list, not how common it is.
Can the user revoke one agent’s access without breaking the others?
8.3% of credential-requiring servers document a way to end one grant on its own. That is 71 of 857. The other 91.7% do not document one.
The 8.3% is a generous count. It includes READMEs whose documented “revocation” is deleting a local credential file or removing a linked device, which ends the local copy without necessarily ending the access upstream. As a cross-check, we searched every remaining README for revocation vocabulary (revoke, deauthorize, disconnect, remove access, delete the key). Counting every such mention as if it documented single-agent revocation, the ceiling is 95 servers, or 11.1%.
Undocumented does not mean it cannot be done. A server that takes one static key from an environment variable can be cut off by rotating that key at the provider. But think about what that means in practice. A user who suspects one agent has gone wrong has to break every other integration that uses the same key, then re-plant the new key everywhere. Most people will not do that on a suspicion. They will wait for proof, and by then the access has been used.
How long does the access last?
8.8% of credential-requiring servers document a credential that expires. That is 75 of 857: 72 with a server-set expiry such as a token lifetime or refresh cycle, and 3 where the user chooses.
Those three deserve a closer look, because user-chosen duration is the control that matters most for an agent. In two of them, the choice is made on the upstream provider’s token-creation page, where the account owner sets a validity period for the key before pasting it into the server’s configuration. In the third, the duration applies to new storage keys that the agent itself can create through a tool, up to a maximum the operator sets. None of the three is a duration a user sets for one agent’s access to the MCP server. If you want to give one agent access to your account for the afternoon and have it end at six, we found no server on the list that documents that as a per-agent option.
The cross-check here is looser. Counting every README that mentions expiry, a TTL, a refresh token, or a short-lived credential anywhere, including mentions that have nothing to do with the agent’s credential, the ceiling is 24.5%.
Can the user narrow what the agent may do?
66.2% of credential-requiring servers document no way to narrow what the agent gets. The other 290 servers (33.8%) document some narrowing: 101 by tool, 82 through scopes the user selects at grant time, 64 through separate credentials per user, and 43 per action.
That third is the most encouraging number in the study, and it comes with a caveat. Most of the per-tool narrowing is an operator switch: an environment variable that lists enabled tools, a read-only flag, or a tool profile chosen when the server is started. In 82 of the 101 per-tool cases the classifier’s evidence refers to an environment variable, a command-line flag, a config setting, or a read-only or tool-profile switch. It is a real control and worth having. It is set once for the deployment, though, so every agent that connects gets the same surface, and the person whose data is at stake may not be the one who set it.
Can the server tell which agent made a call?
23.2% of credential-requiring servers document per-user or per-agent attribution. That is 199 of 857. The other 76.8% either document one credential that every caller presents or say nothing about it.
Attribution decides whether an audit log is worth anything after an incident. A log that says “the key did it” cannot answer “which agent, under what authorization?”
How many servers document none of these controls?
436 servers, 50.9% of credential-requiring servers, take the credential through an automated pipe and document none of the five user controls: no narrowing, no way to revoke one grant, no expiry, no approval step, and no per-user or per-agent attribution. On the repeat sample, the two classification passes put this figure at 52.0% and 48.1%.
How was the classification done, and how reliable is it?
This is static analysis of documentation. It measures what a server documents, not how it behaves at runtime. A server may have an undocumented revocation path, or a documented one that does not work. We did not probe any third-party server.
Each repository’s README, up to its first 30,000 characters, plus its top-level file names, was classified by a language model (Claude Sonnet 5.5, one fixed version for every row) working from a written rubric with a definition for each label. A verbatim evidence quote was required for every label, with an “insufficient data” option instead of guessing. 129 READMEs (7.9%) run to 30,000 characters or more, so any text beyond that point was not read.
We tested the method three ways and re-read one label row by row.
Repeatability. We ran the same classifier a second time on a random 200 repositories. The two passes assigned the same label in 85.8% of cells (1,029 of 1,200): 95% for credential delivery, 90% for consent, 88.5% for attribution, 82% for lifetime, 80% for scoping, and 79% for revocability. Most of the flips were between a label and “insufficient data.” For the headline figures in this post, the two passes differed by less than four percentage points.
Independent re-read. A separate reviewer pass, also a language model and blind to the labels, read 20 of the September repositories in full. It agreed with the classifier on 80.0% of cells (96 of 120). Both readers come from the same model family, so this measures agreement, not ground truth.
Quote check. For labels that credit a server with a capability, we checked mechanically that the quoted evidence appears in the README. Across all 1,634 rows it did for 71 of 78 revocation labels, 71 of 77 lifetime labels, 305 of 329 scoping labels, and 224 of 235 attribution labels.
Row-by-row review. The 36 rows carrying the agent-operable approval label were each re-read individually, in a separate pass by a different model from the classifier, and sorted into the categories reported above. The README passage behind each judgment is recorded. This is a closer reading than the batch classification, and it is still not a human audit. It does not change any label or any other figure in this post.
The numbers we threw away are part of the method too. Our first pass, in July and September, read only the first 3,500 to 4,000 characters of each README and reported that 57% of credential-requiring servers had no way to revoke a single agent and that 44% failed all six dimensions. A verification re-read exposed the truncation. When we re-ran the classification on full READMEs with one model, those two figures fell to 16% and 9%, and they moved again between repeat passes. They had been measuring how readily a classifier infers failure from a silent README. The figures in this post count only what a README documents, and they are the ones that held.
“Curated list” cuts both ways: these are the servers people actually install, which makes the findings more relevant, and they are probably better documented than the long tail.
What would user-controllable agent access look like?
Every dimension above has a concrete better shape, and none of it requires abandoning standard authorization flows. It complements them.
The person starts the grant from inside the app they already trust, in their signed-in session. On a consent page hosted for that app, they decide which operations the agent may perform and for how long. The token is shown to the person, not to the agent; the person gives it to their agent, and the agent exchanges it for a scoped access token. The agent has no endpoint that opens a consent screen. Each agent gets its own connection, so the server can name the caller on every request and the user can revoke one agent without touching anything else. Access ends at the expiry the user chose or at revocation, whichever comes first. Operations that can do damage can require a fresh confirmation from the person, bound to the exact call.
That is the model we built AgentAdmit around, and it is why we ran this study: to find out how far the ecosystem is from it. The answer, for now, is that half of the credential-handling servers on the list document none of those controls, and fewer than one in ten document a way to revoke a single agent. The gap is the product.
Frequently asked questions
How many MCP servers were analyzed in this study?
1,634 repositories from the punkpeye/awesome-mcp-servers curated list: 1,347 fetched on July 13, 2026 and 287 added to the list by September 10, 2026. Of those, 857 document a real credential channel and form the denominator for credential-related figures.
What percentage of MCP servers document a way to revoke a single agent’s access?
8.3% of credential-requiring servers (71 of 857) document a way to end one grant on its own. The other 91.7% do not document one. Counting every README that mentions a revocation keyword anywhere raises the ceiling to 11.1%.
Do any MCP servers let the user choose how long an agent’s access lasts?
Three of the 857 credential-requiring servers (0.4%) document a user-chosen lifetime, and none of the three is a duration set for one agent’s access to the MCP server: two rely on the validity period chosen on the upstream provider’s token page, and one concerns keys the agent creates through a tool. 8.8% document a credential that expires at all.
Is this study based on live testing of MCP servers?
No. It is static analysis of each repository’s README and top-level file names, so it measures documented capability, not runtime behavior. No third-party server was probed. Labels were assigned by a language model working from a published rubric; two independent passes of that classifier agreed on 85.8% of labels, and the headline figures moved by less than four percentage points between passes.
Is a confirm flag on an MCP tool the same as human approval?
Not by itself. Of the 36 servers flagged for an agent-operable approval step, 24 document a confirmation that is completed inside the agent’s own tool call: a confirm flag or fixed string, a token returned to the caller, or an approve tool on the same server. A second call shows that the call was made twice, not that a person approved it. A client-side approval prompt can add that, and it is a property of the client.
How can I reproduce the numbers?
Every figure in this post is printed by committed scripts over one classification file. The rubric, the repository list, the scripts, and the aggregate counts are published at github.com/PhoenixCo-Founder/mcp-user-controllability-study. The per-repository label file is available to researchers on request at christopher@agentadmit.com, so that no individual server is singled out.
If you run an MCP server and want your users to be able to see, scope, and revoke what their agents hold, AgentAdmit is the hosted layer for that: user-started grants, per-agent connections, user-chosen duration, confirm-each-time on sensitive actions, and a tamper-evident audit ledger. Patent pending. Build and test on a test key.