Openfort

# Fix list: Openfort

From Anchor Terminal's listing at https://www.anchorterminal.com/tools/openfort, the October 2026 research run, assessed 9 October 2026. Grade BB, 70.1 out of 100.

This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.

For a coding agent working on Openfort: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.

## 1. Security & auth, 65 out of 100, up to 6.1 more on the total

Why it scored 65: Secret keys carry 26 named scopes and can be rolled, test and live are isolated, and backend signing needs a second credential, a wallet secret that signs an ES256 JWT with a nonce and request hash and can be rotated. A key made without a scope list includes `accounts:sign` and `accounts:export` (26 of 30). The policy engine rejects what no rule matches and policies can be scoped to one wallet, and session keys are limited on-chain. For an EVM backend send the engine sees only a hash, so address, value and calldata rules bind only if the caller pre-flights, and no approval step or rolling cap was found (11 of 20). The product page says an injected prompt can attempt a transaction but cannot take a key, and the docs advise one policy-bounded wallet per agent and a tool allowlist. The CLI MCP server lists key export tools that return the private key (7 of 15). API logs in the dashboard, webhooks, a request id on every response and emails on 500s (11 of 15). Five named audits and a security contact. No security.txt, no bug bounty found and no SOC 2, which the vendor states (10 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-security):

- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.
- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.
- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.
- 0 to 15, audit logs or per-call visibility for the operator.
- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.

Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.

## 2. Agent ergonomics, 65 out of 100, up to 5.7 more on the total

Why it scored 65: Graded on the REST API, which is what an agent's backend calls. List endpoints take `limit`, `skip`, `order` and `expand`. The CLI MCP server puts 72 commands in context with no built-in subsets (15 of 25). Paging and filters from the OpenAPI file. We did not read the pagination page (16 of 20). A stable `error.type`, a status table with what to do for each code, field-level details on 422 and a request id. Only two error types (16 of 20). No documented idempotency key on wallet writes, the guidance after a 5xx is to re-read, and a send without a fee sponsorship stays pending with no error. The wallet JWT carries a nonce (8 of 20). The SDK hides the wallet JWT, but a bounded EVM send needs two policies, a sponsorship and a pre-flight call. The only server SDK is Node (10 of 15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):

- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).
- 20, pagination, filtering and output-size controls.
- 20, actionable, documented error responses, codes and messages an agent can recover from.
- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.
- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.

Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.

## 3. Payments & pricing, 60 out of 100, up to 5 more on the total

Why it scored 60: Wallets take the highest step that applies on the 40-point protocol line, as for the other wallet listings. Openfort wallets pay over x402 and MPP as a buyer, per the docs recipes and the product page, and its own API is not paid over either, so the buyer step (15 of 40). Per-operation prices on every plan are public without a login (20). Free plan of 2,000 operations a month with no card (20). A person signs up in the dashboard or approves `openfort login` in a browser once, after which the CLI creates wallets and policies (5 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):

The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).

- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.
- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login.
- 20, a free tier or trial that doesn't need a card.
- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).

Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.

Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.

## 4. Transparency & trust, 69 out of 100, up to 2.7 more on the total

Made of editorial 64, provenance 73.

Why it scored 69: Closed service under developer terms that name the entity. The Node SDK and OpenSigner are MIT, and the CLI states no licence (20 of 30). The privacy policy of 4 September 2026 gives retention periods and names Google Cloud, PostHog and Sentry. It says Openfort does not store private keys and also lists encrypted key material among what it holds, and the docs index calls backend wallets custodial while the terms call them non-custodial. No DPA found (18 of 30). llms.txt states that `/v1` changes are additive and a deprecated endpoint keeps working at least 90 days after a changelog notice. We read that summary, not the full policy page, and found no dated deprecation notice (15 of 20). Processors and a United States base are in the privacy policy. Payment processors are unnamed and there is no sub-processor list with locations (11 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):

- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.
- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).
- 0 to 20, a deprecation policy or notices with dates.
- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).

The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.

Provenance checks not met in full (half of this category, computed from checked facts):

- Domain age: openfort.io, no registry record we could read (0 of 15)
- Terms of service: read, states 7 of the 7 things a reader expects, and has 1 clause that costs points (8 of 10)
- security.txt: not found (0 of 10)

## 5. Reliability, 88 out of 100, up to 2.4 more on the total

Why it scored 88: Hosted lines. Status page at status.openfort.io on Better Stack with six components and 90-day bars (20). No incidents listed for August to October 2026 and three maintenance windows of 10 to 14 minutes in September. The API bar reads 99.987 per cent, about 17 minutes down that no incident entry explains (28 of 30). Rate limits published per plan, 100 to 1,200 requests a minute (15). A 429 carries `Retry-After`, the errors page asks for exponential backoff on 5xx and says to re-read a resource before retrying a write. No idempotency key is documented, though the Node SDK sends an `X-Idempotency-Key` header (12 of 15). The pricing page lists SLA guarantees on Enterprise and the terms say an SLA may be negotiated in an order form. None is published (5 of 10). The API is generally available with an OpenAPI file at 1.0.0. The Node SDK is 0.13.1 and the CLI 0.2.2 (8 of 10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):

Hosted APIs, MCP servers, models and platforms.

- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).
- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.
- 15, rate limits documented with numbers.
- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.
- 10, an SLA published for any paid tier.
- 10, the surface agents use is generally available, not beta or preview.

Local packages, SDKs, frameworks and stdio MCP servers.

- 20, installs from an official package with supported runtimes stated.
- 25, a public CI and test suite, passing on the default branch.
- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).
- 15, semver discipline and breaking changes called out in a changelog.
- 15, version 1.0 or later, or declared stable.

Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.

## 6. Schema & documentation, 89 out of 100, up to 1.8 more on the total

Why it scored 89: Public OpenAPI 3.0.3 file with 94 operations on 80 paths (25). llms.txt, a docs index, a full-text file and a Markdown twin of every docs page (10). All 94 operations carry a summary or description, and the guides say what each policy operation does and does not check (16 of 20). Policy rules are typed by operation and criterion, and the API refuses a criterion that cannot match its operation (13 of 15). 86 of 94 operations carry examples, and the errors page has the envelope and a status table. Only two error types exist and the `error.code` values are not listed (12 of 15). Path versioning, a versioning policy and a dated changelog. llms.txt says every endpoint lives under `/v1` while the OpenAPI file has `/v2` and `/iam/v2` paths (13 of 15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):

APIs and MCP servers.

- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).
- 10, llms.txt or Markdown docs served for agents.
- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.
- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.
- 0 to 15, examples and documented error responses.
- 15, versioning and a public changelog.

Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.

## 7. Maintenance & community, 87 out of 100, up to 1.1 more on the total

Why it scored 87: Latest changelog entry 28 September 2026 and Node SDK 0.13.1 on 26 September (30). Changelog entries on 24 July, 28 August and 28 September, and six Node SDK tags since 11 July (20). The one outside issue in the 30 most recent items on the Node SDK repository was closed in four days with a reply. Three outside pull requests opened in May and June were merged on 25 September. Support is a Telegram group and plan response times of 24 to 48 hours (15 of 25). Current official SDKs. No entry in the MCP registry (15). CI runs a build, type check and `pnpm audit`, Dependabot is active with five updates open, and both packages are below 1.0 (7 of 10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):

- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.
- 20, at least three releases or dated changelog entries in the last 90 days.
- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.
- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).
- 10, package health, current dependencies and CI.

Models are read for deprecation notice periods and model churn rather than release counts.

## Deductions

Each comes off the total. A fixed and documented problem counts for less at the next check.

- 9 October 2026. The agent wallets page says a signing policy is evaluated server-side on every operation against value caps and allowlists and that caps are enforced at signing time. The policies docs say an EVM backend send is evaluated only as `signEvmHash`, so those rules cannot block one. The docs disclose this plainly, so 3 points (https://www.openfort.io/agent-wallets; https://www.openfort.io/docs/configuration/policies).
- 28 September 2026. The changelog says tokens from a third-party login provider were still accepted after the provider was disabled. Fixed and documented in the changelog, with no advisory found, so 2 points (https://www.openfort.io/changelog).

## What we couldn't check

What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.

- unchecked: the full API versioning page at /api-versioning. The deprecation line rests on the summary in llms.txt
- unchecked: the pagination page, the rules reference, the x402 and MPP recipe pages and the session key pages. Their content is taken from the docs index, the OpenAPI file and the pages that cite them
- unchecked: the docs MCP endpoint at www.openfort.io/api/mcp. We sent it nothing, and its nine tools are as the docs list them
- unchecked: whether the CLI MCP server sets readOnlyHint or destructiveHint. The command source sets none, and the framework that turns commands into tools was not read
- unchecked: the audit reports, which sit in a shared folder we did not open
- unchecked: domain registration date. rdap.org has no RDAP service for openfort.io
- The previous incidents view on the status page was reached at /incidents, the tab the page shows, which the page draws by script and does not link in its markup
- Whether signing policies support a daily or rolling cap. The policy page shows per-transaction value criteria only, and the product page pictures a $50 a day limit on a session key
- Whether the API honours the `X-Idempotency-Key` header the Node SDK sends. The API reference does not mention it
- Whether failed or rejected calls count as billable operations
- The Developer Terms bar using the Services to build a competitive product and exceeding documented rate limits. No clause on automated access or benchmarking was found. Check again before any probe is run

## Weaknesses

- An EVM backend send is evaluated only as `signEvmHash`, so address, value and calldata rules do not block it unless the caller pre-flights
- Signing policies cap value per transaction. No daily or rolling cap was found in the reviewed policy pages
- The CLI MCP server exposes 72 commands as tools, among them `accounts_evm_export`, which returns a private key
- A default secret key includes `accounts:export` and `accounts:sign`
- No SOC 2 report (the vendor says so), no security.txt and no bug bounty found

## What costs an agent a turn today

The notes we give agents before they call it. Each one is a workaround an agent shouldn't need.

- Call `policies.evaluate` with operation `signEvmTransaction` before every EVM backend send. The send itself is checked only as `signEvmHash`
- Keep the signing policy and the gas sponsorship policy separate. Linking a signing policy to a fee sponsorship stops it working as a guardrail
- Pass a fee sponsorship on EVM sends. Without one the transaction stays pending with no error
- Give an agent a secret key without `accounts:export`, and limit the CLI MCP server to the tools it needs
- On a 5xx after a write, read the resource before retrying. On a 429, wait the full `Retry-After`

## When it's done

Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.