How data is handled

When you connect an assistant to Citino, everything a tool returns lands in that assistant’s context, next to instructions Citino did not write. So the server is built around one rule: what it returns is measurement data, and nothing in it was written to be acted on.

​

It only reads

No tool adds, changes or deletes anything. A confused assistant cannot spend your prompt allowance, track a competitor or change your engines. Changes go through the REST API, from a script a person wrote.

​

What a tool returns

• Numbers, each with its ± band, its sample size and whether a change is within noise. See Metric objects.
• Names: brands, your prompts’ text, segments, domains and URLs, and the short web searches engines ran before answering.
• Dates and statuses.
• A short, fixed list of sentences Citino writes itself, where the sentence is the meaning: an alert’s headline and detail, the “what moved” headline, an experiment’s notes and verdict, a claim’s verdict summary, the note on how attribution is estimated and how much traffic it covers, the note on crawler activity, and the sentence saying what a set of figures counts.

​

What a tool never returns

• An engine’s answer text. Answers are written by AI engines from pages anyone can publish, which makes them exactly the text an attacker would use to slip instructions to your assistant. They are not in any tool’s result. A person can read one answer through the REST API, in a script they wrote.
• Quotes from answers: no claim evidence, no objection quotes. An objection appears only once it has been grouped under a label, because before that its label would be a quote.
• Links into the Citino app and report share links. A URL in a result is data, the address of a page an engine cited, never a link the tool asks your assistant to open; a customer-typed address that is not http or https is left out.
• Your teammates’ names, an agency’s logo and contact address, and the raw text of a website’s robots.txt.
• Anything from another workspace, or from a project the connection may not read.

​

Strings are cleaned and capped

Every string a tool returns has control characters and invisible characters removed (the kinds that can hide text from a person reading the same screen: zero-width characters, direction overrides, tag characters), and is cut off at 2,000 characters. A landing page path from your analytics, which anyone can create by visiting your site, is returned as plain, percent-encoded characters.

​

Whose data a connection reads

• Signed in, a connection reads as the person who connected it: their workspace, everything their dashboard shows, read-only. A client portal login cannot connect at all.
• With an API key, a connection reads what the key allows: its read scopes and, if it was limited, its projects.

​

What Citino keeps

• For each request to the MCP server: the time, the status, how long it took, the client’s name as it sent it, and the shape of the credential (a key, a sign-in token, or nothing) — never the credential itself. When a tool refuses, the tool’s name and the error code.
• Keys and sign-in tokens are stored only as hashes. A sign-in connection uses a short-lived access token that the app refreshes by itself; a connection unused for 90 days ends.
• Disconnect on Workspace settings → Connected apps ends a signed-in connection at once. Revoking a key on Workspace settings → API keys ends a key connection.

What your assistant’s vendor does with tool results once they reach it is governed by your agreement with that vendor.

​

Related