Salt Security is Not Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Salt Security API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 19/100Comprehension
55% of score · 0/100What we found
- An agent looking for Salt Security's API documentation hits a hard login wall: the entire Developer Portal (docs.secured-api.com) redirects every path — including llms.txt — to login-docs.secured-api.com, so zero endpoint, auth, or error documentation is publicly readable.
- No public OpenAPI spec, llms.txt, llms-full.txt, AGENTS.md, or MCP registry listing exists anywhere — notable for a company whose homepage leads with 'Agentic AI Security and MCP Discovery' and whose product ingests other companies' OpenAPI specs.
- The one bright spot: salt.security/robots.txt is permissive (User-agent: * / Allow: /) with no AI-crawler blocks, and it references a working sitemap — but that sitemap covers only marketing pages, not documentation.
- docs.salt.security does not resolve at all; the docs live on a separate secured-api.com domain that an agent has no discoverable path to except one 2024 blog post.
- The public web surface an agent can actually read (API Security 101, blog posts, use-case pages) is educational marketing content about API security in general, not documentation of Salt's own API.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a public read-only tier of the Developer Portal — at minimum the API reference, authentication overview, and getting-started guide. The blanket login wall is the single blocker behind nearly every failed check.
- 02Publish the platform API's OpenAPI spec publicly (highest-weight discovery check, worth 5/21 alone) — especially credible for a vendor whose product is built around OpenAPI analysis.
- 03Add an llms.txt at salt.security (and on the docs domain) that links to whatever public API documentation exists, with API-focused sections and descriptions.
- 04Ship an official Salt Security MCP server and list it on Glama/Smithery/PulseMCP — this directly matches the company's own agentic-AI security positioning and is currently absent.
- 05Point docs.salt.security at the developer portal (or at least a public landing page) so agents resolving the obvious docs subdomain don't dead-end on DNS.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Nothing is publicly documented. The Salt Developer Portal (docs.secured-api.com/apidocs) requires a Salt Dashboard login for all content, so auth methods, error formats, rate limits, pagination, and idempotency behavior cannot be assessed from public sources. Marketing materials mention code samples in Python, Java, and Go and built-in testing tools inside the gated portal.