Warden

“Audio of your own text, and a default right to use it”

Nothing untrusted comes back, only audio of your own text, and synthesis has no side effects. A hijacked agent's damage is spend, at up to $100 per 1M characters on long-form, plus async output landing in your own S3 bucket. SigV4 with IAM users, roles or temporary credentials, scoped per action and resource by policy, and CloudTrail logs API calls per caller. The catch sits in the AWS Service Terms rather than the Polly guide. AWS may store and use text processed by Polly to improve the service, and opting out takes an organisation-wide AI services opt-out policy. Stored input isn't zero-retention by default. Vulnerability reporting, SOC and ISO reports in AWS Artifact and public security bulletins. The aws.amazon.com security.txt passed its Expires date on 24 September 2026, and no paid public bug bounty was found. Four, because the blast radius is a bill and the text sent may be kept and used unless the organisation opts out.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“IAM can pin an agent to one sender”

IAM policies per action and identity, condition keys such as ses:FromAddress, temporary credentials and rotation. That's enough to write a credential that calls SendEmail from one verified identity and nothing else, and AWS has a read-only managed policy for agents that only look. CloudTrail records SES API calls, and configuration sets publish per-message events. The API returns no third-party content. Inbound mail goes to S3, SNS or Lambda, so the injection path is whatever reads those, not SES itself. SMTP uses separate credentials derived from an IAM user. Nothing confirms a send, which IAM leaves to the caller, and a broad policy undoes the rest. SOC 1, 2 and 3 scope, a HackerOne disclosure programme and security bulletins, no paid bug bounty found, and the aws.amazon.com security.txt expired on 24 September 2026. SES-specific retention is unchecked. Four, because the boundary is as tight as the policy you write and nothing asks before a send.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“The only API key is the admin key”

One developer key type, and SECURITY.md calls it admin-equivalent across every /v1 endpoint, stored in plain text with no scopes or expiry. An agent holding it can delete workspaces, users and documents. It travels in the Authorization header only, and that's the end of the good news on credentials. Built-in write skills for the filesystem, Gmail, Outlook and Google Calendar ask before acting, but MCP tool calls don't, and scheduled jobs approve every call. Chat answers carry text from uploaded documents and scraped pages with no injection guidance, and GHSA-4q6m-qh3w-9gf5 (April 2026) was an XSS reached through prompt injection. The Docker quick start adds --cap-add SYS_ADMIN. The advisory record is the better half. Ten published between 13 March and 15 July 2026, all fixed, among them CVE-2026-48116 (CVSS 7.5), code execution through the filesystem search skill, fixed on 20 May and published the next day. Two because the only key is the master key.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“A token in the query string and scraped pages returned raw”

Query-string tokens are a documented way into the Apify API, and a key that can travel in a URL is the first thing I check. It fails here. The rest of the token model is good. OAuth on mcp.apify.com, scopes per resource, an expiry date and rotation with a 24-hour overlap, and AGI prepaid tokens are spend-capped. Writes come next. call-actor, build-actor, delete-schedule and the task tools carry destructiveHint, and ?tools= can hold a session to read tools, but there's no server-side confirmation step. Then content. Actor results, third-party Actor READMEs and scraped pages go back to the model as they are, and nothing I read gives prompt-injection guidance. Telemetry to Segment and Sentry is on by default with an opt-out, and retention is 'no longer than necessary' with no periods. SOC 2 Type II, private vulnerability reporting, no bug bounty found. Two, because untrusted pages arrive unmarked in a session that can still write without asking.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Auth off, password admin, and a careful OAuth server behind them”

Auth is off by default on a local instance, and the admin password is admin until someone changes it. Switch auth on and it improves. /mcp runs Phoenix's own OAuth 2.1 server with PKCE, dynamic registration and an RFC 8707 audience, so an MCP token can't be replayed at /v1, and REST keys are revocable. A viewer role is read-only. Annotations follow the HTTP verb, but execute runs model-written Python, sandboxed to 30 seconds and 100 MB, and reaches writes the annotations can't separate. Span inputs and outputs hold whatever the application logged, and the MCP code leaves approval to the client with no user-facing injection guidance. No audit log found. SECURITY.md has a disclosure address, no advisories are published, and Arize's bug bounty excludes the open-source repositories. Three, because a viewer account bounds the agent and the defaults bound nothing.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“One unscoped key, and the Fetch API wants it in the URL”

The Fetch API takes the key only as the apikey query parameter, so it sits in every request URL and every log that records one. It's one account key with no documented scopes. The hosted MCP takes a Bearer header or OAuth instead. 44 MCP tools, 36 of them browser actions, all annotated, none confirmed, and no read-only subset. No prompt-injection guidance in the docs index, the MCP README or the tool descriptions. With no key set, the stdio MCP signs up for a Free account and stores the key under ~/.zenrows/ (mode 0600) unless ZENROWS_AUTO_SIGNUP=false. The x402 route runs through a ZeroClick storefront that proxies calls on its own path under its own buyer terms. The privacy policy doesn't say whether scraped content is stored. SOC 2 Type II and ISO 27001 claimed, security.txt valid, no bug bounty found. Two, because the only key there is opens everything and gets written into the URL.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read-only tools on unscoped keys”

No tool writes or deletes, which takes most of the blast radius away. The MCP adds allow-lists through ?tools= or X-Allowed-Tools and a two-tool free profile. Keys travel in the X-API-Key header, never a URL. Several keys per organisation, revoked immediately on delete, rotated by create-then-delete, and developers see only their own. The hosted MCP takes OAuth 2.1. What's missing is scope. No per-key scopes or spend caps are documented, so a leaked key spends on every API, Research included. Search and Contents return untrusted page text with safesearch as the only content control, and no injection guidance. The key list shows a last-used date, and no per-call log was found. The trust centre renders only with JavaScript, so certifications and the disclosure page are unchecked, and there's no security.txt. Prompts and outputs aren't used for training, and Zero Data Retention covers Web Search and Answer on enterprise agreements only. Three, because nothing writes and nothing is scoped.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Mail, calendar and browser steps, and no approval I could read”

No advisories found, and no disclosure channel I could find. conway.tech's security.txt is a 404 and Conway's three GitHub repositories have no SECURITY.md (underdog.ai's is unchecked). There's no agent interface, so no key to leak in a URL. The exposure sits inside the app. Per Conway it connects the owner's mail and calendar, its prompts include tool calls, mail and browser steps, and Woof 4B and 2B 1.1 are DOM browser executors by their release files. I read nothing on approval before it sends or acts, on prompt injection from the mail and pages it reads, or on a per-action log. Credential storage, revocation and telemetry would sit in the privacy policy on underdog.ai, whose robots.txt refuses our reader, so they're unchecked. Conway says Woof runs on the Mac "with nothing sent anywhere", and the weights are safetensors. Two, because it reads untrusted mail and can act on it, and nothing I could read puts a confirmation between the two.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Recordings kept until someone deletes them”

Live caller speech is the untrusted input here, and it reaches the agent by design, through Media Streams or ConversationRelay. Webhooks and websocket upgrades are signed with X-Twilio-Signature. That authenticates Twilio. The caller's words are still untrusted. Restricted keys take up to 100 endpoint permissions, so an operator can keep an agent away from recordings and number purchases, and no documented option sends a secret in a query string. Recordings are kept and billed until someone deletes them, and no stated retention period for call logs turned up. The alpha MCP takes the key and secret as a command-line argument, visible in process lists, and has no confirmation step before dialling. Its README does warn about injection from untrusted servers. SOC 2 Type II, ISO 27001, 27017 and 27018 and a HackerOne bounty. No security.txt, and public advisories weren't checked. Three, because the key can fence the recordings and nothing fences the dial.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Restricted keys, and nothing asks before a send”

Up to 100 endpoint permissions on a restricted key, revocable in the console or by API, and no documented option to send a secret in a query string. So an agent can hold a key that sends but can't buy numbers or read other logs, and that's the right shape. The gap is the write. No Twilio MCP asks before a send. The local @twilio-alpha/mcp takes ACCOUNT_SID/API_KEY:API_SECRET as a command-line argument, which shows in process lists, and was last published on 7 July 2025. Inbound SMS and WhatsApp bodies are untrusted text. Webhooks are signed with X-Twilio-Signature, and the alpha README warns about injection through other MCP servers. The Monitor Events API keeps an audit trail of account changes. SOC 2 Type II, ISO 27001, 27017 and 27018 and a HackerOne bounty, but no security.txt, and no retention period for message logs on the pages read. Three, because the key narrows to sending and nothing asks before a send.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Three meta-tools that reach every endpoint”

The hosted MCP has three tools, list_api_endpoints, get_api_endpoint_schema and invoke_api_endpoint, and the third reaches the whole REST API. That includes dialling and number purchase, with no confirmation step. Behind it sits one kind of credential, a Bearer key from the portal, with no per-key scopes and no read-only mode found. Keys are minted at /v2/api_keys on the same API. Calls carry untrusted caller speech, and I found no prompt-injection guidance. Call Control webhooks are signed and call records come back by API, but no account audit log was found, and retention periods for call records and recordings aren't stated. SOC 2 Type II and ISO 27001 per Telnyx's compliance file, a SECURITY.md on telnyx-node with no published advisories, no security.txt and no bug bounty found. One, because a model listening to strangers holds a key that can place calls and buy numbers, and nothing in between asks.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“The documented setup puts the key in the URL”

?tavilyApiKey= in the MCP URL is how the README and docs lead. A key in a query string is the first thing I look for, and here it's the example. Behind it the credential is thin. Development and production keys can be revoked, and the hosted MCP's OAuth maps to one dashboard key with no scopes. Every tool reads except tavily_feedback, which posts scores to Tavily, and there's no read-only toolset and no readOnlyHint or destructiveHint. Search, extract and crawl return untrusted page text. The home page claims layers that block prompt injection, with no technical detail. The privacy policy keeps data for the life of the account, lets query data improve future responses unless a contract says otherwise, and describes no zero-retention option. The trust centre renders only with JavaScript and is unchecked, with no security.txt or bug bounty. Two, because the documented setup puts the key in a URL and the data stays as long as the account.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“No disclosure route, and browser tools that click unasked”

No security.txt, no disclosure policy, no bug bounty and no certification found. The 9 hosted browser tools click and type on third-party sites with no confirmation and no annotations, and there's no read-only mode. Keys are better than the paperwork. They go in the Authorization header only, and an account can hold several, all regenerable. None has documented scopes or a spend cap, and a crawl with no limit set stops only at the credit balance. Whether OAuth-minted MCP keys are narrower is unchecked. No prompt-injection guidance in the docs, llms.txt or MCP README. Dashboard request logs, with inline browser previews since 3 March 2026. The privacy policy gives no retention periods and no DPA. The EULA says the free Spider Shield and Spider Peers apps route third-party traffic through users' connections, which leaves the proxy pool's sourcing open. Two, because nothing scopes a key and nobody is named to tell.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Eight hex characters guard raw SQL and pipe creation”

Eight hexadecimal characters, about 4.3 billion values, follow the sp- prefix, and that one key reaches every route, raw SQL and pipe creation included. Auth is on by default, localhost included, though the getting-started page lists ?token= as a less secure way to send the key. Pipes get scoped sp_pipe_ tokens, but the MCP server and any outside agent hold the main key, and create-pipe, run-pipe, control-recording and merge-speakers run without confirmation. Results carry screen text, transcripts and messages written by anyone. The bundled skills say to treat that as untrusted and the tool descriptions don't, while a shipped pipe template (off by default) carries the vendor's own instruction for agents to add its header to files outside the repository. PostHog, Sentry and, since 17 September, remote support logs are on by default. The SOC 2 report is under NDA and unchecked. Two, because a continuous screen and audio record sits behind one short main key without a read-only mode.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“A full-access agent can mint its own keys”

106 MCP tools load at once, and 16 of them remove, cancel, revoke or rotate something without a destructiveHint. With a full_access key the MCP can create API keys, remove domains, rotate webhook secrets and revoke OAuth grants, and there's no read-only mode. The hosted MCP signs in by OAuth with no documented scope choice. Then the input side. get-received-email hands inbound mail bodies to the model, and the MCP docs and README say nothing about prompt injection, so anyone who can email the domain can write into the agent's context. Sending keys can be limited to one domain, which is the one boundary worth using. API request logs keep full request and response bodies. SOC 2 Type II, an annual penetration test, a responsible-disclosure page and a security.txt without Expires. Two, because the inbox that can steer the agent sits beside the tools that let it keep access.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read-only keys per collection, expiring in 90 days”

One advisory in the last year. GHSA-f632-vm87-2m2f, high severity, an arbitrary file write through /logger, fixed in v1.16.0 in November 2025 and published on 5 February 2026, nearly three months later. Qdrant Cloud database keys can be read-only or read-write, limited to chosen collections, and expire after 90 days by default, with management keys kept separate. They travel in the api-key header or as Bearer. QDRANT_READ_ONLY=true drops the MCP store tool, though neither tool carries readOnlyHint or destructiveHint and nothing confirms a delete. The weak spot is memory. Stored payloads come back as written with no injection guidance, so what an agent stores today it reads as context later. Paid clusters keep an audit log of operation, key, time, collection and result. SOC 2 Type 2, HIPAA and a bug bounty, but no SECURITY.md or security.txt. Four, because a read-only key on one collection is a real boundary and poisoned memory isn't covered.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Seven advisories this year, two past the metadata blocklist”

Seven advisories in 2026, read before anything else. February brought two high-severity ones, server-side request forgery in URL download handling (CVE-2026-25580) and stored XSS through path traversal in the web UI's CDN URL. May to August added five moderate ones, among them two bypasses of the cloud-metadata blocklist, unbounded memory use on remote downloads and UI adapters trusting client-sent data. Every one was published on GitHub with a fix. The pattern worries me more than the count, because the guard for agents that download URLs is a blocklist and it was bypassed twice in May. The defaults are sound. No telemetry unless you configure OpenTelemetry or Logfire, and human approval is built in through deferred tools. Nothing I read describes a sandbox for model-written code, a read-only mode or prompt-injection guidance. SECURITY.md uses GitHub private reporting, with no bounty mentioned. Three, because telemetry is off by default and an agent that downloads URLs leans on a filter with a record.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“A tool that tells the model not to ask the user”

Since MCP server v0.3.0 on 7 August 2026, every database tool asks the calling model for its provider and model name 'to track usage analytics', and tells it not to ask the user. The values go to Pinecone with the API calls, and the README and docs don't mention it. The data is small. The habit is wrong. A tool description that tells the model to keep something from its user is the shape I'd flag in an injection. The platform itself is well fenced. Project keys with roles including read-only, RBAC, CMEK, private endpoints, deletion protection and audit logs. The MCP server reads PINECONE_API_KEY from the environment, annotates every tool with upsert marked destructive, and has no read-only mode. Stored records come back as written, with no injection guidance. SOC 2 Type II, ISO 27001, HIPAA, no security.txt or bug bounty. Three, because a read-only key fences the data and the tool text still needs reading.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“A search server that only reads, on a key that buys ultra8x”

Search and Extract only read, and the Task tools live in a separate MCP server, so connecting search.parallel.ai/mcp alone gives an agent a read-only surface. The key is another matter. It's sent in x-api-key or as Bearer with no scopes found, and the same key creates Task runs priced up to $2,400 per 1,000 on ultra8x. Excerpts and fetched pages are untrusted web text, with no injection guidance in the docs index. No audit log found. The MCP source is closed, so tool annotations aren't visible. The EU endpoint keeps no request or response content, but the default endpoint has no retention period and the policy says nothing on training. The privacy policy shows a SOC 2 badge and links a trust centre that rendered nothing readable, so the report type is unchecked. No security.txt, no bounty found. Three, because the search server is a read-only subset and the key behind it isn't.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“The bot token the docs suggest has leaked twice this year”

Three advisories landed in 2026, a critical FreeMarker template injection to code execution, CVE-2026-26010 (7.6), which exposed bot JWTs to any read-only user, and CVE-2026-46481 (8.3), which returned the ingestion-bot JWT and a database password to non-admin users. The docs suggest bot JWTs for unattended agents. All fixed. Issue #34566, opened 2 October, says get_entity_details returns service connections that REST masks, and no masking step turned up in the MCP read path. The vendor's view is unchecked. Sign-in is the strong part, OAuth with PKCE through the instance's SSO, 1-hour access tokens and rotating 7-day refresh tokens, and every MCP call lands in the instance database with tool, user and client. Tokens still carry full roles, four write tools are always listed with no read-only switch or confirmation, and a fresh install signs in as admin with password admin. Two, because MCP is on by default with writes listed, and bot tokens reached low-privilege users twice this year.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read Only keys, and a 30-day abuse log”

Three permission levels on a project key, All, Restricted and Read Only, and Restricted sets None, Read or Write per endpoint. That's the fence I look for first. Service-account keys and mutual TLS with X.509 workload identity, GA since 26 August 2026, round it out. The key travels in an Authorization: Bearer header, not a URL. API data isn't used for training unless the customer opts in. Abuse-monitoring logs stay up to 30 days, Responses state 30 days when store=true, and zero data retention is by approval for nine endpoints, not Assistants, Threads, Vector Stores or Conversations. Usage and Costs filter by key since 4 August, and audit logs are for enterprise. Remote MCP and web search return untrusted content into the model. SOC 2 Type 2, ISO 27001, 27017, 27018, 27701 and 42001, and a bug bounty with safe harbour. Four, because a key can be held to Read Only and the content tools still bring untrusted text in.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Tracing sends tool inputs and outputs to OpenAI by default”

Two defaults decide the blast radius, and both point outwards. Tracing is on, and trace_include_sensitive_data defaults to true, so model and function-call inputs and outputs go to OpenAI's Traces dashboard. Nothing I read states how long those traces are kept, and tracing isn't available to zero-data-retention organisations. OPENAI_AGENTS_DISABLE_TRACING=1, set_tracing_disabled or RunConfig turn it off. The guards exist and you set them yourself. Approval is available per local MCP server, per hosted MCP tool and for function tools, MCP servers take allow and block lists, sandbox agents work in a container, and the MCP page says to use least-privilege credentials and keep tokens out of URLs. SECURITY.md routes reports through OpenAI's coordinated disclosure policy, and no advisories or CVEs were found against the SDK. Three, because the boundaries are opt-in and the one default that matters sends content to a vendor with no published retention for it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“129 advisories in a year, over half in access control”

129 advisories in the 12 months to 3 October cover flaws fixed since 0.6.35, 58 High and 1 Critical, each fixed in a release before publication, and more than half are access-control or authorisation flaws by their titles and CWE tags. CVE-2026-59216 let a low-privilege user run code in another user's session, as root in default containers when the target was an admin. The defaults are careful. Sign-in is on, sign-up closes after the first admin, API keys stay off until ENABLE_API_KEYS is set, and an endpoint allowlist can hold keys to chat and models. Each user gets one sk- key, in plain text with no scopes or expiry, sent in a header, never a query string. Deletes run unconfirmed, per-call tool approval works only in the interface and is off by default, and installed tools are Python loaded with exec. Two, because more than half of a year's flaws sat in the permission model an agent's key relies on.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read-only tools, and other users' OAuth tokens until 4.0.0”

GHSA-q62f-rv3h-f822, CVSS 9.0, published 20 July 2026. Before 4.0.0 any signed-in user could read other users' live OAuth tokens for per-user MCP servers through GET /api/mcp/servers, and three moderate IDORs were published in April and July. All fixed. The MCP server is the narrow part. Three tools, all read, and a personal access token limited to read:search covers them, expires after 7, 30 or 365 days, is stored hashed and revokes one at a time. No OAuth for MCP, and nothing long-lived travels in a query string. The exposure is the mix. search_indexed_documents returns documents anyone in the company can write, and open_urls fetches any URL the model names, so a session that reads private text can also reach any address. The docs carry no injection guidance. Telemetry is on by default, called anonymous, and carries user IDs. Three, because the token narrows to search and the server behind it leaked across users this year.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“12 CVEs at NVD and not one vendor advisory”

12 CVEs against Ollama at NVD since October 2025, and zero GitHub advisories. I read that gap before anything else. The updater pair (CVE-2026-42248 and CVE-2026-42249, 9.8 each) let whoever answered the Windows app's update request run code, since it installed unsigned files silently until v0.23.3 on 12 May 2026, a fix listed only as app: harden update flows. CERT Polska says the maintainers didn't respond with details. The local API on 127.0.0.1 port 11434 takes no credential, so anything that reaches it can pull, push, create and delete models, and the FAQ's ngrok and Cloudflare Tunnel examples say nothing on adding auth. The loopback Host check and narrow CORS are the only walls. No read-only mode, no injection guidance for web search and fetch results, and cloud keys don't expire. Whether all 12 CVEs are fixed in 0.35.1 is unchecked. Two because the loopback address is the whole perimeter.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“One admin key per environment and three delete tools”

Full administrative access to its environment is what the REST secret key grants. No scopes, no read-only key, and regenerating it kills the old key at once with no overlap. The hosted MCP signs in with OAuth, short-lived and revocable, or takes that same key as a Bearer token, and ships 30 tools including delete_subscriber, delete_workflow and delete_integration, with no read-only mode. Their annotations are unchecked, since the server source isn't public. Two things narrow it. Keys are confined to one environment and OAuth sessions default to Development, and the MCP docs warn against mixing the server with untrusted data and ask you to review tool calls that change data. Conversation tools return end-user replies. Self-hosted instances send an hourly keep-alive beacon with hostname and IP address whether telemetry is on or off. SOC 2 Type II, ISO 27001 and HIPAA, no bug bounty, no security.txt. Two, because whoever holds the key owns the environment, deletes included.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read-only tools, and the token rides in the URL”

All 29 MCP tools are read-only, annotated readOnlyHint true and destructiveHint false, and there are no write actions to hijack. The REST side is the problem. The documented way in is the access_token query parameter, so pk, sk and tk tokens land in proxy and server logs unless someone redacts them. The tokens are well built otherwise, with scopes, URL restrictions, one-hour temporary tokens and documented rotation, and a public-scope token can't change the account. The hosted MCP uses OAuth instead. Release 0.13.0 on 30 July 2026 fixed a query-parameter injection through directions_tool's exclude field and said so in the changelog. Responses carry third-party POI names and attributes with no injection guidance. Per-token usage reporting is unchecked. SOC 2 Type II, SOC 3 and a HackerOne bounty, but no security.txt. Four, because a hijacked agent can only read and spend, and the token in the URL is the caveat.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“21 write tools held back by a prompt”

42 MCP admin tools, 21 of them mutating, no readOnlyHint or destructiveHint, and the only thing between a hijacked model and a model delete is a rule in the system prompt. The docs say there's no code-side preview or apply step. --read-only drops the 21, and it's the first flag I'd want set. The HTTP side is better built than it ships. With accounts on, per-user keys are stored as HMAC-SHA256, revocable, carry a role and per-model and per-feature permissions, and never go in a query string. With nothing configured, every caller on a loopback, LAN or VPN bind gets every route, model installs and settings included, and only a public bind is refused. Shared LOCALAI_API_KEY keys are full admin. CVE-2026-59707, an unauthenticated SSRF through POST /models/apply, is guarded in the code from v4.8.0 at the latest, with no project advisory, and SECURITY.md still calls 3.x current. Three because the read-only switch and accounts exist, and neither is the default.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Sound tokens, off by default, and no security policy”

Zero CVEs at NVD, zero advisories, and nowhere to file one. There's no SECURITY.md in the public repositories, no disclosure policy, and the security.txt path answers with a Hub web page. With the app and llmster closed source, a clean record tells me little. The credential model is well shaped. Named sk-lm- tokens, shown once, with permissions picked at creation, sent in a header. Which permissions exist, the docs show only in screenshots. And Require Authentication is off by default, so any local process can call port 1234. API access to the owner's mcp.json servers sits behind its own switch and needs authentication on. The app asks before each MCP tool call with editable arguments, but tool calls made through the API run without that prompt, and that's the path an agent takes. Three because the boundaries look sound once switched on, and nobody outside Element Labs can check them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Keys in the header, disclosure in public”

Ten published GitHub advisories with CVEs and fixed builds, four from January to March 2026, the worst an unauthenticated code-execution path in the RPC backend (GHSA-j8rj-fmpv-wcxw, 9.8 at NVD). Then on 1 June 2026 SECURITY.md switched private disclosure off, asked for fixes as public pull requests and said emails would be ignored, while a paragraph below still asks for private advisories. A reporter is now told to fix in the open. Keys are optional and go in a header, never the query string, which is the first thing I check. They're off by default, carry no scopes and change only with a restart, and CORS reflects any origin with credentials unless tools or MCP are on, so a web page can call a keyless server on localhost. The Docker examples bind 0.0.0.0 with no key. Built-in tools, MCP and --agent stay off and tools can run in a container. Three because every guard exists and most ship switched off.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Anonymous by default, and pip installs the unfixed 1.42.10”

Port 42110 published on every host interface, --anonymous-mode in both documented quick starts, and KHOJ_ADMIN_PASSWORD=password with KHOJ_DJANGO_SECRET_KEY=secret as the Compose file's examples. Anonymous mode answers every request as a default user and doesn't mount /auth, so no key exists to require. With sign-in on, kk- keys sit in plain text with no scopes or expiry, and the web app revokes one by sending it as a token query parameter. Deletes run unconfirmed, the account included through DELETE /api/self. pip install khoj gives 1.42.10, which lacks the fix for CVE-2025-69207 (Notion OAuth IDOR, 5.4), logs the Notion OAuth token response at info level and sends the caller's IP in default-on telemetry. Research mode feeds web, file and MCP text to the model with no injection guidance. No SECURITY.md, and security.txt returns 404. Which image latest points at today is unchecked. One, because the documented Compose setup answers anyone who reaches the port as the default user.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“The 0.0.0.0 fix has waited 71 days for a release”

71 days. That's how long the fix for GHSA-x6p8-7cp8-c3p6 has sat on main with no release carrying it, and the advisory itself is unpublished. In 0.8.4, still the latest release, binding the Local API Server to 0.0.0.0 swaps the Trusted Hosts list for a wildcard, so any Host is accepted and any Origin reflected with credentials. Pair that with the default key, which is empty, and any web page the owner visits can call the server. The docs flag the 0.0.0.0 bind as risky and advise a key there. The key is one shared string with no scopes and no per-client split, and jan serve --api-key is empty by default too. The approval prompt before each MCP tool call is on by default, and server-side tool execution through the API is off, both as they should be. Reports go through Discord or a Google form. Two because the one known hole is fixed in code and still shipping.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Archive and move on one page, drafts on the other”

The developer site lists five MCP tools and says Update Card suggests changes. The help centre, updated 19 September 2026, describes 14 actions, among them moving cards and folders, archiving cards, applying draft edits and changing collaborators. Neither page documents a confirmation step, and the two don't agree on what an agent can write. OAuth works only for clients Guru has pre-approved, with no scopes documented. The fallback is Bearer email:token, and a user token reads and writes with the user's full rights. Collection tokens are the one narrow key, read-only and limited to one collection. An audit log for API or MCP calls is unchecked, and none turned up. There's no injection guidance for the cards and connected documents it returns, and no security.txt, disclosure policy or bug bounty. The impersonation token pages are unchecked. Two, because a hijacked agent on a user token can archive what the user can, and nothing I read would record it.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Project-scoped keys, and a disclosure file with one line”

Keys are Bearer tokens scoped to a project, with custom request limits per project and model permissions at organisation and project level. A read-only Reader role, request logs and usage per project mean an operator can see what a stolen key did. The data page says nothing is retained by default, up to 30 days for reliability and abuse monitoring, and zero retention is a Data Controls setting any customer can turn on. Storage is Google Cloud in the US. The training ban sits in the services agreement per the listing, and the data page doesn't mention training. I found no key rotation documented. groq.com's security.txt holds a Contact line and nothing else, and the trust centre needs JavaScript, so certifications and any bug bounty are unchecked. Four, because a hijacked agent gets a project's spend, throttled by its limits, and the disclosure side is unread.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Wildcard CORS, TLS checks off, and no reply since June”

Two security reports filed on 26 June 2026, both public issues, both unanswered, and no commit to main since 27 May 2025. #3681 is the one an owner should read first. The local server on port 4891 has no authentication and sends Access-Control-Allow-Origin: * on every response, so while it's on, any web page in the owner's browser can call /v1/chat/completions and read the answers, LocalDocs snippets from the owner's files included. A Host-header fix against DNS rebinding has sat on an unmerged branch since May 2025. #3682 is the supply chain. The model catalogue and fallback downloads come over plain HTTP, and nine request sites turn TLS certificate checks off, model downloads among them. No SECURITY.md, no security.txt, no advisories. The server is off by default and has no write actions, and that's the whole of the defence. One because both reports sit unanswered and main hasn't moved since May 2025.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Two 9.3s this year, one in tool confirmation”

CVE-2026-18236, CVSS 4.0 9.3, let forged continuations in tool confirmations run tools without a real approval in ADK before 2.5.0. That's the control I'd lean on, and it was forgeable. CVE-2026-4810, also 9.3, let an unauthenticated attacker run code on a server hosting ADK 1.7.0 to 1.28.0, local ADK Web included. Both fixed and published by Google as CNA, neither as a GitHub advisory. Otherwise the controls are the right ones. Tool confirmation, before-tool callbacks, a Model Armor plugin, a safety page on indirect injection through tool results, advice to always pass tool_filter, and sandboxing recommended for model-written code. Message content in traces is opt-in. It's a library, so the credential is whatever you hand it, a service account or the user's OAuth token. SECURITY.md routes reports to g.co/vulnz with a one-day triage target, and bounty scope is unchecked. Three, because the design is sound and the boundary that matters most broke this year.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Nineteen scopes, and a global token that can be anyone”

19 scopes on a Glean-issued token, optional expiry, and every credential in the Authorization header. OAuth comes from Glean's own server with dynamic client registration an admin can restrict or switch off, and every read keeps the source system's permissions per document. The weak joint is a Super Admin's global token, which impersonates whoever X-Glean-ActAs names, so one leak can act as any user. Write tools (artifacts, memory, run_tool, data_analysis) have no documented confirmation, and whether the MCP tools carry readOnlyHint or destructiveHint is unchecked behind a sign-in. gmail_search, outlook_search and web_search return mail and pages that outsiders write. The security page claims 96.9 per cent injection detection, a vendor figure, and the MCP security page gives hosts no injection guidance. MCP activity logs filter by tool and user, there's a Bugcrowd bounty, no CVE at NVD and no security.txt. Three, because the scoping is careful and neither the write tools nor the global token has a documented brake.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Raw pages back, and key scopes only on Enterprise”

Scraped pages come back raw. Only retained Alexandria results carry a line telling the model that source content is data, not instructions, and Threat Protection, which blocks risky URLs, is Enterprise only and off by default. Keys are revocable Bearer tokens, but keys locked to endpoints and formats are Enterprise only. The README says never to put a key in the server URL, yet the legacy key-in-path routes still exist, undocumented. What narrows a session is the endpoint, 3 tools keyless and 8 on the search-only endpoint under its own OAuth identity. Write tools (monitor create, update and delete, interact) carry destructiveHint, and Alexandria terms need explicit consent and confirmed: true. No per-call log for operators. SOC 2 Type II, a valid security.txt, no bug bounty found, and no retention period for scraped content outside Enterprise. Three, because the small endpoints contain an agent and nothing contains the pages.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Writes off by default, and every call reports to Mixpanel”

Twelve write tools stay off until an operator sets TOOLS_IS_MUTATION_ENABLED=true, and save_document may only update the agent's own documents unless the operator changes that. That's the read-only default I look for. Personal access tokens last 1 hour to 365 days (never-expiring is off by default), can be revoked and carry the user's full privileges with no scopes. HTTP mode refuses a shared token and rejects ?access_token=, so the key stays out of URLs. Once writes are on there's no confirmation and no annotation on them, while the docs page says every tool carries destructiveHint. Every tool call sends a Mixpanel event, on by default, with the client's name and up to 500 characters of any error message, which can carry catalogue URNs, and no page mentions it. Returned text gets HTML and base64 stripped, with no injection guidance. Four advisories in twelve months, the worst CVE-2026-25644 (7.5), all fixed. Three, because the default is narrow and the telemetry isn't disclosed.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Read-only by default, with every write a step-up”

A plain CLI login gets a read-only baseline, and every write is a step-up. That's the default I want and rarely get to read. Workspace API keys carry read or write scopes per product, an optional expiry and CIDR ranges. A key can never mint another key, and org:owner is never delegable. The hosted MCP and CLI use OAuth with consent per workspace. Destructive MCP tools are annotated, and billable voice calls need a person to confirm in the browser. SMS sends don't, so an agent with write scope texts without asking. Inbound messages are untrusted text, webhooks are signed with a per-endpoint secret, and nothing I read gives prompt-injection guidance. An owner-only org:audit scope covers audit records. A valid security.txt, expiring 17 June 2027, points to HackerOne, alongside ISO 27001 (the 2022 revision) and SOC 2 Type 2. No retention periods found. Four, because the default is read-only and the one unconfirmed write is a text message.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Live audio kept nowhere, batch kept until deleted”

Real-time and fast transcription audio isn't stored, and customer audio isn't used for training. The data privacy page, the privacy statement and the product terms agree on both. Batch is the exception. Output stays in Microsoft storage until it's deleted or timeToLive expires, so a batch job without a TTL leaves transcripts behind. The credential model is sound. Two regenerable resource keys in the Ocp-Apim-Subscription-Key header allow rotation, or Microsoft Entra ID tokens bring role-based access, which Microsoft recommends. Azure Monitor and the activity log record resource actions, but whether each Speech request is logged is unconfirmed. MSRC's disclosure policy, the Azure bounty programme, SOC 2 and ISO 27001 reports and public advisories are all in place. The microsoft.com security.txt passed its Expires date on 23 September 2026. Four, because the live paths keep nothing and the batch path keeps everything until someone sets a TTL or deletes it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Writes wait for approval, and read-only is a request to Atlan”

By default the hosted server lists 20 write and 4 admin tools, manage_asset_lifecycle (archive, restore, purge) and delete_custom_metadata_set among them. Each write returns a preview, waits for approval and needs the user's own edit permission, and nothing I read says a person, not the model, must give that approval. Read-only mode strips write, admin and lifecycle tools, and a customer gets it by asking Atlan. OAuth with PKCE runs each call as the user under their personas and policies, API tokens carrying more than one persona are refused, and no secret travels in a query string. Scopes and token expiry are unchecked. query_assets refuses anything but SELECT, WITH, SHOW, DESCRIBE and EXPLAIN and still returns up to 100 warehouse rows, beside an MCP security page that says the server handles only metadata. Gateway injection guardrails are claimed, not described. Calls are logged with arguments redacted. Four, because writes stop for approval, and the off switch belongs to Atlan.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 3 October 2026. No calls made.

“Path traversal reported in February, still in main”

Seven months. Issue #194, filed on 24 February 2026, reports path traversal in Mixpost Lite's system log download and clear endpoints, and on 1 October the main branch still builds the path from the log directory and the user-supplied filename, so a signed-in user can read or truncate files outside it. An XSS report (#204) has been open since 17 June 2026. Neither has an advisory, though SECURITY.md asks for reports by email, and whether Pro, which carries the API and MCP, shares the code is unchecked. The token model is fair. Personal access tokens expire after 7 to 90 days or on a set date, and a Viewer-role token can only read. Otherwise a token carries its creator's full authority, and delete-post and delete-post-version run with no confirmation and no MCP annotations. Data stays on your own server. Two, because the read-only role is sound and the disclosure process isn't answering.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The token can still travel as api_token”

Older Pipedrive docs still show the personal API token as an api_token query parameter, where it ends up in logs, and that token carries the user's full rights. The x-api-token header is the safe route, and whether the query form still works rests on the 30 September check. The MCP server is better on credentials, OAuth only through oauth.pipedrive.com with scopes for deals, contacts, leads, activities, products and search. Pipedrive doesn't publish its tool list, though, so an operator can't see what an agent may change before connecting, and no read-only mode or write confirmation is documented. Email sync and notes reach the model with no injection guidance. The launch post says every MCP action lands in Pipedrive's change logs, and ISO 27001, ISO 27701, SOC 2 Type 2 and SOC 3 sit in the trust centre beside a disclosure programme. No security.txt. Two, because I can't bound a tool list I can't read.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Temporary credentials down to a path”

Four token levels, Admin or Object, each read-write or read-only, with the object levels limited to named buckets and an optional expiry. Under them sit temporary credentials bound to one bucket, a set of operations and optional paths, which expire on their own. That's the grant I'd hand an agent. Bucket lock rules block deletion and overwrite, with no confirmation step. The Workers Bindings MCP server can delete buckets, and the Code Mode server's execute tool calls any endpoint the token allows, so the token is the whole boundary there. Data Access Logs went GA on 4 September 2026 and record successful object operations, best effort, excluding errors and jurisdictional buckets. Stored bytes come back with no untrusted-content guidance. cloudflare.com's security.txt points at HackerOne but had no Expires field on 30 September, and certifications weren't re-read this run. Four, because the credential is as narrow as storage gets and the logs still miss failures.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Good walls, and the front door is yours to build”

There's no hosted credential to audit, which cuts both ways. The sandbox sits behind a Worker you write, the starter template has no auth, and the docs say sandbox IDs aren't cryptographically secure, so the template deployed as it ships would answer anyone who can reach the Worker and guess an ID. Behind that door the walls are good. Each sandbox is its own VM, enableInternet = false or a deny-by-default allowedHosts list cuts egress (GA, though internet is on by default), and outbound handlers in the Worker add credentials the container never sees. security.txt lists HackerOne and a disclosure policy. Open bug #844 has allowedHosts failing closed for approved hosts, the safe direction to fail. Certifications, SDK advisories and account audit logs went unchecked. Three, because the first boundary an agent meets is whatever the operator remembered to write.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A total delete and untrusted inputs, nothing between”

forget with everything=true wipes all of a user's memory, and I found no read-only key, no confirmation step and no annotation to stop an agent sending it. Cloud takes one plain X-Api-Key per tenant with no scopes found, and the local REST server runs with no auth until you turn it on. Cognee ingests documents and synced Slack, Notion, Linear and Google Drive content and hands it back to the model, with no prompt-injection guidance, so a poisoned wiki page would sit in memory as a standing instruction. Tenant isolation is better, a Postgres database and Kubernetes namespace per tenant. No audit log. The security page says Cognee holds no SOC 2, ISO 27001 or equivalent audit, there's no security.txt, and those pages weren't re-read on 1 October. Two, because the inputs are untrusted, the delete is total and nothing sits between them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Caps the agent can't change, and an unreleased exfiltration fix”

AgentKit on npm is still 0.10.4 from 19 December 2025. Its flaunch and zora providers read any non-URL image argument as a local file and uploaded it to a public IPFS pinning service, so an injected agent could publish host files. PR #1432 fixed that in source on 19 August 2026 with no advisory, and it hasn't shipped, nor has the 3 September fix for attacker-set token names. Only agents that register those providers are exposed. AgentKit gates nothing else, as its README says. The wallets are better fenced. Agentic Wallet signs in by email OTP, the agent never holds a key, and the operator sets max per call and per session where the agent can't change them. Server wallets sit behind a default-deny policy engine, scoped CDP keys and a separate wallet secret. HackerOne bounty, and coinbase.com's security.txt had expired. Three, because the wallets hold and the AgentKit package still ships a known hole.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A cent a call, and token names anyone can write”

Payment is the credential on the four x402 paths, so there's no key to leak, only the paying wallet, which signs a fixed $0.01 USDC authorisation per call on Base. Everything is read-only market data, the transfer runs only when data comes back, and x402 calls are capped at 30 a minute, which bounds what a looping agent can spend. The risk is what returns. DEX search hands back token names and symbols that anyone launching a token can set, and I found no injection guidance for them. The keyed Pro API uses one account key in X-CMC_PRO_API_KEY with no scopes, and whether it still accepts the key in a query string, or lets you rotate it, is unchecked. No security page, disclosure policy or certification turned up in the API docs, and the privacy policy's word on request logs wasn't read. Three, because the read-only surface is small and nobody says where to report a flaw.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Roles per operation, and delete_resource unguarded”

Integration credentials here bind to a custom role you set per resource and per operation, sales channel tokens are scoped to a market, and it's OAuth 2.0 throughout. The docs tell you to give an agent a dedicated role with minimal permissions. The Core MCP takes the same tokens, so the role is its boundary, and it has three write tools, create, update and delete_resource, with no annotations and no documented confirmation. Merchant- and shopper-entered data comes back with no injection guidance. The change trail got thinner this year. The per-resource versions endpoint was removed on 8 May 2026, leaving event stores with a retention policy added on 18 June. SOC 2 Type 2, ISO 27001 and PCI DSS Level 1 are vendor claims on the security page. There's no security.txt or bounty, and the privacy policy dates from October 2020. Three, because a narrow role is easy to build and nothing else stops a delete.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-scoped keys, and a bash sandbox on by default”

Rube closed on 16 May 2026, so this reads the platform it ran on. Project keys split session management from execution, read-scoped keys have worked for tool operations since 21 September 2026, and each key takes an IP allowlist. End users authorise apps through hosted Connect Links, and provider tokens are redacted from responses by default. Sessions can drop toolkits or keep only readOnlyHint tools. The default that bothers me is the sandbox, whose meta-tools run arbitrary Python and bash in Composio's cloud and are on by default in sessions. Nothing asks before a destructive tool runs. Third-party mail, chat and documents come back with no injection guidance. Execution logs keep arguments, responses and user ID per call for up to a year, an audit trail and a payload store, unless ZDR is bought. SOC 2 Type II, no published advisories, no bounty, no security.txt. Three, because the brakes exist and the sandbox has to be switched off by hand.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only tools, and the query goes to three model vendors”

Nothing here writes. Both tools carry readOnlyHint: true and destructiveHint: false, so a hijacked agent can't break anything through Context7. What it can do is leak. Model-written queries are stored anonymously for benchmarking with no retention period given, and sent to OpenAI, Google Gemini and Anthropic for reranking, so a query that quotes proprietary code reaches three vendors. Results are third-party documentation, and Context7 says a two-pass injection and malware classifier screens indexed content, which a desk read can't test. Keys carry the ctx7sk prefix, are hashed at rest and rotatable, have no scopes, and go in a Bearer header or X-Context7-API-Key, with OAuth through Clerk as the alternative. API logs last 30 days. SOC 2 Type II through Upstash and a SECURITY.md with private reporting that still lists only 1.0.x as supported while 4.1.1 ships. No bug bounty, security.txt or advisories. Three, because the content coming back is the attack surface.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A whole account per key, and admins see every key”

A Copper key goes in X-PW-AccessToken with its owner's email in X-PW-UserEmail, and it carries that user's full rights. There are no scopes and no read-only keys, and admins can see and generate every user's keys, so an admin session reaches everyone's credentials. OAuth 2.0 exists for partner apps, but I found no scope list and no revocation docs. Records hold email and activity synced from Gmail, outside text an agent will read with no injection guidance. I found no API audit log, so a hijacked agent's edits would leave nothing to reconstruct them from. Reports go to security@copper.com and the security page cites outside penetration tests, but it names no certification and still lists Privacy Shield, struck down in 2020. The trust centre gave the research run a 403, and there's no security.txt. One, because the key can't be narrowed, its use can't be traced and its revocation isn't documented.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only data, scraped text unmarked”

Five tools on the MCP, and MCP v2 signs in with OAuth 2.1 through the dashboard and looks the team key up server-side, so no key sits in the client config. The data surface is read-only apart from webhook subscriptions, credits are only taken on a 200, and v2 stops to confirm record count and credit cost before large pulls, which covers the one thing an agent can do wrong here. REST takes an apikey header with no scopes I could find. Results are scraped public web content, profiles, posts and job ads, handed back with no prompt-injection guidance, which is where I'd expect an attack. The site shows ISO 27001 and SOC 2 marks with no report details, no security.txt and no bounty. The terms name Deeptrace Inc. while the privacy policy names Binary House LLC as controller. Three, because the blast radius is small and the scraped text is a channel nobody fences.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Free/busy-only tokens, and an app secret for the MCP”

free_busy alone is a scope here, and so is read_only, with delete_event granted apart from create_event. An agent that only needs availability can hold a free/busy-only token, and only_managed limits event access to what the app created. The weak link is the application's client_secret. It's the Bearer for application calls such as Availability and for the single-tenant MCP, and it reaches every connected account. The MCP is early access with no published tool list, so annotations are unchecked. Nothing confirms a delete, and event titles and descriptions from third parties come back with no injection guidance. Retention has numbers, 30 days for third-party events after authorisation ends, application logs up to 90 days, backups 7 days in-region. ISO 27001, 27018 and 27701, SOC 2 Type 2 and a public bug bounty, but no security.txt. Four, because the scopes go as narrow as I'd ask and only the single-tenant MCP route skips them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Caps enforced onchain, and a checkout agent reading any page”

Agent Wallet limits (spend cap, allowed counterparties, time window) are enforced onchain, and neither the builder nor Crossmint takes custody. Agent Card limits sit at Visa and Mastercard, and the agent gets one-time or encrypted credentials, never the card number. That's the shape I want for money. A hijacked agent can lose up to the cap and no further. API keys split into server and client keys with named scopes such as wallets:transactions.create, and client keys can require a JWT from your own auth provider. The weak point is Agent Checkouts. It browses any merchant URL, has no prompt-injection guidance, and runs in production only, so the first test spends real money (under a hard cap per run). No API audit log found, and key rotation is unchecked. security.txt points to a disclosure policy with a 5 working day reply, and SOC 2 is cited without the report type checked. Four, because the caps hold outside Crossmint's own code.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Per-key caps, no security programme”

Zero. That's what I found for security.txt, bug bounty, disclosure policy and certification combined. The key model is the opposite, the best I've read in lead data. Several named keys per account, each with endpoint restrictions and an optional monthly credit cap since July 2026, active, inactive and deleted states, usage filterable by key, and X-Credits-Used on every response. A key barred from live endpoints is a key that can't fetch the open web, and that matters, because live web fetch, web search and social posts return untrusted text with no injection guidance. The MCP docs don't separate read and write tools or confirm before a watcher sets up a standing job. The terms are a website-use notice naming CrustData Inc., the privacy policy names Crustdata Technologies Inc., and I found no API terms. Three, because the keys let an operator fence the agent, and nothing tells me how the vendor fences itself.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Four CLI advisories, and no stated defaults”

Four high advisories named the CLI between 2 October and 3 November 2025, two of them through MCP, one a code-execution path through a permissive CLI config and one a sensitive-file overwrite bypass. All fixed. What I can't find is the starting position. The docs list allow and deny rules for Shell, Read, Write, WebFetch and Mcp, with deny winning, plus a read-only ask mode, but not what runs without asking by default, whether --sandbox starts on, or whether the editor's network block reaches the CLI. --force runs any command no deny rule matches, and --approve-mcps approves every MCP server at once. Nothing I found describes what the CLI sends home, Privacy Mode's default isn't stated, headless runs hold a long-lived CURSOR_API_KEY, and the install script checks no checksum or signature. Closed source, so there's no code to settle it. Two, because the boundaries I'd need to judge are the ones left unwritten.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Scopes that stop at the sandbox door”

Keys take per-action scopes, write:sandboxes apart from delete:sandboxes, plus expiry and immediate revocation, the best key model of the sandbox listings on paper. Then the docs add that any valid key in the organisation can reach a running sandbox whatever its scopes, so a narrow key still reaches everything that's running. Container sandboxes share the host kernel, only the Linux VM and Windows classes get their own, and the docs don't say which class an empty create call gets. Tiers 1 and 2 get restricted egress that can't be loosened per sandbox, the safer default, with allow lists from Tier 3. Audit logs sit behind their own scope, with log streaming and webhooks. I found nothing on keeping credentials out of the sandbox, no security.txt, and no SOC 2 report or bug bounty. Three, because the scopes are right and the defaults around them aren't.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Expiring role keys, and call audio kept for training by default”

Keys carry an owner, admin or member role, can expire on a date or after a duration, and can be tagged, and browsers get 30-second JWTs from /v1/auth/grant so the real key stays on the server. Member keys narrow what a stolen key does, but there's no read-only agent mode. The function-call hold waits for a confirmed user turn before irreversible tools run, and without it calls can fire on a speculative reply. Your own LLM and TTS keys travel in endpoint.headers of the Settings message, so Deepgram holds them in flight. The default worries me most. Audio and transcripts are kept for model improvement unless mip_opt_out is set. No prompt-injection guidance, no audit log of account actions, no security.txt (carried over from last week's check) and no bug bounty. SOC 2, HIPAA and PCI DSS are vendor-stated. Three, for good keys and a bad default.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Policy at every fetch, silence on the vault”

Four sign-in routes for an agent (client credentials, device code, CIBA, RFC 7523 JWT bearer), and Policies decide which tokens each identity may fetch, evaluated at issuance and exchange. Client-credentials tokens can't read user tokens. A management key bypasses Policies, and the Agent Auth SDK makes you opt in before it will use one, which is the right default. CIBA can put a person between the agent and the token. The key travels in the Authorization header, not a URL. What worries me is the vault. The docs don't say how vaulted third-party tokens are encrypted, security.txt was a 404 when the research run checked, I found no bug bounty, and the SDK's own endpoint file marks its device-code and CIBA paths as unverified. Token deletion can't be undone and asks for nothing. Four, because the boundary is documented and enforced, and the one thing I'd most want to read about isn't written down.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only tokens, and an MCP server that lists deletes”

Service tokens bind to one config and are read-only by default, with --max-age for expiry, and on Team an OIDC token from GitHub Actions, Kubernetes or EC2 trades for a short-lived one, so a shared runner holds nothing static. The MCP server is the soft spot. With no flags it exposes every API operation, deletes and workplace updates included, with no annotations and no value masking. --read-only and --config narrow it, and it warns at start-up when a production config or write tools are exposed. Revocation leaks, since the CLI keeps serving its encrypted fallback file after a token is revoked, and open CLI issue #542 reports that secrets delete prints every remaining value in plain text. Activity logs run 3 days on Developer and 90 on Team, and I found no per-read access log. SOC 2 and ISO 27001 claimed and HackerOne for disclosure, while security.txt is blocked by robots.txt. Three, for the defaults on the MCP side.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Per-route scopes, and a share tool beside shared files”

281 routes in the Stone spec, each tied to one OAuth scope such as files.content.read or sharing.write, with short-lived access tokens, refresh tokens and App folder apps confined to one folder. The hosted MCP server is the weaker half. It's beta, signs in with OAuth and dynamic client registration, and reads up to 5 MB of file content from anything the user can see, shared folders included. Its tools put CreateSharedLink and CreateFileRequest next to GetFileContent, and I found no prompt-injection guidance and no documented confirmation for deletes. A poisoned file in a shared folder and a link-making tool in the same session is the path I'd watch. Team admins can block app connections, and Business teams get audit events through team_log, while personal accounts see linked apps only. Intigriti runs the bounty, and the security.txt lacks RFC 9116 fields. Three, because the REST scopes are fine-grained and nothing documented narrows the MCP server's reach.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Small blast radius, one unscoped key”

HackerOne sits behind a security.txt valid until 9 April 2027, which is more than most of this category publishes. The surface is small. Enrichment and verification only read, the one write is webhook settings, and results come back as cleaned names, titles and company fields with little free text to carry an injection. A hijacked agent can burn credits and point results at another callback URL, and that's about the limit. One API key per account goes in the X-Access-Token header with no scopes, and the MCP takes OAuth or the same key as a bearer token. There's no per-call log for operators. No SOC 2 or ISO 27001. A DPA is published, but the pricing page says processing runs on its own EU servers while the data charter mentions US subcontractors under SCCs. Four, because there's little here for a compromised agent to break, and the one key does everything.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Firecracker walls, one unscoped key”

The sandbox is a Firecracker microVM with its own kernel. Egress can be switched off or limited by domain, IP or CIDR, GA, though it's on by default. Stored secrets are filled into outbound HTTPS headers by the egress proxy outside the sandbox, with per-host transforms in public beta, and workload identity tokens give code inside short-lived credentials. Then the key. One API key per project in X-API-Key, with no scopes and no documented rotation, and no audit log found for the hosted service. A hijacked agent holding it can do whatever the project can, and nothing records it. Personal access tokens were switched off on 1 August 2026, which shrinks the list of things to leak. security@e2b.dev and a SOC 2 Type II report with a pen-test summary, no security.txt or bug bounty. Three, because the sandbox is well walled and the key that drives it isn't.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“95 tools on one full-CRUD secret”

Ninety-five MCP tools, reads and writes across orders, pricing, promotions, carts and accounts, all running on a client_credentials token that the docs say has full CRUD. The server takes the client ID and secret as environment variables and refreshes tokens itself, so the model never holds the secret, but whatever hijacks the model inherits everything that secret can do. No read-only mode in the MCP, no confirmation, and nobody has published whether the tools carry destructive annotations. The implicit grant reads only the live catalogue, and custom API role policies can narrow a key, which is the only brake I found. Merchant and shopper text comes back unmarked. No audit log, elasticpath.com/security returns 404, there's no certification claim, and the MCP's source and licence aren't public. Two, because the narrowing exists on the platform and the official server documents none of it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Keys scoped to endpoints, with a credit cap on each”

API keys can be limited to endpoint groups, given a credit limit, owned by a service account and rotated, and keys found on GitHub are disabled. A credit cap bounds what a hijacked agent can spend as well as what it can touch. The hosted MCP server signs in with OAuth and asks for scoped consent to agents and speech, and MCP clients can require confirmation per tool. Private agents take a signed URL or conversation token minted server-side, so the main key stays off clients. Conversation data is kept 2 years by default, set per agent in days, with a per-agent zero retention mode. Audit logs over 100 endpoints are Enterprise-only. security.txt was valid at last week's check, and certifications and a bounty weren't re-checked. The caveat is the caller. Agents feed caller speech to an LLM and I found no prompt-injection guidance. Four, because the key model is the best I read in this set.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Professional clones are verified, instant ones take your word”

Professional clones are own-voice only and need a spoken verification matched to the training samples. Instant clones rest on an attestation, so a hijacked agent holding a minute or two of somebody's audio can make one, with high-risk and celebrity voices blocked and nothing else in the way. An AI speech classifier and C2PA support are public. Keys can be limited to chosen endpoints, capped with a credit quota and set to expire in 15 minutes to 30 days, so an agent's key never needs to reach cloning, and leaked keys are disabled through GitHub secret scanning. The History API lists every generation with voice, model and date. Training on content is on by default with a self-serve opt-out, and the Terms take a perpetual, irrevocable licence to User Voice Models while promising deletion on request. security.txt is valid to 1 March 2027, with SOC 2 Type II. Three, because the instant tier is one attestation from an impersonation.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Private-key JWTs and nowhere to report a flaw”

An RS256 JWT, signed with the application's private key and valid for 24 hours at most, rides on every call, so no shared secret crosses the wire. The cost is key material on each agent host, and whoever holds it can mint a token for the whole application, which carries no scopes. The limits are good. Restricted mode confines a production app to whitelisted accounts, payment initiation stays off without a PISP licence, and DELETE /sessions closes the bank consent where the bank allows. Merchant-written transaction text comes back unmarked. No security.txt, disclosure policy, bug bounty or certification, and Control Panel request logs are unchecked. There are no public terms (the FAQ points to a contract agreed by email) and the privacy policy needs JavaScript, so the FAQ's line that nothing is stored or cached has no contract I could read behind it. Three, because the boundaries are sound and nothing says who to tell when one breaks.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“25 read-only tools, SOC 2 under consideration”

All 25 MCP tools carry readOnlyHint and openWorldHint, and the API only reads. That's the half of my checklist Enrich Layer passes. The MCP runs locally over stdio and reads ENRICH_LAYER_API_KEY from the environment, and Sentry error reporting stays off unless SENTRY_DSN is set, which the README says plainly. The other half is empty. One secret bearer key per user, no scopes, and rotation went unchecked. A credit-balance endpoint is the only window into usage. Profiles carry free text written by the people they describe, with no injection guidance. There's no security.txt, disclosure policy, bounty or certification, and the privacy policy says SOC 2 is under consideration. It lists data brokers among its sources and gives no retention periods. Three, because a read-only tool limits what a hijacked agent can do, and the vendor publishes nothing about what happens on its side.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Fenced to named folders, with no brake on writes”

Fourteen tools, every one carrying readOnlyHint, and write_file, edit_file and move_file marked destructive, so a host can gate them. That gate is the only one. The source confines paths to the allowed directories from arguments or MCP Roots and resolves symlink targets before checking them, the fix for CVE-2025-53109 and CVE-2025-53110, both High, published on 1 July 2025. There's no read-only switch inside the server (the README points to read-only Docker mounts instead), and write_file overwrites without asking. No credentials to steal. File contents reach the model unmarked, which matters once a cloned repository or a download sits in an allowed folder, and there's no call log. SECURITY.md says the repository isn't eligible for vulnerability reports, yet those two advisories went out through it. Three, because the fence is real and has been patched twice, and nothing inside it slows a write.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Any voice from 10 seconds, licensed to the vendor for good”

About 10 seconds of audio gives a voice model at once, or no model at all, since TTS takes reference audio inline per request. There's no consent field, no speaker check, no watermark and no detection tool, only guidance in the docs to clone your own voice or one you have written permission for. A compromised agent can impersonate anyone it holds a clip of. The terms (Hanabi AI Inc., effective 18 August 2024) take a perpetual, irrevocable, royalty-free licence to submissions, training included, with no opt-out, and warn that deleted content may not be fully removed. The privacy policy keeps content as long as needed to run the service. Plain API keys with no scopes. No security.txt, disclosure policy, bug bounty, SOC 2, DPA or subprocessor list found. One, because every clip an agent uploads, someone else's voice included, becomes Fish Audio's to keep.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No delete tool, and a page on malicious instructions”

None of the 38 MCP tools deletes a record. They create and update people, companies, objects, notes, groups, interactions and tasks, and can remove group members, all with the signed-in user's full access and no read-only mode. The docs urge a person to confirm each step, though nothing enforces it. folk is also one of the few vendors here with a security best-practices page warning that untrusted tools and content can carry malicious instructions, and call transcripts only come back when the workspace's privacy rules allow. REST is weaker. Workspace API keys have no scopes, and I found no rotation or expiry docs. Errors carry a requestId, but I found no audit log. security@folk.app takes reports and TLS 1.2 and AES-256 are stated, while no SOC 2, ISO 27001, security.txt or bounty turned up. Three, because the MCP tool list is restrained and every credential behind it is all or nothing.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No scopes, so the token is the whole business”

Every token carries the authorising user's full access. OAuth 2.0 authorisation code, one-hour access tokens and refresh tokens that rotate on each refresh are sound, and there's a client secret rotation guide, but there are no scopes and no read-only mode, so an agent asked to read a profit and loss can also create invoices, explain bank transactions and edit contacts. The one brake is that invoices stay drafts until a transition call marks them sent, which limits what a stray create does to a customer. Bank descriptions and contact text written by third parties come back with no injection guidance. I found no per-app audit log or API activity view, and couldn't establish whether a user can see or revoke an app's access inside FreeAgent. security.txt runs to 17 April 2027, with a disclosure policy, discretionary rewards and Cyber Essentials Plus, and no ISO 27001 or SOC 2 found. Two, because nothing stops a read job from writing.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read scopes per resource, refresh tokens forever”

Scopes split read from write per resource (user:invoices:read, user:journal_entries:write), so an agent that only reads the books can hold only read scopes. That's the right door. Access tokens are short-lived JWTs, there's a revoke endpoint and redirect URIs must be HTTPS, but no PKCE is mentioned. Refresh tokens never expire. They're single use, with one alive per user per app, so a leaked one stays valid until the next refresh. Invoices stay drafts until marked sent. Client-entered text comes back with no injection guidance, and I found no audit log or API activity view. PCI DSS Level 1 with an annual third-party audit and a responsible-disclosure policy, while security.txt answered 403 on 30 September and no bug bounty or SOC 2 turned up. No advisories found. Three, because the scopes are good and nothing records what a token did with them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One key per user, with bulk delete in reach”

Authorization: Token token=<key>, one per user, bounded only by that user's role and visibility. No scopes, no read-only key and no OAuth for the CRM API, and the reference doesn't say whether the key can be regenerated or revoked. Bulk delete endpoints exist, so a hijacked agent holding a manager's key can clear records in bulk, and nothing in the API asks first. Records carry email, notes and chat text from outside parties, and I found no injection guidance. The disclosure side is the strongest part. Freshworks runs a HackerOne programme, publishes a security.txt without an Expires field and shows ISO, AICPA and Cyber Essentials Plus logos, and audit logs come with the Enterprise plan. Below Enterprise there's no log at all that I could find. Two, because the key is the user's whole role and the delete path has no brake.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Webhooks signed with the API key itself”

HMAC-SHA1, keyed with the account's API key. That's how webhooks are signed, so every service that verifies a FullEnrich webhook has to hold a key that can spend credits and pull contact data. I'd rather see a separate signing secret. REST takes a bearer key with no scopes I could find. The hosted MCP signs in with OAuth and keeps no static secret in the client, which is the right call. It isn't read-only, since enrichment and export spend credits, and confirmation before a paid step is recommended but left to the client. The optional skills add a confirmation before any sequencer change and honour opt-out and do-not-contact signals. Results are mostly structured contact fields. SOC 2 Type 2 per the trust page, disclosure by support email, no security.txt or bounty, and enrichment runs through third-party providers the vendor doesn't name. Three, because the MCP is fenced well enough and the webhook design spreads the account key.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A CVSS 10 in CI, and the sandbox starts off”

CVSS 10, published 24 April 2026. Headless runs in CI trusted the workspace folder and loaded its configuration, and --yolo ignored tool allowlists, so a workflow fed an untrusted pull request or issue could run an attacker's code. 0.39.1 fixed it, and the repository's own advisory page still says there are none. The guards are better than the defaults. Folder trust is on, yolo needs a flag and a setting can block it, there's a read-only plan mode and a TOML policy engine with admin paths. The sandbox is off, though, and the default macOS profile allows network. Open P1 #29310 reports that yolo and auto_edit auto-allow obfuscated shell commands. Usage statistics go to Google by default (no prompts or file contents, per the docs), and the free tier may train on data unless the user opts out. Three, because the walls exist and none of them is up when it starts.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Four advisories, and a policy that refuses reports”

SECURITY.md says the repository isn't eligible for vulnerability reports, and four advisories were published for this server anyway. On 17 December 2025 came argument injection in git_diff and git_checkout that could overwrite local files, missing path validation with --repository, and git_init creating repositories anywhere, all fixed in 2025.12.18. On 25 February 2026 came path traversal in git_add, fixed in 2026.1.14 before publication. Since then --repository and MCP roots confine paths with symlink-safe checks, and refs or paths starting with - are rejected. There are no credentials to steal and no network calls. There's also no read-only mode, git_reset and git_checkout run without confirmation, and commit messages, diffs and file contents from a cloned repository reach the model unmarked. Annotations are right, with git_reset marked destructive, and the only log is git's own reflog. Two, because a hostile commit message can talk the agent into a reset nobody approves.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Deny rules hold, managed settings didn't until 1.0.88”

1.0.88, on 22 September 2026, is the version to check first. Before it, ACP mode, AHP hosts and --server sessions ran with no managed MCP, permission or plugin policy, and the fix appeared only in the changelog. 1.0.79 renamed a sandbox key and ignored the old one, so a false opt-out reverted to on. The prompts are sound. It asks before the first use of each tool that can modify or execute, --deny-tool beats --allow-all-tools and every other allow, and a fine-grained token with only the Copilot Requests permission covers CI. The sandbox, with path rules and a host-filtering proxy, is an opt-in preview, and organisation MCP policies aren't enforced. Since 24 April 2026 GitHub may train on Free, Pro, Pro+ and Max interactions unless switched off, and I found no opt-out for product telemetry. Two CVEs this year, one through a nested bare repository's core.fsmonitor. Three, because the prompts hold and the policy around them has leaked.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only by URL, and public issues are the payload”

GitHub published two advisories for this server in 2026, both fixed. GHSA-pjp5-fpmr-3349 (moderate, June) could hand one user's request another user's GraphQL client in HTTP mode, and GHSA-w4q6-qw23-4rg7 (high, July) was a denial of service. The boundaries are the best documented in this batch. OAuth with scopes is the remote default, with per-call scope challenges since v1.11.0 and fine-grained PATs or GitHub App tokens for headless runs, always in the Authorization header. Every remote toolset has a /readonly URL, and --read-only drops write tools even when named. delete_repository makes the user type the repository name through elicitation. delete_file and the rest run without it, and 27 of 35 write tools leave destructiveHint unset. Public issue and comment text is untrusted, and lockdown mode filters it by push access but calls itself best-effort. MCP calls reach the audit log only as ordinary API calls. Four, because read-only is a URL away and injection still arrives through issues.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read only by design, on unmaintained libraries”

No endpoint moves money. The API only reads, and each end user agreement caps access_scope (balances, details, transactions) along with history days and access days, so a hijacked agent's worst day is reading what the user consented to. A secret_id and secret_key pair, posted as JSON, becomes a 24-hour access JWT and a 30-day refresh token sent as a Bearer header. The pair has no scopes. Requisitions can be deleted, which ends a consent early. Merchant-written transaction text arrives with no untrusted-content guidance. The paperwork is thin. The Bank Account Data Service Terms PDF returned 404, the privacy notice gives no retention periods, security.txt lacked an Expires field in the 30 September check, and the portal blocks crawlers, so request logs went unchecked. The official client libraries still draw 28,608 npm downloads a week and have been unmaintained since April 2025. Three, because read-only is the right boundary and the code most agents wrap around it gets no fixes.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Twenty scopes, and delegation that opens every calendar”

From calendar.freebusy and calendar.events.owned.readonly up to full calendar, 20 scopes classed non-sensitive, sensitive or restricted, and the restricted ones trigger app verification. Auth is OAuth 2.0 only, so there's no static key to paste into a URL. The wide door is domain-wide delegation, where a Workspace service account reaches every user. Nothing in the API confirms a delete. The MCP preview guide configures three read-only scopes, warns about indirect prompt injection, points to Model Armor and tells operators to review AI-initiated actions. It also names create, update and delete tools, and which scopes those need is unchecked, as are their annotations. The Cloud console shows traffic and errors per method, not a per-call log. security.txt is valid with the VRP behind it, and certifications went unchecked this run. Four, because the scopes are the finest in this category and delegation can still reach every calendar in a tenant.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Eight MCP tools, none that delete or share”

Google's Drive MCP server has eight tools, for copying, creating, downloading, reading, metadata, permissions, recent files and search, and none of them deletes, moves or shares. It runs on drive.readonly and drive.file, and drive.file limits an app to files it created or the user picked, so the restricted full drive scope never comes into it. Tokens are short-lived and revocable, and Workspace admins can restrict API access per app. The setup page warns about indirect prompt injection through file contents, which is more than most of this category says. The caveats sit off the MCP path. Over REST, an anyone permission can't take an expirationTime, so a public link made by an agent lives until someone deletes it. Audit log coverage of API calls wasn't re-read this run, and the server is Developer Preview. Google VRP covers reports, and the security.txt runs to 2030. Four, because the MCP surface can't delete or share, and a REST share has no clock.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No API keys, and every screening call is audited”

OAuth 2.0 bearer tokens from a service account or Application Default Credentials, and no API-key mode at all, so there's no long-lived string to end up in a URL. Each screening method has its own IAM permission, which means a role can screen prompts without being able to edit the template that decides what counts as an attack. Both methods write Data Access audit logs. The overview says the service is stateless and discards prompts and responses unless logging is turned on. google.com's security.txt runs to 1 April 2030, and the Google VRP, SOC 1, 2 and 3 and ISO 27001 are stated. I found no advisories for Model Armor. The caveat is the input cap. Past 65,536 tokens the injection, responsible-AI and CSAM filters return EXECUTION_SKIPPED, and an agent that reads that as clean can be padded straight past its guard. Four, for that one hole.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No API keys, and reads unlogged until you ask”

API keys are refused outright. Calls carry OAuth 2.0 bearer tokens from a service account or workload identity on GKE, Cloud Run or GCE, so there's no long-lived string to end up in a URL. roles/secretmanager.secretAccessor can be granted on a single secret, IAM conditions add an expiry or pin a version, and version_destroy_ttl delays destruction of a version. Nothing asks for approval on writes. The gap is the log. Admin Activity logs cover create, update and delete, but each AccessSecretVersion is a Data Access log that has to be enabled, so by default a hijacked agent's reads leave no record. There's no Secret Manager MCP server, and the general gcloud MCP server can read secrets if its allow list permits gcloud secrets. security.txt runs to 1 April 2030, and certifications weren't re-read this run. Four, because the grant model is right and the read log is opt-in.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Autonomous by default, and no sandbox behind it”

1000 turns is the default --max-turns, and in the default autonomous mode no tool call in any of them asks first. There's no sandbox (the docs point to a VM or container), and prompt-injection detection and the adversary reviewer for shell calls stay off until someone sets SECURITY_PROMPT_ENABLED and turns adversary mode on. So out of the box the model's shell calls run with the user's full rights and nobody is asked. CVE-2026-72718, published in July, showed the cost, when a repository's git core.fsmonitor ran commands during goose review with no approval, fixed in 1.44.0. Elsewhere it's careful. Usage data waits for consent and never includes conversations, code or tool arguments, model keys sit in the system keyring by default, and manual approval, chat-only mode, per-tool rules and an extension allowlist an administrator can host all exist. Two, because every one of those guards has to be switched on by someone who knew to.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“An approval gate the agent can switch off”

The request body takes an autoApprove flag, and the MCP server reads the same workspace key from the agent's environment. So the gated party holds the key that opens the gate, and a hijacked agent can file its own approval with it. It's one workspace key in an x-api-key header, with no scopes and no read-only key. Reviewer answers come from people you assigned, each result carries the responder and a timestamp, and the terms rule out training on customer data, with processing mainly in the EU. The security programme is thin. No security.txt (a 404), no disclosure policy or bounty, no SOC 2 of its own, audit logs only on the $950 Business plan, and the docs don't say whether webhooks are signed. If they aren't, a forged webhook reads as an approval. Two, because a human-in-the-loop tool should be the one place an agent can't skip the human.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“clear_graph on an unauthenticated port”

Port 8000, and no authentication in the server code. Anything that can reach the streamable HTTP endpoint can call clear_graph, delete_episode or delete_entity_edge, none with annotations, a read-only mode or a confirmation. The README doesn't say whether the Docker Compose file binds the port to localhost only, so I'd assume it doesn't. Credentials come from environment variables, and nothing travels in a URL. Facts and episodes come back from whatever was ingested, with no injection guidance, so a fact planted in one conversation can return as an instruction in the next. No audit log of tool calls. SECURITY.md is in the repo, no bug bounty, and no published advisories found. Telemetry is on by default, documented as excluding content and keys, and GRAPHITI_TELEMETRY_ENABLED=false turns it off. Two, because the destructive tool sits beside search on a port with no lock.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A malicious 0.10.1 on PyPI, and no auth on the server”

Advisory history first. On 11 May 2026 a stolen employee GitHub token ran Actions across 30 repositories, took deploy secrets and published a malicious guardrails-ai 0.10.1 to PyPI. It was quarantined in about two hours, and the advisory is full, telling anyone who installed it to treat the host as compromised. A good write-up of the worst event a library in front of your model can have. The library and server have no auth of their own, provider keys come from the environment, and validators check inputs and outputs but not tool calls, which is still a proposal in issue 1601. enable_metrics defaults to true in ~/.guardrailsrc, and I couldn't find what the metrics contain. No bug bounty found, the disclosure policy is unchecked, and Harvey bought the company on 9 September with nothing said about the code. Two, because the supply chain broke once this year and every boundary is yours to build.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Sound engine, MCP build missing two security fixes”

Advisory history first. The Vault MCP server fixed cross-user credential inheritance through a shared session ID on 28 July 2026 and an SSRF through a VAULT_ADDR query parameter on 11 August, yet the newest binary and Docker image are still 0.2.0 from 24 September 2025, and no advisory was issued. That build has 16 tools, can create and delete mounts, write and delete secrets and issue PKI certificates, has no read-only mode, and returns values to the model. Its own README limits it to local use with trusted clients. Vault itself is the other story. Tokens with TTLs and path policies, explicit deny, dynamic secrets on leases that revoke at expiry, audit devices with HMAC'd values on every edition, and CVEs named in the changelog, including a LIST ACL bypass fixed in 2.0.3. Control groups for approvals and agent ceiling policies are Enterprise only. Three, because I'd trust the API and wouldn't run the published MCP server.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Keys locked to a bank, delete_memory in the default list”

A single bank is the blast radius. Keys can be restricted to named banks, set to expire after an hour to a year or never, and revoking a parent revokes its children. The hosted MCP uses OAuth with PKCE under RFC 9728. Inside the bank there's no read-only key, and delete_memory sits among the 27 default tools with no confirmation. Every retain is screened before storage. The MIT server gets regex redaction of 44 key patterns, while prompt-injection blocking, LLM secret detection and audit trails are Enterprise only, so most buyers get the regex and not the injection screen. No security.txt, SOC 2 or bug bounty found, and the privacy policy is a Termly embed with no address, read on 30 September and not since. Three, because the bank is a real wall and everything inside it is writable and deletable by the same key.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Keys per peer, and a tool list you can't read first”

Honcho's create-key endpoint mints keys scoped to a workspace, a peer or a session, with an optional expires_at, revocable from the dashboard. An agent that needs one user's memory can hold one user's key. There's no read-only flag and no confirmation on deletes. Honcho hands back stored messages and model-written conclusions about a peer, with no injection guidance found. The hosted MCP sends its tool list on connect rather than documenting it, so the destructive surface can't be read before an agent is attached. The x402 endpoints run on the AgentCash platform, a third party on Honcho's subdomain, and what it keeps is unchecked. No audit log, no security.txt, and a SOC 2 Type I badge on the site. Data is kept 90 days after termination, then deleted. Three, for least-privilege keys around an inside nobody audits.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A summary and a yes before any write”

OAuth 2.1 with PKCE is the only way into the remote MCP server, with scopes set by the tools and the user's grant and no API-key path. On REST, Service Keys are scoped and rotate with a 7-day grace period. Of the 32 tools, none deletes, and the manage_* writes show a proposed-changes summary and wait for the user to confirm. Turning on Sensitive Data blocks calls, emails, meetings, notes and tasks from the server. Leave it off and those emails, notes and conversations reach the model with no injection guidance. The trust centre says account activity history can be viewed and exported, though nothing MCP-specific is documented. The disclosure side is the best in this batch, a PGP-signed security.txt valid until 2034, a HackerOne bounty and SOC 1 Type II, SOC 2 Type II and SOC 3. The privacy policy lets HubSpot train its AI on personal data. Four, because writes are gated and what HubSpot keeps isn't.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The account key goes in the WebSocket URL”

One API key and secret pair per account, replaced together with Regenerate keys, no scopes and no read-only key. The docs put the API key or a 30-minute access token in the WebSocket URL as a query parameter, and the Twilio webhook URL carries the API key the same way, so the only credential for the whole account ends up wherever URLs get logged. The access tokens help on the web path. For the phone path I found no alternative. EVI listens to callers, and I found no prompt-injection guidance and no audit log. The privacy page contradicts itself, saying anonymised EVI data improves Hume's models by default and also that API data isn't used to train them. Retention is on until someone ticks 'Do not retain data'. HIPAA BAAs and DPAs on request, and no security.txt, SOC 2 report or bug bounty found. Two, because one leaked URL is the whole account.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Cloning stays off the API, and the key goes in a query string”

Outside Enterprise, cloning happens in the Platform, an upload behind a legal agreement checkbox or a live recording, and the API can't do it. So an agent with a key can design voices and use saved ones but can't clone a clip it was handed. That's a pricing line, and the best boundary on the listing. On Enterprise, where API cloning exists, I found no verification described. The credential is the weak point. One account-wide key and secret pair, regenerated together, and the EVI docs show ?api_key= in a WebSocket URL. 30-minute tokens from POST /oauth2-cc/token exist for clients. The Terms take a perpetual, irrevocable licence to inputs for improvement, Platform submissions may train models unless you opt out, and the privacy statement contradicts itself on EVI API data. No retention period, security.txt, SOC 2 or subprocessor list found. Two, because one key runs the account and the docs put it in a URL.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“An agent that can mint its own API key”

Create-API-Key is in the hosted MCP's tool list. So are Delete-API-Key, Delete-Lead, Bulk-Delete-Leads, Bulk-Delete-Companies and Start-Sequence, among about 100 tools, with no read-only mode, no annotations I could find and no built-in confirmation. A hijacked agent here can give itself a credential that outlives the session, empty the lead lists and start sending email. The REST key can also travel as the api_key query string, where it lands in logs. hunter.io/security is a 404, and there's no security.txt, bounty or certification on record. The privacy side is the best in lead data I've read, with a 451 for anyone who opted out, servers in Belgium and profiles dropped within 3 months of leaving their source page. None of that limits what an agent can do with the account. One, because key creation and bulk deletes in an agent's tool list are the breach I'd plan for.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The credential stays at the proxy”

Agent Vault is the boundary I want. The agent holds a time-bound session token that only works against the proxy, the proxy swaps it for the real credential on the way out, revocation bites within one poll (10 to 300 s, default 60), and every request is logged, encrypted, to an S3 bucket you own. Two cracks. Session tokens reach the proxy unencrypted, so it belongs on a private network, and a machine identity token can outlive revocation by up to 12 minutes if the Redis invalidation fails. The official MCP server can be cut to list-projects, list-secrets and get-secret by allowlist, carries annotations, and masks values only when INFISICAL_MASK_SECRET_VALUES is set. Change and access requests take approvals. No audit logs on Free. security.txt runs to 1 August 2027 with a Bugcrowd programme, but no GitHub advisories are published to judge past handling. Four, for masking that's off by default.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The event key sits in the URL path”

inn.gs/e/<key>. The environment-wide event key travels in the URL path, where proxies and access logs keep it, and anyone holding it can send the event that resumes a waiting approval. The HITL guide matches on an approval ID the developer picks, so the answering endpoint needs its own check on who approved, and the docs leave that to you. Key separation is otherwise sensible, with event keys, signing keys and sk-inn-api keys kept apart. The Cloud MCP's cancel_run, rerun, invoke_function and send_event change state, and I couldn't confirm destructive hints on them. Audit trails and RBAC are Enterprise only, and traces last 24 hours on Free. The security programme is strong, with SOC 2 Type II, a paid bounty, yearly penetration tests and a security@ address with an age key, though no security.txt. Two, because the secret that can answer for a human is the one most likely to end up in a log.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Unscoped tokens and two stored XSS advisories”

Two moderate stored XSS advisories landed on 22 and 23 March 2026, GHSA-98wm-cxpw-847p through invoice line items (CVSS 5.4, fixed in 5.13.4) and GHSA-xph7-9749-56mh through product notes. Both were fixed and published in the open, which I credit. Both also show that text an agent writes onto an invoice reaches other users' browsers, and the client and product text coming back is written by other people, with no injection guidance for API consumers. Tokens are per user, sent in X-API-TOKEN and never a URL, revocable in settings, with no scopes and no read-only option. A plain create stays a draft unless ?mark_sent=true or ?send_email=true is passed. There's an activity log and an activities report export. SECURITY.md gives a disclosure email, with no security.txt, bounty or certification. Self-hosting keeps the data on your own server. Two, because every token can do everything its user can.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Revocation waits for the token to expire”

Cedar policy runs at every exchange, agents prove who they are with a client secret, OIDC web identity or EKS workload identity, and the JWTs are short-lived. The audit log records each issuance and exchange, sessions show every delegation hop, and events export hourly to S3 in OCSF Parquet. That's the best audit trail in agent auth I've read. Now the breach case. Revoking a grant only stops the next issuance, there's no per-token kill switch, and Keycard's access at the provider stays until someone removes it there. Leave the audience unset and the verifier accepts tokens minted for any resource in the zone. security.txt is valid to 12 June 2027 and SOC 2 Type II is claimed, but I found no terms of service (keycard.ai/terms is a 404), no DPA and no hosting regions, and the product is Early Access. Three, because a hijacked agent keeps its token after you've revoked it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Screens tool results, and keeps every prompt by default”

Bearer keys made on the dashboard, shown once, with no scopes, expiry or rotation documented, and nothing to narrow a key beyond the User, Admin and No access roles. The screen is the useful part. It takes OpenAI-format messages with tool calls and tool results in the same request, so the untrusted text a tool hands back gets checked. Only the last interaction is scored, though, so a slow multi-turn attack is your problem. Every prompt and output is logged to the dashboard by default. Admins can switch that off, retention controls are Enterprise-only, and no Community retention period is published. SOC 2 Type II and ISO 27001:2022 are on the trust centre. No security.txt on lakera.ai or checkpoint.com, no disclosure policy, no bug bounty, no advisories, and the contracting Check Point entity sits on a terms page that needs JavaScript. Three, because the vendor holds a copy of everything it screens.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Ten switches on every key, none on the inbox”

Ten resource groups (publishing, engagement, messages, contacts, analytics, ads, telephony, accounts, billing, webhooks) can each be switched off on a restricted zrk_ key minted through POST /v1/api-keys. Whether a restricted key can mint a wider one is unchecked. The hosted MCP does OAuth 2.1 with eight scopes such as posts:read and analytics:read, and the tools carry readOnlyHint and destructiveHint. That's the narrowest credential I read among the social schedulers. The gap is what comes back. Inbox, comment and DM tools return text from strangers with no injection guidance, and I found no advice on approving a publish. X-Request-Id on every response, no audit log. SOC 2 and GDPR paperwork sit behind trust.zernio.com, which is unchecked, there's no security.txt, and the privacy contact is one named person's email. Four, because an operator can cut a narrow key and only has to fence the inbox.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No deletes, no read-only mode either”

48 tools on the hosted MCP, OAuth only, and it refuses static keys, so no lm_ key sits in a client config. The tools are lookups, searches and bulk job submissions with no deletes, which keeps the worst case to spent credits. There's no read-only mode or confirmation step, though a free preview_cost tool lets an agent see a bill before running it. Every response carries X-Credits-Cost and X-Credits-Remaining, and every error a request_id, so an operator can reconstruct a run. REST keys go in X-API-Key with no scopes I found. Results include ad copy, job posts and company descriptions from the open web, with no injection guidance, though the server tells the model to report only what the tools returned. security.txt is valid per the 30 September check, the DPA promises breach notice within 72 hours, and there's no SOC 2 or bounty. Three, because nothing here deletes, and nothing here stops an agent spending.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Three ways to make the token read-only”

Three read-only routes, each enforced on Linear's side rather than in the client. The OAuth read scope gives a token that can't reach write APIs (Linear's words), API keys can be created with Read permission only, and /mcp/readonly exposes read tools alone. Auth is OAuth 2.1 with dynamic client registration or a key in the Authorization header. On the full endpoint, writes run without confirmation. Issue, comment and document text written by any workspace member comes back with no injection guidance. Linear doesn't publish the tool list or schemas, so annotations are unchecked. Workspace audit logs keep 3 months and admins can list active MCP connections, but I found no per-call MCP log. SOC 2 Type II, ISO 27001:2022, security.txt valid, no bug bounty found. The privacy policy says US hosting while the security page lets a workspace choose EU or US. Four, because read-only holds at the token, and the tool surface behind it is unpublished.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Credit caps on admin keys, none on the rest”

Admins can mint keys with a monthly credit cap, and a key a user makes for themselves has no cap of its own. That gap is the first place I'd look after a leak. Keys go in an api_key header, with no endpoint scopes I found. The hosted MCP takes OAuth in Claude, ChatGPT and Codex or an x-api-key header elsewhere, and its 50 tools include table writes and CRM export, with no read-only mode or annotations found. CRM export is a write into your own system of record. Signals carry some free text with no injection guidance. The vendor side is the strongest of the lead-data vendors I've read, with SOC 2 Type II, five ISO certifications claimed, ISO 27701 in the privacy notice, a valid security.txt, a named DPO and a published subprocessor list, though no bounty. Three, because the vendor documents itself well and the agent side writes without asking.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Scoped tokens, and a token-in-path URL in the docs”

Make documents a URL-path form for its MCP token, /mcp/u/<token>, which puts a credential into every proxy and access log between the client and Make. The header form and OAuth at mcp.make.com both exist, so the path form is a choice someone makes and shouldn't. Behind it the boundaries are better than most builders here. About 35 read and write token scopes, OAuth clients with refresh or PKCE on request, and each MCP token can be limited to chosen scenarios. Nothing confirms before a scenario runs, and scenario output carries third-party text with no injection guidance. Audit logs are kept 30 days, longer on Enterprise. SOC 2 Type II, SOC 3, ISO 27001 for the enterprise platform, a bug bounty, no CVEs found in NVD and no security.txt. Whether the paid-plan management tools carry annotations is unchecked. Three, for the scopes, held back by the URL form and unconfirmed runs.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A view-only key exists, and confirm trusts the caller”

No advisories published, a disclosure programme that pays in swag and a security.txt that returns 404, so the clean history tells me little. The credential model is the strong part. X-API-Key travels in a header, never a query string, a service account holds up to five hashed keys with optional expiry, and marmot login tokens last 24 hours and can be revoked one by one since v0.11.0. A custom role gets a view-only key, though the three write tools stay listed for it and refuse at call time. Those writes preview first and apply on a second call with confirm true, and a hijacked agent can send that second call itself. The tools return asset descriptions, glossary text and team members' emails with no injection guidance. The caller is logged only at debug level, which ships off, and the write tools record no actor. Three, because reads can be fenced and writes trust whoever holds the key.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A secret key for the whole store, and a quiet security fix”

No published GitHub advisories, yet release 2.20.1 shipped a field-filtering fix its own notes call a security fix. That's the first thing I read, and it sets the tone. On the shopping side the boundary is real. Publishable keys are scoped to sales channels, so a Store API agent sees only what its channel shows. The admin side is all or nothing. A secret API key, user JWT or session cookie, and a secret key reaches the whole store, with role-based access still behind a feature flag. The official MCP only searches the docs, so it can't touch orders, but the privacy policy describes a Medusa Cloud MCP connector whose results can include customer names, addresses and orders, and its docs page returns 404. No audit log, no security.txt, no bounty, no SOC 2 found. SECURITY.md promises a reply within 3 business days. Two, because an admin agent runs on full access with no record behind it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Free-plan memories train the vendor's models”

The privacy policy of 22 August 2026 says Free Plan interactions train Mem0's models and paid ones don't, so on Hobby the facts an agent stores about a user are training material. Keys are plain and revocable, sent as a Token header, with no scopes and no read-only key. The hosted MCP signs in through the browser with no scopes documented and lists delete_all_memories and delete_entities among its 11 tools, with no annotations documented. Bulk deletes need at least one filter, which stops a blank wipe and not a broad one. Memories come from user text and go back into prompts, with no injection guidance. An events API lists memory operations, and audit logs are Enterprise. SECURITY.md promises a 72-hour acknowledgement, SOC 2 Type I is claimed, no security.txt. Two, because one key deletes in bulk and the free tier trains on what it stores.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A store that hands planted text to every later session”

Three delete tools run without confirmation, and their destructive annotations are the only signal a host gets before part of the graph goes. No credentials and no network, so the JSONL file is the whole attack surface. The danger is time. Anything an agent saves, an instruction lifted from a web page included, comes back verbatim in later sessions, and the README says nothing about it. One poisoned turn becomes standing context for every turn after. No log of who changed what, and resource notifications say only that the graph changed. Without MEMORY_FILE_PATH the file lands inside the package directory. The published release can still lose one of two writes made in the same turn, with the fix merged on 2 and 3 September and unreleased. SECURITY.md declines reports. Two, because a compromised session can write into every future one and nothing records that it did.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One customer per token, no read-only key”

The agent never sees a platform credential. Merge holds the accounting platform's OAuth tokens, and each call pairs a Bearer API key with an X-Account-Token that reaches one linked account, so an injected prompt is confined to one customer's ledger. Scopes can limit common models, and fields from Professional up, but I found no read-only key, and nothing I read says whether scopes can make one. Ledger text from third parties comes back unfiltered, with no injection guidance. Request logs last 3 days on Launch, 30 on Professional and 90 or more on Enterprise, so on the cheapest plan the evidence is gone within 3 days. SOC 2 Type 2, ISO 27001:2022, a pen test report and responsible disclosure on trust.merge.dev, with no security.txt or bug bounty. Subprocessors include OpenAI, and the privacy policy says Merge doesn't train generalised AI or ML models on personal information. Three, for writes with no read-only option.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A read scope on the MCP, and source nobody can read”

A read-only session is one consent screen away. The hosted MCP signs in with OAuth and separate mcp:read and mcp:write scopes, access is revoked from the AI client, and a post can go to review instead of out. REST is coarser, one account token in the X-Mc-Auth header (never the query string) plus userId and blogId, with no scopes, shared by every integration. Regenerating it kills the old one at once. Most of what comes back is the account's own analytics, so little untrusted text reaches the model. The help centre names six hosted tools, four that read and two that write, and calls their source public at metricool/mcp-metricool. That repository returned a 404 on 30 September and a sign-in prompt since, so the definitions and annotations went unaudited. No audit log, security.txt, disclosure route or certification. Three, because the read scope is real and everything behind it is taken on trust.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Per-request logs, and a token-leak fix stuck on main”

A token-leak fix merged into msgraph-sdk-javascript on 16 June 2026, and npm still serves 3.0.7 from September 2023 with no advisory. It needs an attacker-influenced URL passed to the client, and I think an agent following links it read could pass one. The API side is strong. Delegated or application Calendars.ReadBasic (no bodies), Calendars.Read and Calendars.ReadWrite, with admin consent for application permissions, which otherwise reach every mailbox in the tenant until RBAC for Applications fences them to a scope. Graph activity logs record app, user, IP, URI, status and scopes for every request, if you pay for Entra ID P1 or P2 and an Azure destination. Nothing confirms a delete, and event bodies written by outsiders reach the caller with no injection guidance. microsoft.com's security.txt passed its Expires date on 23 September 2026. Three, because the permissions and logs are right and the JavaScript client on npm still carries the leak.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Nothing to steal, and no word on what it logs”

There's no credential at all, so there's nothing to leak, scope or rotate. The endpoint at learn.microsoft.com/api/mcp takes no key or login, and its three tools (microsoft_docs_search, microsoft_docs_fetch, microsoft_code_sample_search) all read. A hijacked agent's worst move is a search. Results come from Microsoft's own documentation and code samples, which the README names as the only source, so the injection surface is one vendor's pages. Whether readOnlyHint is set couldn't be checked, since the live tools/list wasn't reachable. The gap runs the other way. I found no statement of what the endpoint logs or keeps about queries, only Microsoft's general privacy statement, so code pasted into a search goes somewhere unstated. The caller gets no audit trail. MSRC takes reports with a 24-hour response target and a bug bounty, no advisories turned up, and microsoft.com's security.txt expired on 23 September 2026. Four, for the unstated query retention.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A moderation key that also reaches fine-tuning and files”

The moderation endpoint is free, and the key that calls it is the same workspace key that reaches files, fine-tuning, agents, batch jobs and paid models. There are no endpoint scopes. An agent handed a key for screening holds the account. (It's revocable in the console, at least.) Data sent on the free Experiment plan may be used for training, abuse logs are kept 30 days unless zero retention is bought, and nothing I read says whether moderation is exempt, so the text an agent screens on the free plan may train Mistral's models. The jailbreaking category is one score, with no document-aware injection check. security.txt is valid. Certifications, a bug bounty and a disclosure policy sit behind a trust centre that needs JavaScript, and I found no per-call log. Two, because the narrowest credential available is the whole workspace.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Three MCP scopes, and email stops at a draft”

Close makes the operator pick a scope per MCP connection. mcp.read is read-only, mcp.write_safe adds creates but no updates or deletes, and mcp.write_destructive adds updates, deletes, enrichment and scheduling AI voice-agent calls. It's one Close-Scope header, or OAuth with dynamic client registration. Email tools only make drafts a person sends, which shuts the route I'd expect an injected instruction to use to get data out, and delete tools tell the model to act only on an explicit instruction. The event log records changes on every plan. The weak spots are the inputs and the paperwork. The server reads emails, SMS and call transcripts from outsiders with no injection guidance, OAuth for REST apps has only all.full_access, and I found no security.txt, disclosure policy or bounty, only SOC 2 Type 2. Whether the tools carry annotations is unchecked. Four, because the read scope is real and the riskiest write is a draft.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“gVisor by default and secrets in the environment”

gVisor by default, with the full VM runtime only on Team or Enterprise. Outbound traffic can be blocked or held to CIDR ranges (GA), domain lists are beta, and nothing comes in without tunnels. Connect Tokens open one sandbox's server to an outside caller. The credential is a workspace token ID and secret pair, revocable, and I found no scoped token type, so whatever drives sandboxes holds a workspace token. Modal Secrets go into the sandbox's environment, and I found no proxy that keeps credentials outside it, so untrusted code inside can read whatever it's handed. Audit logs are Enterprise only. The disclosure side is strong, a private HackerOne bounty with stated fix times (24 hours critical, one week high) and SOC 2 Type 2. No security.txt. Three, because the network walls are real and the secrets sit inside them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only by flag, confirmation by client”

Confirmation is on by default for eight risky tools (drops, delete-many, user and access-list creation, stream changes) and for $out and $merge pipelines, through elicitation. A client without elicitation runs them unconfirmed, with no warning. --readOnly unregisters every create, update and delete tool, but it's off unless set. Results come back inside per-call UUID tags with a warning not to follow instructions in them, on by default. Server-side JavaScript is off, and HTTP binds to loopback unless --dangerousHostBinding. Atlas service accounts carry per-operation roles, and the temporary database users it creates expire after 4 hours. Secrets can still go on the command line, which the README warns against, and telemetry is on until you turn it off. MongoDB publishes a disclosure policy and Atlas holds ISO 27001 and SOC 2, though the repository has no SECURITY.md. Four, because every guard I look for is here and the confirmation one depends on a client feature you have to check.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One unscoped key and a written consent rule”

One api-key header, no scopes, no consent check, no watermark. The key goes in a header, not a URL, and a token endpoint mints short-lived client tokens, which is the one boundary I can point to. Clones belong to the workspace rather than the key, and the docs say deletion is permanent, so I'd assume any key that can create a clone can also destroy one. The only misuse control is a written rule to clone voices you own or have documented consent for. The docs say reference audio isn't used for training, with no retention period for samples. I found no per-call log, no security.txt, no bug bounty and no SOC 2 or trust centre, and the advisory history is unchecked. The Enterprise gate keeps strangers out, not a hijacked agent already inside. Two, because nothing in the API asks whose voice it's cloning.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Careful grants on an engine with 24 critical advisories”

24 critical advisories for the n8n package between 8 December 2025 and 14 May 2026, most of them sandbox escapes or remote code execution. CVE-2025-68613, code execution through workflow expressions for any authenticated user, has been on CISA's Known Exploited Vulnerabilities catalogue since 11 March 2026. High-severity batches kept landing on 22 July, 10 September and 16 September 2026, one of them credential decryption without an ownership check. I read that history before anything else, and it frames the rest. The MCP side is well built. OAuth with about 17 scopes, per-client revocation, read-only grants, destructiveHint on destructive tools and workflows exposed one at a time, though search_workflows previews every workflow the user can see. REST keys reach the whole account unless the instance is Enterprise. Workflow output is untrusted third-party data with no injection guidance. Valid security.txt and a disclosure policy. Two, because the grants fence the agent and the engine behind them has been the breach.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A 9.2 in the runner, disclosed by someone else”

CVE-2026-9317, CVSS 9.2, published 4 September 2026. Nango's runner before 0.71.6 didn't enforce RUNNER_SECRET_KEY, so anyone who could reach the port could run arbitrary JavaScript. Twelve days later CVE-2026-92804 (high) followed, for unvalidated connection configuration through 0.70.4. Both went out through NVD by VulnCheck, neither is on Nango's own advisory page, and whether Cloud was exposed is unanswered. The design around the agent is better than the record. An agent session is bound to one tenant's tagged connections, the agent never sees a raw credential and can't widen its scope, and credentials sit under AES-256-GCM with AWS KMS envelope keys. Then the gaps. No approval on writes, provider content passed straight to the agent with no injection guidance, logs kept 15 days, and the audit trail only on Enterprise. Three, because the session boundary is sound on paper, and I'd want Nango to say whether Cloud was exposed before trusting the rest.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A cent a call and no credential to steal”

$0.01 or $0.05 a call, signed from the agent's wallet, and no key on the x402 route, so what a hijacked agent can lose is USDC. The docs cap x402 at 60 calls a minute per wallet and don't charge failed or rate-limited calls, which by my sum keeps a runaway under $3 a minute. Every endpoint reads, so there's nothing to delete or send. Token names and symbols are set by whoever created the token, and they arrive beside Nansen's labels with no injection guidance. The keyed API uses one account key with no scopes I could find, and whether it can be rotated or revoked is unchecked. The privacy policy collects query parameters, IP addresses and timestamps, gives no retention period and names no legal entity. I found no security page, disclosure route or certification. Three, because the blast radius is small and bounded, and there's no one to tell when it isn't.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No auth by design, and a heartbeat to NVIDIA every 10 minutes”

SECURITY.md says so outright. Authentication, authorisation, TLS and rate limiting are the deployer's job, so the server answers whoever can reach it until a gateway goes in front. Provider keys come from the environment. Tool-input and tool-output rails can block a tool call, but there's no human approval hook, and the LLM-judged tool_safety_check has existed only on develop since 29 September 2026. Jailbreak and injection rails ship with it. Usage telemetry and a heartbeat every 10 minutes go to NVIDIA by default. The telemetry page lists what's sent (version, configuration, enabled capabilities, deployment type) and what isn't (prompts, completions, messages, keys, endpoints), with three documented ways to switch it off, and I didn't see the code checked against it. Disclosure goes through NVIDIA PSIRT, with no bounty and no published advisories. Three, because the rails are real and every wall around them is yours.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Hard caps on delegations, no brake on pay_service”

Delegations cap lifetime spend in cents, the number of charges and the duration, revoke with one DELETE, and each card carries a default $10.00 ceiling across delegations, with Visa passkey binding. The limits are enforced server-side on every verify and settle call. Inside those caps, pay_service and route_by_intent with autoPay move money with no per-call confirmation, and pay_service returns vendor responses unmarked. The key is one Bearer per environment with no scopes found, and the preferred CLI flow hands it back in a localhost redirect's query string (it never leaves the machine, but it does land in a URL). SOC 2 Type II, ISO/IEC 27001 (2022) and PCI SAQ-D are claimed, with reports under NDA. No security.txt, disclosure policy or bounty. The docs don't say who holds buyer funds for ERC-4337 delegations, and I found no money-transmission licence. Three, because the delegation is a real ceiling and everything under it runs unasked.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“OAuth to the whole workspace, with nothing to narrow it”

The hosted server's OAuth grant reaches everything the signed-in user can see and edit, with no scopes and no read-only mode. Its 36 tools include writes that create, update, move and duplicate pages and databases and start Custom Agent sessions. Access tokens have lasted about 8 hours since 14 July 2026, which shortens the life of a stolen one. Workspace owners can allowlist and revoke connections. Pages and comments any member can write come back with no injection guidance, and whether the hosted tools set readOnlyHint or destructiveHint is unchecked. Enterprise audit logs and SIEM events exist, with no per-call MCP log documented. The open-source server still sits on npm with an integration token in an environment variable, and its README has said since 20 September that it isn't maintained. HackerOne bounty, SOC 2 Type 2, the ISO 27001 family and BSI C5, no security.txt. Two, because the only boundary is the user's own reach.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Warned about hidden instructions, holding the whole key”

The MCP docs warn that email, documents and calendar events can carry hidden instructions to send mail or leak credentials, and sends need a confirmation call. Right instinct, since a calendar-only agent loads all 38 tools, email and Notetaker included. The credential undercuts it. One application API key, the same for REST and the hosted MCP, reaches every grant and can't be scoped or made read-only. Keys can carry an expiry and be rotated and revoked through the admin API, which needs a Service Account with RSA request signing. Tool annotations are unchecked, and I found no operator request log. SOC 2 Type II, ISO 27001 and 27701, CSA STAR, an annual penetration test and a private bug bounty, but no security.txt. A Node SDK fix that stops sending the API key as client_secret in the OAuth token exchange is merged and unpublished. Three, because the warnings are good and every agent gets every grant.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The key rides in every URL, writes included”

?apiKey= on every REST call and inside the MCP connector URL, so one unscoped account key lands in proxy and client logs by design. Only ChatGPT gets an OAuth path instead. The quick start shows scheduletextpost as a GET with the post text in the URL, while the endpoint page says POST, so I can't tell which the server accepts. Write tools reach from sending inbox and WhatsApp messages to deleting comments and scheduled posts. requireApproval and isDraftPost are the only brakes, and they're flags the agent sets itself. Comment and inbox text from strangers comes back with no injection guidance, and MCP annotations are unchecked. No security.txt or disclosure route, and SOC 2 and ISO 27001 appear only as a line against Enterprise on the pricing page. The privacy policy keeps content indefinitely while the account is active and names no subprocessors. One, because the credential leaks by design and the agent holds its own brakes.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Sandboxed and offline by default, --yolo undoes both”

Three sandboxes, one per OS (Seatbelt, bubblewrap with seccomp, the Windows sandbox), and the CLI starts inside one with the network off. It's workspace-write in a git folder and read-only elsewhere, and .git, .agents and .codex stay read-only even inside writable roots. Admins can pin constraints in requirements.toml. Codex cloud keeps the agent phase offline unless domains are allowed, and can hold requests to GET, HEAD and OPTIONS. The security page warns that turning on network or web search invites prompt injection, with a worked exfiltration example. Against that, --yolo drops the sandbox and approvals in one flag, anonymous usage metrics go to OpenAI and feedback collection is on, both by default, and CVE-2025-61260 (critical, code execution through a repository's MCP configuration) reached NVD through Check Point rather than an OpenAI advisory. Cloud task retention is unchecked. Four, because the defaults hold a hijacked model in and the disclosure trail is someone else's.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A restricted key can reach moderation and nothing else”

Restricted project keys set None, Read or Write per endpoint, so an agent's key can be cut down to moderation, which has no destructive action to misuse. Service-account keys exist too. The data-controls table lists /v1/moderations as not used for training, not retained by default and eligible for zero data retention, and the API data policy agrees. security.txt is valid, the bug bounty is public, and SOC 2 Type 2 and ISO 27001 are stated. The only incident in the last 12 months is the Mixpanel breach of 9 November 2025, which exposed platform users' names, email addresses and IDs but no API keys or requests. The caveat is what it can't see. There's no injection, jailbreak or PII detection, so a clean result on a tool result says nothing about a hidden instruction inside it. Four, for a key with almost no blast radius and a guard with one blind spot.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Allow by default, and a server with no password unless you set one”

All three 2026 advisories hit the local server or its web UI. The HTTP server the TUI started had no authentication, so local processes could run shell commands as the user (CVE-2026-22812, 8.8). Unsanitised Markdown in the web UI let a malicious page run commands (CVE-2026-22813). GHSA-632h-h47v-g4x4, published 24 September, let a web page make opencode serve install an attacker's npm package through /global/upgrade, fixed in 1.18.22. opencode serve still runs unauthenticated unless OPENCODE_SERVER_PASSWORD is set. Most tool permissions default to allow, though .env reads are denied and paths outside the project ask, and SECURITY.md says the permission system is not a sandbox. Updates install themselves at startup, and a run with no key sends prompts to free Zen models, some of which may train on them. I found no product telemetry. Two, because a web page has twice found a way to run code through it and the defaults still say yes.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Telemetry before consent, confirmation off on the host”

One event leaves before the consent prompt appears. On first use Agent Canvas sends canvas_install (platform, user agent, referrer, origin) to PostHog through z.openhands.dev, a proxy the source comment says is there to get past ad blockers, and the prompt that follows has its box already ticked. AGENT_CANVAS_DISABLE_TELEMETRY=1 or DO_NOT_TRACK=1 stops all of it, if set before the first start. The npm install runs the agent on the host with full filesystem access and confirmation mode off. A Docker container per conversation sits behind OH_CONVERSATION_RUNTIME=docker, the LLM, Invariant and GraySwan risk analysers are advisory, and I found no egress controls. Listeners bind to 127.0.0.1 with an injected session key. CVE-2026-33718, command injection in the git diff endpoint, was fixed in 1.5.0. Two, because the container is there and the defaults walk past it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Fails closed if asked, tokens can live forever”

A negative expiry on POST /api/token gives a JWT that never expires. That's the first thing I'd audit in any Orkes deployment, because the rest of the model is decent. Application keys carry roles and per-resource read and execute permissions, Human tasks go to named users or groups, and TERMINATE fails the workflow when the last assignment expires instead of leaving the task open to anyone. External reviewers are identified by email from your own system, so the UI that claims and completes tasks is the trust boundary, and Orkes can't vouch for it. History is kept per task, and I found no account audit log. SOC 2 Type II is named for Enterprise. The privacy policy dates from 23 February 2022, gives no retention for task data and mentions no DPA, and security.txt went unchecked. Three, because fail-closed exists and nothing stops a caller asking for an immortal token.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A development default that trusts ?user=”

In development mode the self-hosted MCP server signs a user token for whatever ID arrives in ?user=, and development is the default. The Dockerfile and the published image don't set NODE_ENV, so a server started from that image lets anyone who can reach it impersonate any end user, with that user's connected CRM, calendar and drive behind them. The README documents it and the compose file sets production, which is why this isn't a one. The platform model is sound. Every call carries an RS256 JWT signed per end user, and Event Logs record each action with trace, user and credential IDs. But the project signing key can mint a token for anyone, tools filter by integration or name with no read-only mode, confirmation or annotations, and third-party content comes back unmarked. SOC 2 Type II, HIPAA, twice-yearly pentests, no security.txt or disclosure policy. Two, because the shipped default turns one reachable port into every customer's accounts.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Approval happens outside the chat”

Payments over the owner's ask-me limit need a six-digit code or passkey, and approval happens in the owner's Genie account, never in the conversation, so a hijacked assistant can't approve itself. Per-payment, daily and monthly limits and approved payees sit in front of every request. Genie holds no funds. Auth is OAuth 2.1 with S256 PKCE, two scopes (genie:ask and genie:self), one-hour access tokens and refresh tokens rotated on every use and revoked on logout. The assistant can grant itself read access only. The soft spot is ask_genie, which takes free text, so anything the host agent was fed reaches a second agent with money, bounded by the limits and nothing else. Genie says every decision is logged. SOC 2 is claimed through a trust centre the research run couldn't render, there's no security.txt or disclosure policy, and the privacy policy allows anonymised data to train AI models. Four, because the approval channel is one the model can't reach.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Timeouts reject and disconnects cancel”

5 minutes, then the call is rejected. A timeout never approves, a dropped connection cancels the request. That's the fail-closed behaviour I look for and rarely find. Each tool gets a low, medium or high trust level, admins set a ceiling per user, and approval can be required per tool, per server or by level. OAuth 2.1 per host with consent, immediate admin revocation, and sessions that end 90 days after the last call. Every tool call lands in Permit audit logs, the approval history keeps the deciding admin and the time taken, and Slack alerts leave the arguments out. The caveats. A trusted-agent list skips every rule, the docs put prompt injection out of scope, hosted traffic including arguments and responses passes through Permit's infrastructure, and audit retention is on request. Four, because the gate is real and the bypass list is one entry away from undoing it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Annotated tools, unscoped client credentials”

Since October 2025 every action declares readOnlyHint, destructiveHint and openWorldHint, so a host can gate writes across 10,000+ tools. Tools are fenced per app slug and per external user, Connect tokens are short-lived, and a custom rate-limit token can cap each user. The gaps sit at the top. OAuth client credentials carry no scopes I could find, and the developer MCP picks the end user from an x-pd-external-user-id header, so whoever holds the project's client secret reaches every user's connected accounts. Whether clients can be limited to read-only or to chosen apps is an open question. No server-side confirmation before writes, and actions return content such as email bodies with no injection guidance. No operator audit log found. SOC 2 Type 2 on request, HIPAA BAA, annual pentest, a PGP disclosure address, no bounty, no security.txt and no advisories found. Three, because the hints are honest and the master credential is broad.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only at consent, then any DELETE in the API”

The Code Mode consent page defaults to a read-only scope template. MCP tokens are pinned to the MCP resource and carry only granted scopes, and API tokens are scoped per permission, revocable and sent as a bearer header. Grant full access and execute can call any of about 2,500 endpoints, DELETE included, with no confirmation. Issue #485, asking what stops an agent changing production DNS, has no reply. Model-written code runs in an isolated Dynamic Worker, which contains the code and not the content. Browser Run returns arbitrary web pages as Markdown and the AI Gateway server returns stored prompts, with no injection guidance. Account audit logs and cloudflare-mcp User-Agents make calls attributable. The public tracker is the weaker part. Issue #401, a possibly unsanitised path, has sat unanswered since 19 June, and #442 reports undici 5.29.0 with 12 advisories (3 high) in the published tree. Three, because the safe default is one consent choice away from the whole API.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Fourteen days of logs, one secret for everything”

Fourteen days of Dashboard logs, holding every request, response, webhook and Link event, is the best audit trail in this batch, and security.txt is valid to 31 December 2026 with a HackerOne programme. The credential is the problem. One team client_id and secret, sent in the JSON body or headers and never in a URL, reaches every product, Transfer included, with no scopes and no read-only variant. The 48-hour idempotency_key on Transfer authorisations prevents a duplicate and does nothing about an unwanted one. Rotation leaves the old secret live until someone deletes it, so cleaning up a leak takes two steps. Merchant text arrives unmarked. UK and EEA data is transferred to the US and stored in AWS regions, retention has no stated periods, and no SOC 2 or ISO 27001 was stated on the pages read. Three, because the logs would show the damage and nothing in the credential would stop it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Dead host, live docs, keys still in config”

Nothing answers. On 1 October 2026 api.play.ht didn't resolve, and third-party migration guides put the platform's closure at 31 December 2025. I found no shutdown notice from PlayHT itself. docs.play.ht still documents POST /api/v2/cloned-voices/instant with no warning, so a model reading it will write calls that send X-USER-ID and the secret key in the Authorization header to a host nobody answers for. When it ran there were no scopes and no consent check beyond a general warranty in the terms. Clones and audio were reportedly deleted at shutdown with no export, but that comes from third parties, so where the samples went is unchecked, and the privacy policy survives only as an Internet Archive copy. One, because the only security work left is removing the stored keys and keeping agents away from the reference.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“An RCE-equivalent tool you can't switch off”

browser_run_code_unsafe is one of the 25 tools that load by default, and its own description calls it RCE-equivalent in the server process. It sits in the core set and no flag removes it, so a page that steers the model can ask for arbitrary JavaScript on the host. The HTTP transport binds localhost and checks the Host header against DNS rebinding, but has no authentication. --isolated is off by default, so cookies persist between runs, and the docs for the allowed and blocked origin lists say they aren't a security boundary. File access stays inside workspace roots unless --allow-unrestricted-file-access widens it, --secrets masks values in responses, and traces, video and --save-session leave a record. Microsoft's MSRC policy covers reports, no advisories are published for the repository, and playwright.dev has no security.txt. I found no prompt-injection guidance. Two, because the worst tool in the set is mandatory.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“OAuth with read scopes, and a ?key= fallback”

PKCE with S256, dynamic registration and six scopes, four of them read-only, so an agent can hold a token that never writes. The same MCP also takes the pb_live_ key as a Bearer header or as a documented ?key= URL parameter, so the key can end up in a URL. Writes are narrow. delete_post only touches scheduled or draft posts, is_draft holds a post, and there's no inbox or comment text to carry an injection. Omitting scheduled_at publishes at once. list_post_results shows outcomes per platform, and there's no audit log. MCP annotations are unchecked. I found no security.txt, disclosure route or certification, only support@post-bridge.com, and the terms name no company, only Post Bridge under Canadian law. The privacy policy names six subprocessors and deletes personal data within 30 days of account deletion. Three, because the token can be narrow and nobody named stands behind it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Unrestricted by default, and the safe mode reads files”

6 June 2026 is the date to read first. Issue #178 showed restricted mode reading /etc/passwd through pg_read_file in the FROM clause, because the function allowlist checks only calls outside it. Nearly four months on there's no maintainer reply and the fix (#200) is unmerged. It needs a role with pg_read_server_files or superuser, so a low-privilege role still shuts it. Restricted mode is otherwise careful, with pglast parsing, a read-only transaction and a 30-second stop. But unrestricted is the default and every README example uses it. The SSE and HTTP transports have no authentication. Rows reach the model unmarked, and the experimental llm index method sends schema and query plans to OpenAI. No SECURITY.md, and the reporter says private advisories aren't enabled. Two, because the guard is opt-in, has a public hole and nobody is answering for it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One COMMIT ends the read-only transaction”

118,589 npm downloads in the week to 30 September 2026, for a server whose only guard has been broken in public since 21 August 2025. It wraps the agent's SQL in BEGIN TRANSACTION READ ONLY and sends it as a simple multi-statement query, so a query that starts with COMMIT; runs outside the transaction, as Datadog Security Labs showed. The tool description still says "Run a read-only SQL query". The repository was archived on 29 May 2025 with no security guarantees, nobody can file an issue, and the npm deprecation message names neither the flaw nor a successor. The connection string, password included, is a command-line argument visible in process lists. Rows reach the model unmarked. No annotations, no log, no advisory. One, because the description tells an agent it can't write and the code lets it.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Two CVEs fixed through a working route, no read-only grant”

CVE-2026-94455 and CVE-2026-94456 were fixed on 22 September 2026, and a path traversal in the self-hosted upload route, labelled critical, on 20 July. Three security fixes since July, and they came through a working route. SECURITY.md sends reports to GAdvisory with 72-hour acknowledgement and 90-day remediation targets, and CI runs CodeQL. The boundaries are weaker. One organisation API key, sent raw in the Authorization header and rotatable, with no scope. The MCP's OAuth (PKCE, dynamic registration) always grants mcp:read and mcp:write together, and the docs also document the key in the URL path at /mcp/{key}. Tools carry readOnlyHint and destructiveHint in source, posts can go in as drafts, and the MCP has no comment or inbox tools, so little untrusted text comes back. Only the latest release gets security fixes. Three, because the disclosure process works and there's no way to hand an agent less than everything.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Default deny inside an enclave, with a lag on rolling caps”

Keys are Shamir-split and rebuilt only inside AWS Nitro Enclaves, which sign only what passes the wallet's policy. Policies deny by default, DENY beats ALLOW, and rules reach recipients, values, contracts, decoded calldata, typed data and time windows. Key quorums add m-of-n approval, the confirmation I look for. The weak point is the app secret on Basic auth, which can do anything in the app, so the boundary holds only when agents get an authorisation key or a delegated signer. Agent CLI sessions last up to 30 days on rotating short-lived keys. Rolling caps are EVM only and update after signing, so parallel requests can exceed them (per the 30 September check). Wallet and token data come back with no injection guidance. SOC 2 Type I and II, audits by Cure53, Zellic and Doyensec, a HackerOne bounty, no security.txt. Four, because the enclave refuses what the policy doesn't list, while the app secret stays away from the agent.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Eight read-only tools and a perpetual licence”

Eight tools, every one annotated readOnlyHint true and destructiveHint false, so a hijacked agent can search, enrich and burn credits, at 10 a mobile against 1 an email, until the plan's daily cap (2,000 enrichments on Starter) stops it. Keys go in the X-KEY header, several per account, and the hosted MCP takes OAuth instead; nothing I read puts a key in a URL. Output is structured profile and company fields with little free text to carry an injection. The vendor side is where it falls down. No security.txt, disclosure policy, bug bounty or certification, no per-call log, and per the 30 September check the privacy policy takes a perpetual, irrevocable licence to contact data customers upload and feeds it into the shared database. That page rendered empty this run, so I can't say whether an enrichment request counts as an upload. Three, because the tool surface is clean and the retention terms aren't.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Scoped keys, but posts means read and write”

Five scopes on a key, workspaces and accounts always on, posts, media and analytics optional, and a revoked key gets a 401. The docs advise rotating every 90 to 180 days. An agent limited to analytics can't touch a post. One that needs to read posts gets the posts scope, which also writes, so there's no read-only posting agent. The MCP uses the same key, and the help article documents it inside the generated server URL as one option, with no approval guidance and no tool list, so the tools and their annotations are unchecked. Competitor analysis and post insights bring back other accounts' public content with no injection guidance, and there's no inbox or comment tool. No audit log, security.txt or disclosure route. The privacy policy claims ISO/IEC 27001, names servers in Frankfurt and links a DPA and sub-processor list. Three, because the scopes are real and the MCP they guard is undocumented.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One tool argument turns the sandbox off”

Archived on 29 May 2025 under a README that says NO SECURITY GUARANTEES, deprecated on npm, and still drawing 25,072 downloads in the week of 14 to 20 August 2026. The guard against dangerous Chrome flags lifts when the model passes allowDangerous: true to puppeteer_navigate, so a page that steers the model can ask for --no-sandbox. Docker mode never had the sandbox, launching with --no-sandbox --single-process --no-zygote. puppeteer_evaluate runs any script, and the README's only caution is that the browser can reach local files and internal addresses. Page content and console output come back unmarked. There's no call log, no advisory process because the archive is read-only, and the pinned Puppeteer ^23.4.0 is itself marked unsupported on npm. Setting ALLOW_DANGEROUS to false doesn't help much when the argument is the model's to send. Move to playwright-mcp or chrome-devtools-mcp. One, because the exfiltration path is open and nobody will close it.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Enforced only where the hooks run”

Plain MCP clients get cooperative questions only. Enforcement exists where host hooks run, Claude Code's PreToolUse and Hermes, and everywhere else a hijacked agent simply doesn't ask. With hooks in place the record is good. The audit trail keeps each question, the tool, who decided, when and under which policy, for 30 to 365 days by plan, decision links are HMAC-signed, and the skill says a text answer containing yes isn't approval for a separate action and silence is never consent. One Bearer key per account is written to ~/.pushary/config.json after a QR and fingerprint pairing. Questions can carry file changes and error text, which then sit on Pushary's servers and a phone. SECURITY.md covers the skill repository only, and I found no disclosure process, bounty or certification for the hosted service. Three, because the gate is only as real as the host it runs on.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One scope covers the ledger, and the security page won't load”

I couldn't read Intuit's security side at all. security.intuit.com returns a loading message, www.intuit.com/.well-known/security.txt answers 400, and the developer terms sit in a JavaScript portal, so the disclosure policy, bounty, certifications and data retention are all unchecked. What I could read is the credential. OAuth 2.0 with OpenID Connect, a realmId per company, one-hour access tokens and refresh tokens of about 101 days that rotate, the old one living 24 hours. The accounting scope is one grant over the whole ledger, with no read-only option in the API. The official MCP server can drop create, update or delete tools by flag, sets no annotations, and keeps tokens in .env, rewriting the refresh token there on each refresh. Customer and vendor text arrives with no injection guidance, and whether QuickBooks' audit log records changes per app is unchecked. Two, because the only brake is a flag on a local server.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Watermarking on the account, no consent check in the API”

Ten seconds of audio makes a rapid clone, and one Bearer key with no scopes found makes the request. That key reaches voice creation, recordings, builds and deletes. The terms say Resemble may require verbal consent from the person cloned, but the create-voice API has no consent field and no check, only an optional consent value the Node SDK still sends. Watermarking and deepfake detection run on the same account, which helps after the damage, not before. The privacy policy of 14 August 2026 rules out training general-purpose models on customer voice data and keeps recordings and voice models while the account is active plus 30 days. Usage is readable through the Billing API, with no per-call log found. The trust centre lists ISO 27001:2022, with SOC 2 Type 2 still in observation on 2 October. No security.txt or bug bounty. Two, because a hijacked key clones anyone and the paper trail is a billing line.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only keys exist, and the MCP tools aren't labelled”

Read or edit scopes for Build, Monitor and Deploy, on keys that can be created, rotated and deleted, so an agent that only reviews calls can hold a key that changes nothing. Public keys for web calls take domain allowlists and reCAPTCHA, and webhooks carry an X-Retell-Signature from a separate signing key. The MCP docs warn that transcripts and documents can carry prompt injection, the only voice-agent docs in my batch that say so. Then the hosted MCP server's over 40 tools carry no read-only or destructive annotations, so the client's confirmation setting is the only brake on deletes and calls. Call data is kept indefinitely unless a retention period from 1 to 730 days is set per agent. No audit log of account actions, no security.txt, no bug bounty. SOC 2 Type 1 and Type 2 and HIPAA per the compliance page. Three, because a read key is safe and an edit key reaches everything unannotated.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Gateway tokens bound to one devbox”

Agent gateways are the part I'd trust. Real API keys stay on Runloop's servers and the devbox holds a gateway token that only works from that devbox, so a compromised box leaks something useless anywhere else. The rest is thinner. One Bearer API key, no scopes or rotation guidance found, and no audit log, so whatever a hijacked agent does with the account key goes unrecorded. Devboxes are microVMs, per Runloop's security page. Network policies can block egress or allow listed hostnames, with no beta label, but egress is open by default. SOC 2 Type II, report on request. I found no security.txt, no disclosure policy and no bug bounty, so there's no stated place to report a flaw, and the research confidence is low. Three, because the credential design is right and nothing records what the master key did.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The connection token rides in the query string”

The docs only ever pass the per-connection access_token as a query parameter, so it lands in URLs and logs. It's useless without the client secret, which softens that, but the secret is one client_id and client_secret pair over HTTP Basic for the whole organisation, reaching every connection. I found no scopes and no read-only credential. Each call reaches only the connection its token names, which limits what an injected prompt in ledger or commerce text can touch, and there's no injection guidance. Idempotency-Key on writes stops a retried create posting twice. The Vanta trust centre mentions encryption and access logging, but no certifications, disclosure policy or bug bounty were visible, and there's no security.txt. The terms and privacy policy are Google Drive PDFs that couldn't be read, and the site names no legal entity beyond "Rutter", so retention and subprocessors are unknown. Two, for a token in the URL behind an organisation-wide secret.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only by design, with nine advisories behind it”

The MCP server never runs mutations, and 7 of its 8 tools carry readOnlyHint. App tokens are limited to named permissions such as MANAGE_ORDERS, revocable through the API, and travel in headers, never the URL. A self-run copy can pin allowed API domains with ALLOWED_DOMAIN_PATTERN. The advisory history is busier than I'd like. Nine advisories between January and July 2026, two of them high and touching customer data (a GraphQL IDOR published 23 January, account pre-hijacking through an anonymous order merge published 27 July), plus stored XSS through uploads. All fixed and published through GitHub. The hosted instance at mcp.saleor.app receives a token holding MANAGE_PRODUCTS and MANAGE_ORDERS, permissions that can write elsewhere in the API. Shopper text returns unmarked, and no operator audit log was found. SOC 2 Type 2 and PCI DSS are vendor claims. Four, because the server can't write, though the token handed to it can.

desk review: security · success · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Reads, mutations and deletes are separate servers”

Two scopes, mcp_api and refresh_token, on a per-user OAuth flow with PKCE through an External Client App, and no API-key path. Every server is off until an admin turns it on, one at a time, and there are separate Reads, Mutations and Deletes servers, so an agent that only reads can be given only reads. SObject All, the broad one, includes delete, and its delete tools ask for confirmation. Every call runs inside the user's field-level security and sharing rules. The leaks are on the input side. Record text written by outsiders reaches the model with no injection guidance, the main read tool takes free-form SOQL, and the hosted MCP docs don't say whether MCP calls are logged, though the platform has setup audit trails and event monitoring. No security.txt, a responsible disclosure page in the compliance portal, and certifications unchecked because the portal renders client-side. Four, because the server split is right and the logging is undocumented.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Permission sets and org deletes, no read-only mode”

Credentials stay in the Salesforce CLI's encrypted OAuth or JWT auth files, tools pass usernames instead of tokens, and --orgs allow-lists which authorised orgs the server can touch. Then the edges. ALLOW_ALL_ORGS exists, DEFAULT_TARGET_ORG re-resolves on every call, so it follows whatever the working directory's default is at call time, and there's no read-only mode. Write tools deploy metadata, assign permission sets, create and delete orgs and promote DevOps Center work items. delete_org (NON-GA, off by default) asks for confirmation only through its description and has an empty annotations object, and the ten DevOps Center tools have none. SOQL results carry user-entered record text with no injection guidance. Org audit trails exist but the MCP docs don't mention them, and local logs need --debug. SECURITY.md points to sfdc.co/SubmitVuln, with no advisories and no security.txt, and telemetry is on by default. Two, because a hijacked agent can change who holds which permissions.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Signed requests and five years of logs”

One hour is the longest a Live signature stays valid. Every Live call adds an Expires-at header and a private-key signature over Expires-at, method, URL and body on top of the App-id and Secret headers, so a leaked secret alone can't drive production, and the docs give breach steps for the key. Consents carry scopes (holder_info, accounts, transactions) and period_days, PUT /consents/{id}/revoke ends one, and Test and Pending apps can't reach real banks. The app credential has no scopes. Retention is written down, which I credit, and it's long. Backups up to one month after deletion, logs at least five years, and Yandex for analytics among the named processors, in a policy last updated 14 September 2023. There's no security.txt, /security returns 404, and I found no disclosure policy, bug bounty, certification or operator request log. Three, because the request boundary is strong and nobody publishes how to report a hole in it.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The backend secret reads every user's tokens”

The API reference lists GET /api/v1/connected_accounts/auth, which hands a user's full OAuth tokens to any holder of the API credential. That's the line I'd read first, because whoever steals the backend's client ID and secret gets every connected user's Gmail and Slack, not a tool call. The agent-facing design is careful. Virtual MCP servers mint per-user session tokens from 60 seconds to 24 hours, one hour by default, scoped to that user's connected accounts, so the agent can be kept away from the raw credential. After that, very little. No approval on destructive tools, third-party content from execute_tool with no injection guidance, no audit log in the AgentKit docs (SIEM only on Enterprise), a 404 for security.txt, no certification or disclosure programme confirmed, and no word on how stored tokens are encrypted or whether deletion revokes at the provider. Two, because one leaked secret reaches every user, and I can't see who would notice.

desk review: security · failure · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read scopes per resource, and catalogues from strangers”

Shopify's security.txt points to a HackerOne programme with a PGP key, though the file has no Expires field. Access tokens are per app and limited by granular read and write scopes, so an agent that only reports can hold read scopes and nothing else. UCP checkout calls must be authenticated or signed, and the Dev MCP server reads docs and schemas only. The exposure sits on the shopping side. UCP hands merchant catalogue content to third-party agents, and the spec covers header and log injection but not prompt injection, so a product description written for a model reaches one unmarked. The dossier marks the UCP pages as unread (refused by the research fetch limit), and whether the UCP tools carry read or destructive annotations is unchecked. No general API audit log was checked either. Four, because writes sit behind scopes and signed checkout, and the open door is text from other people's stores.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The seller is capped, the buyer agent isn't”

Each pay token caps what a seller can charge at its amount, expires in 10 seconds to 24 hours and is bound to one seller service. That protects the buyer from the seller, and I found nothing that protects the wallet from the agent. There's no buyer-side spending cap on an agent key and no confirmation on create-pay-token, so a hijacked buyer agent can mint tokens until the wallet is empty, and credits are non-refundable. Key types are split well (a buyer key can't charge, a seller key can't mint), sent in a skyfire-api-key header, but rotation and revocation aren't documented. No audit log or per-call history. No security.txt, disclosure policy, bug bounty or SOC 2. The terms name no bank, custodian or licence for wallet funds, and the privacy policy permits training AI models on personal data. Two, because the only limit on spend sits on the wrong side of the transaction.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Per-tool scopes and an admin at the door”

User tokens only, through a confidential OAuth client with per-tool scopes, and no secrets in URLs. Every MCP client goes through workspace app approval, and scopes can be limited to read tools. That's the read-only mode here, since there's no read-only endpoint. Searching private channels and DMs asks the user for consent first, and public search doesn't. Write tools send and schedule messages, create channels, upload files and update canvases and lists, with no confirmation documented, and annotations are unchecked. Messages come back as anyone in the workspace wrote them, and the docs say only to use judgement, which is thin for a tool whose write side can post what it reads. MCP calls get their own audit-log entries under a fixed app ID, and IP allowlists apply. security.txt valid, SOC 2 Type II, ISO 27001, ISO 42001 and FedRAMP Moderate, no bug bounty mentioned. Four, because read scopes and admin approval hold the agent, once someone sets them.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One live key, 38 tools, refunds with no brake”

A live secret key reaches the whole account, and it's the only kind of key there is. No scopes, no read-only key, no OAuth (the MCP docs say OAuth 2.1 isn't supported). The hosted server loads 38 tools on that key, among them refunds, stock changes, product archives and customer updates, with no documented confirmation and no annotations for a host to gate on. The only log is order notes, with no audit trail. I found no security.txt and no disclosure contact in the terms, and whether Duda's security programme covers Snipcart is unchecked. The key travels in an X-Snipcart-Api-Key header or as Basic auth, and the dossier records no URL form. Test keys see only test data, and the per-key limit of 100 requests a minute slows a runaway agent without stopping one. One, because a hijacked session holding a live key can issue refunds and archive products, and nothing records who asked.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Clean data terms, and nobody checks consent”

Project-scoped keys, plus temporary keys for client use, so a key shipped to a browser needn't be the master. Voices belong to the project that made them. The data terms are the cleanest of the voice-cloning listings I read. Audio is never used for training, logs exclude audio and transcripts, and a clip stays only until you delete the voice. SOC 2 Type 2 and ISO 27001:2022 are stated, with reports in the Console. Then the hole. The terms say Soniox doesn't verify the right to clone a voice, and there's no consent step and no watermark. Every error carries a request_id, but I found no per-call log, no security.txt and no bug bounty. Three, because what Soniox keeps is well bounded and what it lets an agent clone isn't bounded at all.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A consent check the API enforces”

Since 23 September 2026 every clone needs a single-use phrase read by the speaker, and the create call is refused unless the words and the speaker match the sample. The old name-and-email consent field gets a 400 on every API version. Service-account keys carry scopes (voices:read, voices:write, audio:all), rotate with a grace window and can mint child keys capped at 24 hours, so an agent can hold read access or a day of write. Output is watermarked, and POST /v1/audio/watermark/detect checks a clip. Personal keys are full-access, and the no-training statement and security.txt rest on last week's check. I found no retention period, SOC 2 or bug bounty, and the API terms forbid the end-user uploads the consent guide describes. Four, because the sensitive write needs a live human voice, and the paperwork around it is the caveat.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“No email bodies, and no tool list either”

Email content never reaches the model through Streak's MCP server, which removes the biggest source of outside text in a Gmail CRM. The server is OAuth only, follows the user's Streak permissions and can be revoked in account settings. Streak doesn't publish the tool list, count or annotations, the docs say it can create and update boxes, contacts, comments and tasks, and neither route has scopes or a read-only mode. Comments and box fields can still carry outside text, with no injection guidance. REST takes a key over HTTP Basic with all of the user's privileges, rotated only by delete and recreate. Activity shows in the pipeline newsfeed, filterable by teammate and event type. HackerOne runs the bounty and Google reviews the OAuth app yearly, but no SOC 2 is named, there's no security.txt, and the privacy policy dates from 27 September 2024 with no retention periods. Two, because nothing narrows either credential and the write tools aren't listed.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A human gate on refunds, and full-access keys until 31 October”

Refunds and outbound payments through stripe_api_write wait for a person to approve them through a URL, and approvals expire after 24 hours. From 31 October 2026 the MCP server rejects full-access secret keys, leaving OAuth with per-account and per-environment permissions or Agent-tagged restricted keys. Until that date a full-access key still works, and that's the gap I'd close first. The MCP page tells users to turn on human confirmation of tools and warns about prompt injection when Stripe is combined with other servers, though customer-entered fields still come back through stripe_api_read. Workbench logs MCP tool calls, and there's an exportable security history. HackerOne bounty, PCI Service Provider Level 1, SOC 1 and SOC 2 Type II, a public SOC 3 and a valid security.txt. Tool annotations are unchecked. Funds sit in the Stripe balance until payout. Four, not five, because stripe_api_write is generic and the approval list decides what counts as sensitive.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Clean revocation, no record of it”

60 minutes is the default life of an access token, and POST /v1/users/{user_id}/connected_apps/{connected_app_id}/revoke kills every active token for that user and app in one call, with no new one until the user consents again. PKCE with S256 is required for public clients. Consent can only grant scopes the user's RBAC roles allow. The service hands back tokens, not untrusted content, so there's little injection surface. Those are the boundaries I want. What I can't find is a record. No audit log of grants, consents or revocations, no security.txt on stytch.com, and no confirmed certification, disclosure programme or subprocessor list since the legal pages moved to Twilio. DCR takes no credentials once switched on, so consent is the only gate on who registers a client. The Node SDK last shipped on 24 June 2026. Three, because revocation works on paper and nothing tells you what to revoke.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only is a URL parameter, and the default writes”

Read-write with seven feature groups is what a bare URL gets. Add read_only=true and SQL runs as a read-only Postgres user with write tools hidden, project_ref and features cut the surface further, and the agent plugin has no read-only option at all (#361). Personal access tokens can be scoped to chosen projects and permissions with an expiry, and the hosted server uses OAuth 2.1. Destructive SQL asks through elicitation since v0.13.0, and execute_sql results sit inside an untrusted-data boundary. Supabase says these reduce the risk rather than remove it, and the July 2025 support-ticket exfiltration is the reason they exist. #318, open since 2 July 2026, reports that the confirm_cost token can be precomputed. SOC 2 Type 2, ISO 27001 and a valid security.txt, with platform audit logs unchecked. Three, because the walls are good and the operator has to remember to build every one.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Read-only spaces, and an intake for any web page”

Scoped keys are limited to one or more container tags, can expire after 1 to 365 days and stop on revocation, and they can't read billing, change settings or mint keys. Org keys still have full access. The MCP signs in with OAuth and asks which spaces to allow, each with read or write permission, so an MCP connection can be read-only, and the mass forget has a dry run. Then the intake. Supermemory ingests URLs, PDFs and web pages and returns what it extracted to the model, and I found no prompt-injection guidance. Customer content never trains models on any plan, per the security page. SOC 2 Type II and GDPR are claimed, with a HIPAA BAA from Scale. The terms name no legal entity, a single forget is a soft delete, and there's no security.txt. Three, because the keys are narrow and the content coming through them is unscreened.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“One key for every collection, and a day-old audit log”

Every collection in a Swell store sits behind one secret key per environment, sent as HTTP Basic with the store ID. Keys are revocable, and I found no scoped or read-only variant. Role-based permissions appear only on the Unlimited plan. The events audit log in the developer console shipped on 30 September 2026, which makes the first thing I'd ask for also the newest. There's no official MCP server, and the swell-mcp package in the registry comes from Devkind, a partner, so an agent using it hands a full-access key to code Swell didn't write. Merchant and shopper text returns unmarked. The security.txt path redirects to itself, and I found no disclosure policy, bounty, SOC 2 or PCI claim on the pages the dossier covers. Two, because a leaked sk_live_ key is the whole store and the record of what it did starts a day ago.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Deletes ask twice, publishing doesn't ask at all”

Through the MCP server, deletes need a second call with confirmed=true, while publish and rollback run at once. A hijacked agent has to ask twice to delete an agent and once to publish or roll one back. Bearer API keys are made per workspace, with 2FA and SSO on the account and no read-only key. The MCP docs don't say how the server signs in. Webhooks are signed. PII redaction covers transcripts, webhooks and logs but not live audio, recordings and transcripts can be switched off or deleted after 30 days, and default retention looks indefinite. I found no prompt-injection guidance and no audit log of account actions. Certifications sit in a Trust Vault the research run didn't read, beside a public BAA template, and there's no security.txt or bug bounty. Two, because the write that reaches customers has no brake and the paperwork sits behind a contract.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Mutual TLS, and Zelle with no approval step”

Two credentials per call outside sandbox. Each enrolment's access token goes in basic auth, and development and production also need the dashboard's client certificate over mutual TLS, so a stolen token alone doesn't reach a real bank. The price is a private key on each host. A token covers one enrolment and the products picked in Connect, a narrow radius. Then payments. The beta Zelle payments can move money, and I found no approval step or read-only key, only an Idempotency-Key kept for 72 hours. Merchant text comes back unmarked. The paperwork stopped years ago. The developer privacy policy dates from 12 October 2020 with no retention periods, names Google Analytics and lists other processors by category only, and the SOC 2 Type 2 claim rests on an announcement from July 2021. No security.txt, bug bounty or request log turned up. Two, because money can move without a confirmation and the newest security document I can read is from 2021.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“Hashed, scoped keys on a chain still under audit”

Mainnet has carried MPP settlement since 18 March 2026, and the node README still says the chain is undergoing audit with no active bug bounty. A security release, v1.13.1 on 20 August 2026, was announced in the public changelog. No security.txt, and no terms of service found for the API, console, CLI or MCP server. The API key design is careful. Project-scoped keys with named scopes such as data:read, rotation, revocation, optional IP allowlists, environment prefixes, sandbox keys that can't touch mainnet, and only a hash stored at rest. MPP payment credentials stay separate from keys. Payments are signed by the agent's own wallet with no approval step on Tempo's side, so spending control lives in that wallet and in the console's monthly spend and fee-sponsorship limits. Token names and memos are attacker-controlled, with no injection guidance. Three, because the keys are tight and the chain they sit on hasn't finished its audit.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“A read-only role, and the sender is the gate”

30, 20 and 10 days. Those are the expiry warnings Temporal emails for namespace-scoped API keys, which belong to users or service accounts, carry RBAC and come with rotation guidance, or mTLS certificates per namespace replace keys altogether. There's a read-only account role. Client-side encryption through a Data Converter keeps payloads unreadable to Temporal, which answers what the vendor keeps. Each workflow's event history records every signal, and control-plane audit logs export to Kinesis or Pub/Sub, though data-plane events such as starts and terminations are left out. The weak point is the approval itself. A signal carries whatever the sender writes, so whoever can signal the workflow can approve, and the sender needs its own authentication. SOC 2 Type 2, HIPAA and a yearly full-scope penetration test, but no SECURITY.md in the server repository, and security.txt and a bounty went unconfirmed. Four, because every boundary is documented and the one that matters most is yours to build.

desk review: security · partial · Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.

“The operations flag doesn't cover team access”

A token sent as a query parameter gets a 400, which is the first thing I check and the right answer. HCP Terraform tools take a user, team or organisation token from TFE_TOKEN or a bearer token in the Authorization header, revocable, with no OAuth. The default toolset is the nine registry tools, keyless and read-only. ENABLE_TF_OPERATIONS (default false) holds back deletes, force-unlock, action_run and apply-capable runs. It doesn't hold back create_workspace, update_workspace, variable writes and deletes, add_team_member or grant_team_access, so a hijacked agent with the terraform toolset can widen who has access without the flag. Nine variable tools carry no annotations. Provider docs, module READMEs and run logs reach the model unmarked, and the README says not to use the server with untrusted clients or models. v1.1.0 (14 July 2026) fixed cross-tenant token reuse in HTTP mode and a TFE_ADDRESS override that could send the bearer token elsewhere, with no advisory. Three, because the gate stops deletes and not access grants.