Privacy

An API spec and a response body are among the most sensitive things a developer handles. This page is the specific accounting.

By default: nothing

Out of the box, with no settings changed, Tinspec sends nothing anywhere except the requests you explicitly make to your own APIs.

There is no telemetry, no analytics, and no account. The only background network call is the update check against a static JSON file on tinspec.dev.

Everything that could send data elsewhere is off by default and behind its own consent switch.

Where your data lives

Thing	Where
Collections, chains, auth definitions, providers, route matchers, overlays	Plain YAML in your project folder
Run history, spec cache, search index	.tinspec/tinspec.db — local SQLite, rebuildable
Secrets	OS keychain, or a machine-local AES-256-GCM encrypted store
Your Anthropic API key (if AI assist is on)	The encrypted store — never handed back to the UI
The agent-access token	The encrypted store

Secrets are never written to the YAML files or the database. Auth definitions reference secrets by name. This is what makes the project folder safe to commit and safe to sync.

AI assist — what leaves

AI assist is off by default. With it on and your own Anthropic key stored:

What is sent: a minimal OpenAPI subset — the operations of the endpoints you are working with, their parameters and schemas. Nothing else.

What is never sent:

• Response bodies. Whatever your API returned stays on the machine.
• Environment values.
• Secrets, tokens, or keychain contents.
• Run history, your project folder, or any file.

How to verify it rather than trust it: the AI panel has a collapsible “context sent with prompts” preview showing the exact payload, verbatim, before it goes. Open it once.

Requests go directly from your machine to Anthropic with your key. There is no Tinspec-hosted inference tier, and nothing routes through Tinspec’s servers.

Agent access — what leaves

Agent access is off by default, behind a consent switch separate from AI assist.

With it on, the app serves MCP on 127.0.0.1 only — never a network interface — behind a bearer token, and refuses requests without it.

What an agent can read: the open project’s endpoints, saved requests, chains, run history, environment variable names, and — this is the important one — response bodies from requests it sends.

That last point deserves to be stated plainly rather than buried: response bodies do reach whichever model your agent uses. That is the purpose of the feature, and it is why it is off by default and why you approve sends one at a time.

What never crosses:

• Environment values. Keys only.
• Auth tokens. Masked as Bearer **** in what the agent sees.
• The keychain. Not reachable through any tool.

What is recorded: every agent send lands in run history tagged mcp with the client name, alongside your own runs. The Agent activity panel shows every tool call, its outcome, and each approval decision live.

Cloud sync — what would leave

Not available to sign up for at this release. When it is:

What syncs: collections, chains, auth provider definitions, API providers, route matchers.

What does not: secret values, ever. Auth definitions carry secret names; the values stay on the machine that holds them. A teammate who pulls a synced auth provider gets the flow and must supply their own credential.

The update check

On startup the app fetches a static JSON file from tinspec.dev to see whether a newer version exists. It is a plain file read — no identifiers, no usage data, nothing about your project.

Summary

Feature	Default	What leaves
The app itself	On	Nothing but the requests you make
Update check	On	Nothing — a static file read
AI assist	Off	An OpenAPI subset, previewable verbatim
Agent access	Off	Spec and response bodies, to your own agent, per approved send
Cloud sync	Off (not open)	Documents, never secret values