Top findinglow
Authorization server advertises a JWKS URI
When authorization server metadata is discovered, it advertises a `jwks_uri` so clients can verify token signatures. Required for any authorization server issuing signed tokens.
Passive scan summary
https://serenialabs.space/api/mcp
Scanned May 3, 2026 · 17:51 UTC
Review
Review before connecting
1 of 16 check needs a closer look. 15 passed.
See findings
Score & signals
- GradeB · 87/100RiskmediumConfidencelowCoveragenone
Public passive · 0 tools · 15 of 16 rules passed · auth required· 0R · 0W · 0D
Why this verdict
The signals that drove the score, in plain language.
- 01Insufficient probe coverage to evaluate the server
- 02Authorization server metadata does not advertise a jwks_uri
View rule
Recommended actions
What to do before you connect this server.
Recommended next actions
- mediumTreat this score as limited until coverage improves
Coverage is none and confidence is low. Rescan, try a different MCP path, or fix upstream errors before relying on the verdict.
Category breakdown
Six trust dimensions, each tagged Observed, Inferred, or Derived.
Observed
Transport and endpoint hygiene
8/8 checks passed (4 n/a) — 100%.
100%
8/8 passed · 4 n/a
Observed
Auth discovery posture
7/8 checks passed, 1 failed — 94%.
94%
7/8 passed · 1 failed
Not evaluated in this scan (3)showhide
- MCP protocol hygiene— Whether the server cooperates with the MCP handshake — protocol version, schemas, and tool surface size.
- Capability risk— Heuristic risk inferred from the public tool surface — destructive verbs, credential access, code execution, PII handling.
- Transparency and operability— Whether the server identifies itself and documents its tools so an operator can audit it without invoking it.
Tool risk surface
Per-tool capability and risk inferred from each tool’s name, description, and schema. No tool was invoked.
The server returned no tools.
Findings
Per-rule evidence, then the full rule list. Failing rules first.
Evidence per failing rule
- Evidence
{ "observed": [], "__applicable": true, "__observationKind": "observed" }LimitationInferred from a passive probe — AgentReserve never invoked the tool or sent credentials, so behaviour at call time is not observed.
RemediationPublish a JWKS document and advertise `jwks_uri` in your authorization server metadata.
Standards alignment
MCP protocol
passServer identity, protocol version, and TLS transport — the MCP-level signals a client needs before it talks to the server.
Linked rules (3)
- transport_uses_httpsobserved
- initialize_advertises_protocol_versionobserved
- initialize_advertises_server_infoobserved
Standard requirements (5)
- MCP HTTP endpoint is reached over TLSMUST
MCP Authorization spec — 'Authorization servers and resource servers MUST be served over HTTPS'; matches OWASP ASVS V9 transport requirements.
- Endpoint advertises HSTSBEST_PRACTICE
RFC 6797 — HTTP Strict Transport Security; OWASP ASVS V9.1.
- MCP HTTP transports must be reached over HTTPS when authorization is in useMUST
MCP Authorization spec — 'Authorization endpoints and resource endpoints MUST be served over HTTPS.'
- Server must advertise an MCP protocol version on initializeMUST
MCP base specification — `initialize` result schema requires `protocolVersion`; authorization profile assumes negotiated version.
- Server should identify itself via serverInfo on initializeSHOULD
MCP base specification — `initialize` result schema includes `serverInfo { name, version }`.
MCP authorization
unknownWhether the server cooperates with the MCP authorization profile when authorization is in use.
Linked rules (1)
Standard requirements (2)
- Bearer tokens must travel in the Authorization header, not the query stringMUST
MCP Authorization spec — bearer token usage; defers to RFC 6750 §2 ('Authentication Schemes'), §2.3 forbids URI query parameter tokens for new applications.
- Auth-required servers should advertise protected-resource metadataSHOULD
MCP Authorization spec — discovery section; references RFC 9728 (OAuth 2.0 Protected Resource Metadata) at `/.well-known/oauth-protected-resource`.
OAuth protected resource metadata
not observedRFC 9728 — does the server publish a `/.well-known/oauth-protected-resource` document, and does it name the right authorization servers?
No scoring rule currently evaluates this standard. The requirement is documented for reference.
Standard requirements (4)
- Protected resource metadata is published at the well-known URLSHOULD
RFC 9728 §3 — Protected Resource Metadata Request; documents at `/.well-known/oauth-protected-resource[/<path>]`.
- Protected resource metadata `resource` matches the MCP serverMUST
RFC 9728 §2 — `resource` parameter; resource URI must identify the protected resource itself.
- Protected resource metadata lists at least one authorization serverSHOULD
RFC 9728 §2 — `authorization_servers` array.
- Signed metadata, when present, is validMAY
RFC 9728 §3.2 — `signed_metadata` JWT.
OAuth authorization server metadata
not observedRFC 8414 / OpenID Connect Discovery — does the authorization server publish `/.well-known/oauth-authorization-server` with the required endpoints?
No scoring rule currently evaluates this standard. The requirement is documented for reference.
Standard requirements (6)
- Authorization server publishes metadata documentSHOULD
RFC 8414 §3 — Authorization Server Metadata Request, served at `/.well-known/oauth-authorization-server`.
- Authorization server metadata `issuer` matches the discovery URLMUST
RFC 8414 §2 — `issuer` field; §3.3 — validation rules.
- Authorization server metadata advertises an `authorization_endpoint`MUST
RFC 8414 §2 — `authorization_endpoint`.
- Authorization server metadata advertises a `token_endpoint`MUST
RFC 8414 §2 — `token_endpoint`.
- Authorization server metadata advertises a `jwks_uri`SHOULD
RFC 8414 §2 — `jwks_uri`.
- Authorization server advertises a `registration_endpoint` if it supports DCRMAY
RFC 8414 §2 — `registration_endpoint`; RFC 7591 — Dynamic Client Registration.
OAuth security best practices
passRFC 9700 — current OAuth security guidance: PKCE, no implicit grant, audience-restricted tokens, careful redirect URIs.
Linked rules (1)
- auth_supports_pkce_s256observed
Standard requirements (4)
- Authorization server metadata does not surface obviously risky redirect URIsBEST_PRACTICE
RFC 9700 §2.1.1 — Redirect URI validation; §4.1 — Open redirector mitigation.
- Authorization server should support authorization code + PKCE for public clientsMUST
RFC 9700 §2.1 — 'Clients MUST use authorization code grant with PKCE'; RFC 7636 — PKCE.
- Authorization server should not advertise implicit or resource-owner-password grantsMUST
RFC 9700 §2.1.2 — implicit grant prohibited; §2.4 — resource owner password credentials grant prohibited.
- Access tokens should be audience-restricted to the MCP resourceSHOULD
RFC 9700 §4.10 — Audience restriction; RFC 8707 — Resource Indicators for OAuth.
OWASP MCP Top 10
passHeuristic alignment with the OWASP MCP Top 10 — keyword-driven indicators inferred from the public tool surface.
Linked rules (11)
- no_public_credential_access_toolsobserved
- tool_count_is_reasonableobserved
- no_public_admin_control_toolsobserved
- all_tools_have_input_schemaobserved
- all_tools_have_descriptionsobserved
- no_public_code_execution_toolsobserved
- no_public_filesystem_write_toolsobserved
- no_public_destructive_toolsobserved
- no_public_financial_action_toolsobserved
- no_public_send_message_toolsobserved
- no_pii_keywords_in_tool_surfaceobserved
Standard requirements (6)
- Tools must not expose tokens, secrets, or credential materialHEURISTIC
OWASP MCP Top 10 — Token / secret exposure (sensitive data disclosure through MCP tool surface).
- Tool surface should be minimal — no excessive or sprawling privilegesHEURISTIC
OWASP MCP Top 10 — Scope creep / excessive privilege (over-broad capability surface).
- Tool surface must be reviewable — no missing schemas or descriptionsHEURISTIC
OWASP MCP Top 10 — Tool poisoning (malicious or ambiguous tool definitions tricking agents into harmful calls).
- Sensitive tools must not be reachable from anonymous discoveryHEURISTIC
OWASP MCP Top 10 — Insufficient authentication / authorization (sensitive capability exposed without identity or scope checks).
- Server should expose telemetry / audit postureBEST_PRACTICE
OWASP MCP Top 10 — Lack of telemetry / audit (no observable record of tool invocation).
- Server should not invite broad context disclosure via tool surfaceHEURISTIC
OWASP MCP Top 10 — Context over-sharing (tools that pull excessive or PII-laden context into the agent).
Full rule breakdown
- weight 2
When authorization server metadata is discovered, it advertises a `jwks_uri` so clients can verify token signatures. Required for any authorization server issuing signed tokens.
{ "observed": [], "__applicable": true, "__observationKind": "observed" } - detailsweight 14
No advertised tool offers shell access, arbitrary code evaluation, subprocess spawning, or interpreter execution. Public code execution turns the MCP server into a remote shell for any agent that connects to it. The check is a keyword scan over name, description, and schema; a sandboxed-by-design `eval_expression` math tool will trip it. Hard-fail forces `block` so the operator must explicitly authorise the surface — typically by moving it behind authentication, scoping it to a sandboxed runtime, or renaming if the keyword match is incidental.
- detailsweight 12
No advertised tool references credentials, secrets, API keys, tokens, private keys, or vault material. A public tool that returns or mutates authentication material lets any caller pivot to other systems. The check is a keyword scan over each tool's name, description, and input schema; a benignly-named utility like `validate_api_key_format` will trip it. Hard-fail forces `block` precisely so the operator must consciously override the heuristic — either rename the tool, move it behind authentication, or treat the report as advisory and document the exception.
- detailsweight 10
The MCP endpoint is reached over HTTPS. Plain HTTP allows trivial credential and prompt leakage on any shared network path.
- detailsweight 10
No advertised tool grants administrative control over the system (shutdown, terminate, revoke, suspend, grant_role, sudo, …). Public administrative control lets any caller take over or disable the host. The check is a keyword scan over name, description, and schema; a status-only tool like `get_subscription_grant` may trip it on the word `grant`. Hard-fail forces `block` so the operator either renames the tool, moves it behind authenticated operator interfaces, or documents the override.
- detailsweight 10
No advertised tool mutates the host filesystem (write_file, delete_file, chmod, mkdir, …). Public filesystem mutation can plant payloads, overwrite configuration, or destroy host state. The check is a keyword scan over name, description, and schema; a content-store tool exposing `upload_file` against an isolated bucket will trip it. Hard-fail forces `block` so the operator either fences the tool behind authentication, scopes it to a content store that does not expose raw paths, or documents the exception as an explicit override.
- detailsweight 8
No advertised tool's `inputSchema` exposes a free-form string property named `prompt`, `query`, `command`, `sql`, `instruction`, or `message` without an `enum`, `pattern`, or `maxLength` ≤ 200. These are the field shapes that let an upstream MCP server smuggle agent-instructable text — model prompts, SQL fragments, shell commands — into the call site.
- detailsweight 8
The MCP server returns HTTP 403 to a POST whose `Origin` header points at a host other than its own. This is the documented DNS-rebinding mitigation in the MCP 2025-11-25 security best practices: a server that processes cross-origin requests can be coerced via DNS rebinding into accepting tool calls from any page in the user's browser. Real CVEs in this class include CVE-2025-10625 (Neo4j Cypher MCP) and CVE-2026-23744 (MCPJam Inspector).
- detailsweight 8
The MCP endpoint completes a TLS handshake whose certificate validates against Node's CA store and matches the requested hostname. Untrusted, expired, or hostname-mismatched certificates are observable here even when the JSON-RPC handshake fails.
- detailsweight 8
No advertised tool matches destructive data verbs (delete, drop, purge, wipe, destroy, truncate). Destructive actions are typically irreversible and should be exposed under explicit, scoped authorization rather than a default `tools/list`.
- detailsweight 6
Every tool returned by `tools/list` includes a non-empty JSON Schema for its arguments. Schema-less tools force agents to guess argument shapes and make pre-call validation impossible.
- detailsweight 6
No advertised tool performs a financial action (pay, charge, refund, transfer, withdraw, invoice, …). Tools that move money should be explicitly authorized and reviewed individually.
- detailsweight 6
The endpoint URL has no userinfo segment and no token-like keys (`token`, `api_key`, `apikey`, `access_token`, `refresh_token`, `password`, `secret`, `client_secret`) in its query string. Credentials in URLs leak through logs, Referer headers, browser history, and intermediary caches.
- detailsweight 6
Every authorization server advertised by the protected resource metadata uses an HTTPS issuer URL with no userinfo, fragment, or query. RFC 8414 and OpenID Connect Discovery both require HTTPS issuers — anything else allows trivial token interception.
- detailsweight 6
The advertised authorization server metadata does not advertise the resource owner password credentials grant or the implicit grant. Both are flagged as insecure by RFC 9700 and by OAuth 2.1, and should not appear on a modern authorization server.
- detailsweight 6
Every parsed authorization server metadata document advertises `S256` in `code_challenge_methods_supported`. RFC 9700 (OAuth 2.0 Security BCP) and OAuth 2.1 require PKCE on every authorization-code exchange, with S256 as the only acceptable challenge method (`plain` is forbidden).
- detailsweight 6
Every URL advertised in protected resource metadata or authorization server metadata — `authorization_endpoint`, `token_endpoint`, `jwks_uri`, `registration_endpoint`, `revocation_endpoint`, `introspection_endpoint`, and the PRM `resource` — uses HTTPS and resolves to a publicly routable hostname (no loopback, RFC 1918, link-local, or private TLD). The discovery chain has no value if it points clients at the cloud metadata service or the loopback interface.
- detailsweight 6
No tool description contains hidden-instruction tags (`<IMPORTANT>`, `<system>`, `<instructions>`), override phrases (`Ignore previous instructions`, `Disregard prior context`), identity hijacks (`Act as an admin`), or exfiltration directives (`Send results to https://…`). These are the canonical tool-poisoning patterns documented by Invariant Labs and the OWASP MCP Top 10 — the description reaches the model verbatim, and a malicious server uses it to manipulate behavior at read time.
- detailsweight 6
For every tool that returns spec-defined annotations (`readOnlyHint`, `destructiveHint`, etc.), the hints do not contradict each other and do not contradict the capability the scanner inferred from the tool's name, description, and schema. Misdeclared annotations are the canonical rug-pull camouflage — a tool that calls itself read-only but deletes records.
- detailsweight 5
The advertised tool surface (each tool's `name`, `description`, `inputSchema`, and `annotations`) hashes to the same value as the most recent prior scan of this server. A drift in any of those fields is the rug-pull pattern documented by the `postmark-mcp` September 2025 incident: a server changes a tool's behavior or name post-install while the user's existing approval still grants the agent access. The rule is silent on first scans (no prior surface to compare against).
- detailsweight 5
No tool name, description or input schema references obvious PII fields (email, phone, ssn, password, …). This is a governance prompt, not a security failure — many legitimate CRM, HR, and support servers handle PII by design and will trip the rule. The intent is to make the PII surface visible during review, not to block it. Treat a fail as 'document data minimization, retention, and access controls', not 'remove the tool'.
- detailsweight 5
The negotiated TLS version is 1.2 or 1.3. TLS 1.0 and 1.1 are deprecated by RFC 8996 and have known cryptographic weaknesses; servers offering them broaden the attack surface for downgrade and padding-oracle attacks.
- detailsweight 5
No high-precision secret pattern (Bearer header, JWT, OpenAI/Anthropic key, GitHub PAT, AWS key, Stripe live key, PEM private key, etc.) appears in `initialize.instructions`, `serverInfo`, tool descriptions, or input schemas after the standard `redact()` pass.
- detailsweight 5
No entry returned by `resources/list` or `prompts/list` contains a markdown link with a `javascript:` or `data:` target, an HTML tag a renderer would execute or fetch (`<script>`, `<img>`, `<iframe>`, `<svg>`, `<object>`, `<embed>`), or a non-HTTPS inline URL in its description (or name, for resources). Resources and prompts reach the model with the same trust as tool descriptions, so the same technical-injection classes apply.
- detailsweight 5
When the server requires authentication (HTTP 401/403 to an unauthenticated probe), it also advertises either a `WWW-Authenticate` challenge or a discoverable `.well-known/oauth-protected-resource` document. This is what allows a client to start a standards-compliant authorization flow without out-of-band documentation.
- detailsweight 5
The `initialize.instructions` string returned by the server contains no markdown link with a `javascript:` or `data:` target, no HTML tag a renderer would execute or fetch (`<script>`, `<img>`, `<iframe>`, `<svg>`, `<object>`, `<embed>`), and no inline URL on a non-HTTPS scheme. The instructions field reaches the model verbatim — same trust boundary as a tool description, same vector classes.
- detailsweight 5
No advertised tool's `description` contains a markdown link with a `javascript:` or `data:` target, an HTML tag that a renderer would execute or fetch (`<script>`, `<img>`, `<iframe>`, `<svg>`, `<object>`, `<embed>`), or an inline URL on a non-HTTPS scheme. Each pattern is a vector for the upstream server to smuggle content past the agent's normal trust boundary.
- detailsweight 4
No advertised tool offers generic outbound network access (fetch_url, http_request, curl, wget, download, upload, …). A public network-fetch tool turns the MCP server into an open proxy and a SSRF pivot for any agent that connects to it.
- detailsweight 4
Every tool includes a non-empty `description`. Missing descriptions make capability review impossible without invoking the tool, which the scanner refuses to do.
- detailsweight 4
No advertised tool sends an outbound message on the operator's behalf (send_email, send_sms, post_message, broadcast, notify, …). Messaging tools enable spam, phishing and impersonation if exposed without scoped review.
- detailsweight 4
`serverInfo.name` is lowercased and split on non-alphanumerics; tokens shorter than three characters and noise words (`mcp`, `server`, `service`, `api`, `the`, `official`) are dropped. The rule passes if any surviving token is a substring of the TLS certificate CN, any SAN, or the URL hostname (also lowercased). A name like "Slack MCP" served from `mcp.attacker.com` with no matching SAN is a passive identity-claim mismatch worth flagging. The check is deliberately generous — case-insensitive substring, any token — so single-word product names hosted on their own domain pass cleanly. False positives are possible on multi-tenant CDN hostnames (e.g. `*.cloudfront.net`) where the cert identity belongs to the platform, not the operator; treat a fail as 'investigate', not 'malicious'.
- detailsweight 4
The MCP endpoint hostname is not `localhost`, a loopback address, a private/link-local IP range, or a *.local / *.internal / *.intranet / *.lan name. Internal-only hostnames in a published MCP URL usually indicate a misconfigured deployment.
- detailsweight 3
The HTTPS endpoint returns a `Strict-Transport-Security` header with a non-trivial `max-age`. HSTS prevents trivial downgrade attacks by instructing user agents to refuse plain HTTP for the host going forward.
- detailsweight 3
When the protected resource metadata advertises one or more authorization servers, at least one of those issuers publishes a parseable RFC 8414 / OpenID Connect Discovery metadata document. This is what tells a client where to send the user, where to fetch tokens, and where to verify signatures.
- detailsweight 3
The MCP `initialize` response includes a `protocolVersion`. Servers that omit it make safe client fallback impossible.
- detailsweight 2
The peer certificate's `notAfter` is at least 14 days in the future. Certificates that expire imminently cause sudden client-side failures and indicate an unmanaged renewal process.
- detailsweight 2
The `initialize` response includes a `serverInfo.name` so operators can recognize the implementation and cross-reference it with upstream advisories.
- detailsweight 2
When authorization server metadata is discovered, it advertises a `token_endpoint`. Without one, clients cannot exchange authorization codes (or refresh tokens) for access tokens — the flow is inert.
- detailsweight 2
Every advertised tool name matches `/^[a-zA-Z][a-zA-Z0-9_.-]{0,63}$/` — a length-bounded ASCII identifier. Names with shell metacharacters, whitespace, control characters, or unicode look-alikes can confuse logging, agent argument parsers, and reviewers.
- detailsweight 2
Servers exposing a very large number of tools (>50) increase the agent's blast radius. Smaller, focused servers are easier to audit and reason about.
- detailsweight 2
No advertised tool's `inputSchema` carries broad-shape smells: `additionalProperties: true`, untyped `object` properties, or sensitive free-form string fields (`query`, `command`, `path`, `url`, `sql`, `prompt`, `token`, `secret`) without an `enum`, `pattern`, or `format` constraint. Each one is a passive smell that lets a caller send input the schema does not document. Prompt-injection-shaped instructable-text fields specifically are scored under `prompt_injection_surface`; this rule retains the broader structural shape evidence at a lower weight.
- detailsweight 1
The probe response stayed under the 1 MB cap enforced by `safeFetch`. Servers that return multi-megabyte JSON-RPC responses can exhaust client memory and indicate something is wrong with their tools/list output.
- detailsweight 1
The probe completed within the 3-redirect cap enforced by `safeFetch`. Long redirect chains complicate SSRF defense and indicate misconfigured deployments.
- detailsweight 1
The MCP `tools/list` call returned an array (possibly empty) rather than failing. This is a precondition for the rest of the tool-surface evaluation and a baseline indicator that the server speaks MCP correctly.
- detailsweight 1
The `initialize` response includes a `serverInfo.version` so operators can pin known-good builds and cross-reference upstream advisories.
- detailsweight 1
The probe transport layer accepted the response's content-type. MCP servers MUST return JSON-RPC over HTTP or SSE; any other content-type makes the response unusable.
Coverage & scope
What we did and did not look at.
Auth discovery
Passive scan — no `Authorization` header, no token exchange, no client registration. The scanner reads what the server publishes; it does not run an OAuth flow.
- Requires auth?observed
The MCP endpoint returned 401 or 403 to an unauthenticated request.
- WWW-Authenticate observed?observed
Server returned a Bearer challenge.
- Protected resource metadata found?observed
A `/.well-known/oauth-protected-resource` document parsed successfully.
- Auth servers found?observed
1 authorization server advertised by protected-resource metadata.
- DCR discoverable?observed
An authorization server advertised a `registration_endpoint` (RFC 7591). The scanner never POSTs to it — discoverability only.
- Grant types observed?observed
Authorization-server metadata advertised: authorization_code.
- Token endpoint observed?observed
Authorization-server metadata advertised a `token_endpoint`.
- jwks_uri observed?not observed
No `jwks_uri` was observed in authorization-server metadata.
Metadata fetches (3)
- prm200https://serenialabs.space/.well-known/oauth-protected-resource[application/json]parsed
- prm404https://serenialabs.space/.well-known/oauth-protected-resource/api/mcp[text/html; charset=utf-8]
- as200https://serenialabs.space/.well-known/oauth-authorization-server[application/json]parsed
Scan coverage
coverage: none
No usable protocol signal was retrieved. The verdict is unknown — there is nothing to score against.
What the probe got back
- initializemissing
Server did not return a usable initialize response.
- protocolVersionmissing
Server did not advertise a protocol version.
- serverInfomissing
Server did not advertise serverInfo.name.
- tools/listchecked
Enumerated the advertised tool surface.
- Tool countchecked
0 tools advertised.
- Tools with input schemaout of scope
No tools advertised, so nothing to check.
- Tools with descriptionout of scope
No tools advertised, so nothing to check.
Transport observation
- Status codechecked
Header GET returned HTTP 401.
- Content-Typechecked
Final response advertised `application/json`.
- Final URLchecked
No redirects — final URL was the requested URL.
- TLS expirychecked
Certificate valid for another 40 days.
Out of scope by design
- tools/callnot checked by design
Never invoked by design. AgentReserve does not execute tools — safety is a structural invariant of the probe client.
- Authenticationout of scope
Auth flows, token handling and permission boundaries were not exercised.
- Source codeout of scope
Server implementation, dependencies and supply chain were not audited.
- Runtime behaviorout of scope
No tool was executed, so side effects, latency, errors and rate limits were not observed.
What was not checked
What this report does not tell you
- Inferred: tool risk is read from name, description and input schema only. A tool labelled read may still mutate state at call time, and a misleading description can fool the heuristic.
- Not checked: no tool was invoked, so this report cannot confirm that any advertised capability actually works or behaves as described.
- Not checked: authentication, authorization, rate limits and abuse controls were not exercised — they require credentials, which the scanner never sends.
- Not checked: server implementation, dependencies and hosting were not inspected.
- A passing report is not a guarantee of security. It is an automated triage signal based on what was Observed and Inferred within the coverage above.
History
How this server has scored over time.
Diff vs. previous scan
Latest score
87/100
Sun, 03 May 2026 17:51:34 GMT
Previous score
87/100
Sun, 03 May 2026 06:08:09 GMT
Change
0
No score change.
Changed tools
No tool was added or removed since the previous scan.
Changed failing rules
No rule changed pass/fail status since the previous scan.
Changed auth metadata
No auth-discovery observation changed since the previous scan.
Methodology version
Same methodology version (2026-05-03-v2-rfc) on both scans — score delta reflects server changes only.
Report timeline
- Sun, 03 May 2026 17:51:34 GMT87/100 (B)latestmethodology v2026-05-03-v2-rfcscanner v1.0.0
- Sun, 03 May 2026 06:08:09 GMT87/100 (B)methodology v2026-05-03-v2-rfcscanner v1.0.0
lateststale (>24h)methodology updatedgenerated Sun, 03 May 2026 17:51:34 GMT
The scoring methodology has been updated since this report was generated (2026-05-03-v2-rfc → 2026-05-06-rebalance-and-false-positive-disclosure). Rescan to compare against the current methodology.
methodology v2026-05-03-v2-rfcscanner v1.0.0
Embed this badge
Live badge — auto-updates on every rescan.Markdown (live)
[](https://agentreserve.dev/reports/d0pf52jdai)HTML (live)
<a href="https://agentreserve.dev/reports/d0pf52jdai"><img src="https://agentreserve.dev/badge/svr_kaedd5ti2tpdd2rl.svg" alt="AgentReserve security score for serenialabs.space" /></a>Pinned to this scan (does not auto-update)
[](https://agentreserve.dev/reports/d0pf52jdai)