An information transaction: one request, one decision, one proof. The decision weighs who is asking, for what, in which context, for what purpose and under which policy. What the policy allows is released, and every decision returns a signed receipt.
NoData MCP · agents
A key is not a permission.
How to give an agent autonomy, without giving it authority.
An AI agent found an API key in another project, called a paid service and ran up a $100 charge. It did not break in. It did not steal. It found a key and assumed it was allowed to use it.
For years we built systems around one question: who may access this? But an agent does not access once. It works in a stream: it opens files, searches folders, reads documents, runs commands and uses keys. In that world a permission granted once is no longer enough.
The choice was a restricted agent, whose every action waits for approval, or a free one, which can do things you did not intend. NoData MCP offers a third way: every action is checked the moment it is requested.
claude mcp add -s user nodata -- npx -y @nodatachat/mcp@latest # macOS / Linux
claude mcp add -s user nodata -- cmd /c npx -y @nodatachat/mcp@latest # Windows
npx -y @nodatachat/mcp install-gate # optional: read gate + status line
-s user makes it available in every folder. install-gate adds the read gate and the status line. Restart Claude Code after both.
your terminal
$ claude mcp add -s user nodata -- npx -y @nodatachat/mcp@latest
With no key, the server starts in setup mode and walks you to the next step. Works with Claude, Codex, and any MCP client.
The path · stop by stop
From one command to full control
1
One command
claude mcp add -s user nodata -- npx -y @nodatachat/mcp@latest
The MCP connects and the setup tools light up, before you have a key.
2
Connectmanual · once
nodata_connect
No arguments. The tool opens a page in your browser: sign in (or create a free account) and click Approve. No key is pasted into the chat.
3
Activatemanual · once
/mcp
The client loads the tools. Every later start comes up ready.
✓
You're governing
SEE what's sensitive (scan) → CHOOSE what to release (grant) → PROVE what happened (proofs · revoke).
A decision per action
Don't trust the agent. Check every step.
Finding a key does not mean it may be used. Having access to a file does not mean it may be read. Each request is checked for:
Who is asking: a person or an agent.
The action: read, search, run, write, use a key.
Which file, folder or key, and in which project.
The hour and the weekday, in the time zone you chose.
Which rules apply: yours and your organisation's.
The outcome: allowed · ask you · clean copy only · up to a number of uses a day · not allowed. Every decision is logged, and decisions made on the server get a signed receipt.
Classify · Protect · Route · Retrieve · Prove
ClassifyFind what is sensitive: documents, folders, keys, personal data. The scan runs on your computer, and only counts and locations leave it, not the values.
ProtectProtect it where it lives. A file you locked stays encrypted, and keys sit in the vault instead of an open .env file.
RouteEvery agent action is checked against the rules, not against a fixed permission list.
RetrieveOnly what is allowed is released. Sometimes the file, sometimes a clean copy, sometimes nothing.
ProveEvery decision is recorded: who asked, for what, what was allowed, what was held and when.
What the user sees
Files and folders
Several rules per folder. For example:
Finance: only with your approval.
Contracts: a copy without identifiers.
Management: closed outside working hours.
Customers: read yes, write no.
Everywhere else the agent works freely.
API keys
For each key in the vault you set what it does and what an agent may do with it:
Not for agents.
Only with your approval, per command.
Up to a number of uses a day.
Only at certain hours.
The policy is checked on both ways an agent asks the vault for a key: when it runs a command, and when it calls a prepared action.
No secrets pasted into the chat
The agent runs commands with the keys without seeing them, and the values are masked in the output too.
Organisation policy
The admin writes a rule once and it reaches every computer in the organisation. A computer can tighten it, not loosen it.
How it works for developers
install-gate · the gate
A Claude Code hook. Before Read, Grep, Bash or Write it checks the file and folder rules, the scan findings and key files. Reading a .env, or searching folders that hold keys, is held before it runs, in other projects too.
Conditions: who, what the key does, project, hour, weekday and date.
Outcomes: allow, approve, a daily cap, deny.
nodata_run · nodata_use
nodata_run runs a command with the vault's keys, in memory only, and masks the values in the output. Each command is approved as written, and before approval it shows what each key will get.
nodata_use: the server injects the key into a prepared action. The agent does not receive the key, and the key's policy is checked here too.
Access instead of copies
nodata_expose gives a partner clean copies from a folder, for as long as the rule lives.
nodata_send sends a link with an expiry, an open count, a code over a separate channel, and view-only if you want.
Both can be revoked at any moment.
The limits, honestly
Enforcement on the agent's own file tools works today in Claude Code. In other agents (Cursor, Codex) NoData's own tools are enforced, not their file tools.
The key policy covers keys in the vault. A key in an open file is covered by the gate holding its read. A key already exposed in a chat must be rotated.
The cap counts uses, not dollars. Set a real spending limit at the provider as well.
A program that builds a path at run time can go around the gate. For certainty, lock the file or move the keys into the vault.
NoData does not promise an agent won't make mistakes. It checks each action against the limits you set before it happens, and records the decision.
The old question was: who has access? With agents the question is: who may take this action, now, in this context?
NoData MCP replaces a standing permission with a decision computed on every action.
The agent works alone. It doesn't decide alone.
Every MCP tool (38)
Generated from the source of @nodatachat/mcp@1.3.36, not written by hand. The tag on each tool says which credential exposes it. Tools that change files or policy show a preview and ask before acting.
Setup
4
nodata_connect
before connecting
Connect this computer to the user's NoData organisation.
nodata_get_started
every mode
Call this FIRST (no arguments). NoData in one line: what you can achieve, an agent that cannot leak, a look at what is already exposed, a secret we cannot read, with the single next step for each, and how to recover if the tools or MCP...
nodata_node
owner · this machine
Register THIS MACHINE as a Capsule node of the organisation, so "this machine is guarded" is something the organisation can verify, not only the user.
nodata_terms
owner · this machine
Show NoData's terms of use (current version) and, on the user's explicit approval, accept them.
Find and lock
10
nodata_decrypt
owner · org connected
LEGACY (v0.1). Decrypt a Blind Relay string (aes256gcm:v1:iv:cipher:key, the key travels inside it).
nodata_encrypt
owner · org connected
LEGACY (v0.1). Encrypt a field value with Capsule Blind Relay.
nodata_open
owner · this machine
RELEASE a sealed file: open <file>.ndc back to its original next to it (never overwrites), and check its hash matches what was sealed.
nodata_plan
owner · this machine
RECOMMEND a policy after a scan, per file, and apply it only once the user approves.
nodata_protect
owner · this machine
LOCK files: seal each one as <file>.ndc (AES-256-GCM, sealed to this device's key, which never leaves this machine).
nodata_redact
owner · this machine
WORK on the rest: make a clean copy of a file with every sensitive value replaced by a typed token ([CARD], [ID], [IBAN], [PHONE], [EMAIL]); in CSV/TSV and Excel a column whose header names personal data (name, address, account number…) is...
nodata_run
owner · this machine
Run a command on this machine (tests, a migration, a deploy script) WITH the project's secrets from the NoData vault as environment variables, without you seeing them.
nodata_scan_feedback
owner · this machine
REPORT a wrong scan result so NoData's detectors improve: files the scan flagged that are NOT actually sensitive (`not_sensitive`: relative paths or patterns from the scan), and kinds of data it MISSED (`missed`: {"phone": 2}).
nodata_scan_folder
owner · this machine
SEE what's sensitive. Scans a LOCAL folder for hardcoded secrets and unencrypted PII (checksum-validated Israeli ID, Luhn credit card, IBAN, phones), entirely on this machine.
nodata_wrap
owner · org connected
WRAP files into your organization's sovereign archive (a zero-knowledge capsule): each file is encrypted ON THIS MACHINE to the public half of your org master key, the 12 words from signup, and only ciphertext is uploaded.
Share and deliver
6
nodata_burn
owner · org connected
BURN a link sent with nodata_send: the stored ciphertext is zeroed, so nobody, the recipient, a forwarded copy, NoData, can open it again.
nodata_deliver
owner · org connected
Create a burn-after-read secure link for delivering sensitive content.
nodata_expose
owner · org connected
Access, not copies: let a partner's computer ASK this one for files in a folder, instead of sending them copies.
nodata_inbox
owner · org connected
The NoData road (Fabric) on THIS computer: its address, what arrived, and who may reach it.
nodata_link_status
owner · org connected
STATUS of links sent with nodata_send: opens so far, expiry, whether burned.
nodata_send
owner · org connected
SEND a file as a governed link: encrypted on this machine (post-quantum hybrid), stored by NoData only as ciphertext, the key rides in the link's #fragment, which NoData never receives.
Govern and policy
10
nodata_api_list
owner · org connected
The organisation's APIs held to a NoData rule, a bank, a CRM, any https API, each with its rule (which methods and paths are allowed; read-only by default).
nodata_api_read
owner · org connected
READ from an API held to a NoData rule (GET or HEAD; see nodata_api_list).
nodata_api_write
owner · org connected
WRITE to an API held to a NoData rule (POST, PUT, PATCH or DELETE; changes data at the API; see nodata_api_list).
nodata_connect_source
owner · org connected
Connect the user's own Supabase project as the data source for their registered tables, so granted agents can read metadata through NoData.
nodata_grant
owner · org connected
Issue ONE AI agent a claim-scoped grant over your data, claims, not blanket access.
nodata_policy
owner · org connected
The POLICY BOARD: every AI agent in the organization and exactly what it can reach, tables, columns, classifications, plus status.
nodata_register_table
owner · org connected
Register one of your own tables as AI-agent-readable.
nodata_revoke
owner · org connected
Revoke an agent's grant by handle (kills all its active credentials) or by a specific jti.
nodata_rules
owner · this machine
The RULES BOARD for files and folders on this computer: what an AI agent may do with each one, allowed, ask the user, clean copy only, or not allowed, optionally only at certain times or for certain actions (read, search, run, write) or...
nodata_seal_revoke
owner · org connected
Revoke a SEALED FILE so it never opens again, for anyone (use when a .ndc leaked or a computer was lost).
List your organization's signed proofs: every grant, agent read and denial, newest first.
Scoped agent (grant token)
6
nodata_code_advise
--grant-token
Ask the blind code advisor to diagnose/fix a bug in a code capsule WITHOUT seeing its source.
nodata_code_patch
--grant-token
Submit a fix to a code capsule as a SIGNED, queued patch WITHOUT seeing its source.
nodata_decide
--grant-token
Ask whether this agent MAY reach a resource, WITHOUT reading it.
nodata_read
--grant-token
Read governed data within this agent's grant.
nodata_retrieve
--grant-token
Retrieve prompt-ready context for a resource, filtered to exactly what this agent may see.
nodata_use
--grant-token
Invoke a pre-registered capability (deploy, send, charge, query, …) WITHOUT receiving the secret.
The full description of each tool reaches your client over MCP. The npm README has worked examples for each. README →
CLI · one engine, two doors
The same engine is reachable from a terminal (nodata) and from any MCP client (@nodatachat/mcp). Scan and protect run locally, with no account.
npm i -g @nodatachat/nodata
nodata # guided menu (English / עברית)
nodata scan <dir> # what an AI could read here (local, no account)
nodata protect <dir> # seal it, keep the key (local)
nodata open <file>.ndc # reverse a local seal
nodata agent grant # give an agent its own identity and access
nodata agent ask # a governed decision (allow / deny / degrade) + a receipt
nodata agent revoke <name> # remove access
nodata verify <proof_id> # check any decision receipt
nodata mcp # print the MCP config for your client
SDK
Install, one call, a signed answer. No server to stand up and no schema to change.
1 · install
npm i @nodatachat/sdk
2 · the call
import { NoData } from '@nodatachat/sdk';
// your org key: ndp_...
const nd = new NoData({ apiKey: process.env.NODATA_KEY });
const { decision, answer, proof } = await nd.compute({
question: 'What is the claim status?',
clearance: 'internal',
sections: [
{ title: 'Status', text: 'Approved on 2026-07-14' },
{ title: 'SSN', text: '123-45-6789' }, // out of clearance
],
});
await nd.verify(proof.id); // { authentic, unaltered, signer }
3 · what comes back
decision: 'allow'
answer: answered from Status · SSN did not reach the model
proof: signed
The ssn was not filtered from the response. It was not opened.That is the difference between a filter and an authorization, and a question an auditor will ask you.
the three calls
POST /api/v1/governance/grant # agent + grant, returns ndca-...
POST /api/access/compute # "may I?": a decision, no data
POST /api/agents/{handle}/read # reads what was authorized