# Security and data flow

For the people who approve software: what Recipe360 runs, what it reads, what leaves the computer, and how to pin
what its MCP server offers.

## Where it runs

Recipe360 is a program on the person's own computer (macOS with Apple silicon, Linux or Windows), installed
without administrator rights. Its engine is compiled. It has no web server and listens on no port: an agent
program starts it as a subprocess and talks to it over standard input and output (MCP's stdio transport).

## What it reads and writes

| What | Where |
| --- | --- |
| Reads | The data files or folder the person names for a run, and the workspace (`~/.recipe360`, or `RECIPE360_HOME`) |
| Writes | The workspace only: recipes and their history, run folders, the run ledger, settings, and the signing key if one is created |

The workspace is a folder of plain files: recipes in YAML or JSON, run records in JSON. Nothing is hidden in a
database.

## What reaches the AI model

The agent program receives counts, fingerprints, folder names and fixed plain-word messages. It never receives
rows of data: Recipe360 reads the files and does every calculation itself. To make sure the model cannot open the
data with its own tools either, close the data folder to the agent program, as
[Agent programs](agents.md#keep-the-data-away-from-the-model) shows for each one. What the person and the agent say
to each other goes to the agent's AI provider under that provider's terms; Recipe360 does not see it.

Columns a recipe marks as sensitive must be removed or masked by a `protect` step before anything is saved, and
Recipe360 refuses a recipe that would save them. Each run record lists which columns were removed, masked or
turned into tokens.

## What leaves the computer

The licence check: activating, renewing (about once a month) and deactivating contact
`https://recipe.pulso360.ai/licence/` with the licence key, a random installation id, a one-way fingerprint of the
computer, the computer's name, and the Recipe360 version and operating system.

Time stamps, only when the person turns them on (`recipe360 timestamps on`): the sha256 of each new run record
goes to the chosen time-stamping authority (FreeTSA by default). A fingerprint reveals nothing of the record.

No data file, recipe, result, run record or conversation is ever sent. Pulso360 does not receive them.

## The MCP server

Recipe360 speaks MCP 2026-07-28 (stateless: each request names its version, client and capabilities) and the
earlier versions 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05, which start with `initialize`. It implements
`server/discover`, answers an unknown version with `UnsupportedProtocolVersionError` (-32022), and lists its tools
in a fixed order.

Every tool declares an `outputSchema`, and every successful result carries `structuredContent` that matches it.
Every tool carries annotations: none reaches the internet (`openWorldHint: false`), the ones that only read say so
(`readOnlyHint: true`), and none deletes anything (`destructiveHint: false`). Only a run, a saved recipe, a
confirmation of rules, a test or a record file written to a run folder change anything.

Recipe360 does not use MCP's logging, sampling or roots: its run records are its audit trail.

### Pinning the tool definitions

A changed tool description is a known way to mislead an agent ("tool poisoning"). Pin Recipe360's definitions:

```bash
recipe360 tools
```

prints the sha256 of each tool's full definition (name, description, input and output schemas, annotations) and
of all of them together. Record them when you approve a version; a gateway or a review can then notice any change.
They change only with a new version of Recipe360, and the change log says when.

## Evidence for audits

Each run's record names who ran it, the data, the recipe version, every step's fingerprint and the deliverables'
fingerprints. Records form a chain that `recipe360 verify` checks, can be signed with a workspace key, and can be
exported as in-toto statements. See [Run records](run-records.md).

Recipe360 helps produce the evidence that audits and regulations ask for: reproducible results, traceable data and
steps, records that show tampering. It does not by itself make an organisation compliant with any regulation;
that depends on how it is used, and on the organisation's own controls.